solidusio / solidus_starter_frontend Goto Github PK

Some users reported in Slack that it's not possible to override the auth views. We should provide a way to do that (maybe using append_view_path instead of prepend_view_path in the concern that adds those views) or at least document what to change in their application to have custom views.

We could add an option to the installer to copy the assets using the webpacker structure.

Now that we rewrote and decoupled the JavaScript codebase from the Solidus one (and jQuery), we should find a way to exclude jQuery from being included in the frontend.

After the first pass, we can explore alternatives to remove code from views. There are a lot of things that we can use, eg https://github.com/github/view_component.

We could change the homepage field to this repo (in this way the stars count will appear on the Rubygems page).

We could add some badges to the README:

• https://badge.fury.io/for/rb/solidus_starter_frontend
• https://circleci.com/gh/nebulab/solidus_starter_frontend

This is the output of gem build:

WARNING:  description and summary are identical
WARNING:  open-ended dependency on generator_spec (>= 0) is not recommended
  use a bounded requirement, such as '~> x.y'
WARNING:  open-ended dependency on rails-controller-testing (>= 0, development) is not recommended
  use a bounded requirement, such as '~> x.y'
WARNING:  open-ended dependency on rspec-activemodel-mocks (>= 0, development) is not recommended
  use a bounded requirement, such as '~> x.y'
WARNING:  open-ended dependency on selenium-webdriver (>= 0, development) is not recommended
  use a bounded requirement, such as '~> x.y'
WARNING:  open-ended dependency on solidus_dev_support (>= 0, development) is not recommended
  use a bounded requirement, such as '~> x.y'
WARNING:  See http://guides.rubygems.org/specification-reference/ for help
  Successfully built RubyGem
  Name: solidus_starter_frontend
  Version: 0.1.0
  File: solidus_starter_frontend-0.1.0.gem

We need to improve some information 😅

This items are currently not styled:

In our specs we have a lot of:

DEPRECATION WARNING: lastname is deprecated and will be removed from Solidus 3.0 (use name instead) (called from ___solidus_starter_frontend_app_views_spree_components_forms__address_inputs_html_erb___1467724030274288326_70139211483620 at solidus_starter_frontend/app/views/spree/components/forms/_address_inputs.html.erb:26)
DEPRECATION WARNING: firstname is deprecated and will be removed from Solidus 3.0 (use name instead) (called from ___solidus_starter_frontend_app_views_spree_components_forms__address_inputs_html_erb___1467724030274288326_70139211483620 at solidus_starter_frontend/app/views/spree/components/forms/_address_inputs.html.erb:16)

We need to take care of them 😄

In reference to this comment #42 (comment) we should move the stock availability snippet into a separate component.

After we release the first version, we should review the whole README to update installation instructions and experimental notice

See: solidusio/solidus_paypal_commerce_platform#100 (comment)

I think we can evaluate restoring them or provide another way for doing the same thing in the new frontend.

We currently use a non-common use case and we should swap the addresses which is the most common use case.

Check the mobile compatibility of the actual code and provide mobile versions when needed.
N.B. The header should be revised from a designer asap.

For some reason, the locale selector disappeared in the restored Sandbox.
See app/views/spree/components/navigation/_locale_selector.html.erb
current_store.available_locales just contains [:en] language.
When using the dummy app the selector is present and current_store.available_locales is fully populated with all language choices.

The RSpec team now officially recommends system specs: https://github.com/rspec/rspec-rails#system-specs.

We should make a serious attempt to convert the existing feature specs into system specs.

Hi everyone - thanks so much for this fork that has taken so much of the effort out of implementing a Bootstrap frontend for my store.

I know the goal is to strip out all Skeleton classes, but some of the classes stripped are actually depended on by the JS.

The first example is: https://github.com/solidusio/solidus/blob/master/frontend/app/assets/javascripts/spree/frontend/cart.js#L7

This code expects the line items in the cart to have a class of 'line-item' in order to remove them, but this class has been removed. I'm sure I've seen other examples but I don't have them to hand yet. Something to be aware of, anyway!

Failing system specs don't use capybara-screenshot to store the screenshots but they are automatically generated by Rails. But ScreenshotHelper has no options to set the output path.

Perhaps we could update the Solidus orb in this way:
https://github.com/solidusio/circleci-orbs-extensions/pull/34/files

Rerunning sometimes it disappears, other times it appears with MySQL or Postgres only 😑

https://app.circleci.com/pipelines/github/nebulab/solidus_starter_frontend/664/workflows/dfa3f5fa-4833-4258-baf4-6f256feebc1d/jobs/1522

Checkout with attempted XSS escaped XSS string displays the entered state name without evaluating - spec.system.checkout_spec
spec/system/checkout_spec.rb
Failure/Error: fill_in state_name_css, with: xss_string

Capybara::ElementNotFound:
  Unable to find visible field "order_bill_address_attributes_state_name" that is not disabled

[Screenshot]: /home/circleci/project/spec/dummy/tmp/screenshots/failures_r_spec_example_groups_checkout_with_attempted_xss_escaped_xss_string_displays_the_entered_state_name_without_evaluating_201.png


Shared Example Group: "safe from XSS" called from ./spec/system/checkout_spec.rb:636
./spec/system/checkout_spec.rb:621:in `block (4 levels) in <top (required)>'

An example is in categories page using bin/rails dev:cache.
After the first visit the partial "Shop by Categories" seems to be cached and the current category is not highlighted anymore.

Image:

Without cache the current category is in bold.

Instead of using prop names such as small and big we should look into naming them in a more semantic way, such as primary, secondary or similar.

Using controller specs is now discouraged by both Rails and RSpec teams: https://github.com/rspec/rspec-rails#request-specs, and we already did something similar for Solidus API with solidusio/solidus#2052

When I create the sandbox I get this error:

/projects/.asdf/installs/ruby/2.7.1/lib/ruby/gems/2.7.0/gems/actionpack-6.0.3.4/lib/action_dispatch/routing/route_set.rb:578:in `add_route': Invalid route name, already in use: 'root'  (ArgumentError)
You may have defined two routes with the same name using the `:as` option, or you may be overriding a route already defined by a resource with the same naming. For the latter, you can restrict the routes created with `resources` as explained here:
https://guides.rubyonrails.org/routing.html#restricting-the-routes-created

Steps to reproduce

• Clone the repo: git clone https://github.com/nebulab/solidus_starter_frontend
• Enter in the project root: cd solidus_starter_frontend
• Run bundle: bundle
• Launch the sandbox executable: bin/sandbox

Feels natural to have this happen and I often find myself writing 'MM/YY' manually.

(would only be needed for non Stripe payments)

I have a working example over here on CodePen

https://github.com/nebulab/solidus_starter_frontend/blob/master/app/views/spree/components/navigation/_categories.html.erb#L4

Creating a new app from scratch I get the error:

solidus_starter_frontend/lib/solidus_starter_frontend/engine.rb:20:in `block in <class:Engine>’: uninitialized constant Spree::UserConfirmationsController (NameError)

Steps to reproduce

• create the Rails app (6.0.3.2): rails new solidus_test
• add Solidus to Gemfile:

gem 'solidus_core'
gem 'solidus_api'
gem 'solidus_backend'
gem 'solidus_sample'
gem 'solidus_auth_devise'

• execute bundle
• run the generator bin/rails g spree:install
• add the starter to Gemfile:

gem 'solidus_starter_frontend'

• mkdir -p app/assets/javascripts/spree/frontend
• add to app/assets/javascripts/spree/frontend/all.js:

//= require spree/frontend/solidus_starter_frontend

• mkdir -p app/assets/stylesheets/spree/frontend
• add to app/assets/stylesheets/spree/frontend/all.css:

/*
 *= require spree/frontend/solidus_starter_frontend
 */

• spree/shared/nav_bar could be deleted but in turn it renders:

• spree/shared/locale_selector: we don't render it actually in our header. I think we should do it instead. (Or is it part of the super basic approach?) (see #72 )

• spree/shared/_login_bar_items: This partial just contains a comment that says:
  "solidus_auth_devise or a custom auth system can replace this partial".
  Also, in this case, should we render it elsewhere?

Can we translate all the current helpers into components? Let's investigate!

In order to replace the solidus_fronted gem and test changes directly on solidus_starter_frontend we need to move some files and folders from the current frontend gem to the new one.

Anything not strictly related to HTML views, JavaScript files and CSS styles should be copied over to the new gem.

gem install solidus_starter_frontend hits this error Could not find a valid gem 'solidus_starter_frontend' (>= 0) in any repository

And the old way of bundle exec rails g solidus_starter_frontend:install hits the error Could not find generator 'solidus_starter_frontend:install'

With a single locale in the store, I get this console error:

locale_selector.source.js:3 Uncaught TypeError: Cannot read property 'addEventListener' of null
    at locale_selector.source.js:3

Adding another locale to available_locales of the current store makes the error disappear.

During the refactor, we accidentally deleted the locale selector from the codebase. We should bring it back and re-test.

This is the file in question: https://github.com/solidusio/solidus/blob/master/frontend/app/views/spree/shared/_locale_selector.html.erb

We can assume this project will be used for new stores only and we can safely remove all deprecations in the codebase.

We have some proposals about using (or adding) different install methods:

• loading a remote install command directly in rails new?
• add our component to Rails Bytes?

👋 Hey

I've been using this repo for a project recently and found the use of class names for JS functionality rather frustrating.

I kept deleting the class name, replacing it with my own classes and then having functionality not work. There are only a few cases, but I think it's worth looking at.

Keep logic to ID's and style to classes.

I can take a look at this if someone wants me too.

I think there are some undocumented steps that developers need to take in order to start development on this project.

I went with the usual:

bundle install
bundle exec rspec

and ran into a bunch of errors immediately related mostly to files missing and uninitialized constants.

It looks like there are probably some steps that need to be taken in order to set up the project that aren't documented anywhere.

Documenting those steps will make on-boarding developers much easier.

It could be cleaner to use this approach for every property check inside all components.

base_class = local_assigns.fetch(:base_class, nil)

in place of

base_class = nil if local_assigns[:base_class].nil?

We probably removed it from the header in some refactor and we should add it back.

• Users/Edit
• Users/Show
• shared/order_details

The mobile version of the header needs a redesign.
LOGIN / MY ACCOUNT and CART() could be replaced by icons.

Signed Out	Signed In

N.B. The search by category selector is there but is actually hidden.
Is the search by category functionality still wanted?
Does the searchbar require a round of redesign too?