What's your preferred frontend installation option?

[kennyadsl]

Hello!

We are working on a new starter frontend for Solidus, that you can find here in an alpha version:

https://github.com/nebulab/solidus_starter_frontend/

We are in the process of deciding how to this new frontend should be installed in new stores.

We have a couple of options in mind and we would like to know your opinion:

1. as a gem

Exactly as we are doing with the current solidus_frontend gem, this can be added in the Gemfile of the application and, since it's a Rails Engine, make all its routes, controllers, views, helpers and assets available in the host application. The gemfile would look something like:

gem 'solidus_core'
gem 'solidus_backend'
gem 'solidus_api'
gem 'solidus_starter_frontend'

To customize things it's a matter of overriding views (or using Deface, even if we wouldn't do that for the frontend), using prepend or class_eval for controllers as always.

With this approach, we can still provide a task to copy views (probably adding controllers as well) as we are currently doing with solidus_frontend.

2. as an installer

The new gem will not be part of the bundle. You should install it in your system and run a command to install it. Something like:

cd your_store/
gem install solidus_starter_frontend
solidus_starter_frontend .

The installer will copy everything (views, controllers, routes, helpers, assets, and probably also specs) into your own application.

From that moment you have total control of everything and need no override to add your customization.

This will provide much more flexibility but it will be hard to get the last changes released in future versions (unless you implement them in your store on your own). On the other hand, we are not upgrading solidus_frontend anymore to avoid breaking existing applications, so there are generally not a lot of changes to pick in your application when you upgrade with it as a gem.

---

If you have to start a new store with Solidus tomorrow, what option would you choose and why?

[jarednorman]

What about as a Rails generator?

bundle exec rails generate solidus_starter_frontend

Rails' generator system is moderately robust and offers tooling for creating all the files necessary to set up a starter frontend. It might be more reliable than building our own command line tool to do this. Additionally, it's a "normal Rails thing", so I'm always inclined to consider options like that.

[filippoliverani]

This solution can be very different from Thomas's one, depending on whether the gem will provide both the engine and the generators or just the generators.

I would rather not have an engine messing with my routes and loading classes, but I'd love to use a generator to copy files like option 2.
A problem could be that if generators are kept in a gem, we would still have to require the gem itself to be able to run them. It could be pretty awkward to require a gem just to run the generators. After running them, the gem will be useless, but it will be required every time by bundler unless we explicitly remove it from the gemfile.

So probably option 2. is the closest thing to using generators without keeping them in Solidus core or removing a gem just after having used it once, correct?

[jarednorman]

The gem would be required only in the development environment, so I don't think this would be a serious issue, but perhaps we could find a better solution so that only a fraction of the code is loaded unless the generator is actually being run. That would require a little experimentation.

[waiting-for-dev]

A problem could be that if generators are kept in a gem, we would still have to require the gem itself to be able to run them. It could be pretty awkward to require a gem just to run the generators. After running them, the gem will be useless, but it will be required every time by bundler unless we explicitly remove it from the gemfile.

I wanted to do some tests about it, and in fact, you don't need to add the gem to the Gemfile in order to be able to run the generators. You can check it with the minimal gem I created in this repo:

https://github.com/waiting-for-dev/gem_with_rails_generators

This repository has a minimal DummyGenerator that will only create a dummy.rb initializer.

Usage as an installer

• git clone https://github.com/waiting-for-dev/gem_with_rails_generators
• cd gem_with_rails_generators
• gem build gem_with_rails_generators.gemspec
• gem install gem_with_rails_generators-0.1.0.gem
• Now cd into any Rails repo, for instance, the sandbox application that you may have created within your local solidus repository
• Run dummy_generator from the shell. It will execute the gem's executable
• Check that config/initializers/dummy.rb got created.
• Don't forget to gem uninstall gem_with_rails_generators 🙂 and to remove the initializer

As a gem

• Following from above, add gem 'gem_with_rails_generators', path: '/path/to/your/local/gem_with_rails_generators'
• bundle
• bin/rails g gem_with_rails_generators:dummy
• Check that config/initializers/dummy.rb got created
• Don't forget to remove the initializer, remove the gem from the Gemfile and re-bundle

Using it as an installer has a caveat, though. We can't access Rails.application, so we can't do any reflection if we need it at some point. Of course, it's the case for any other kind of implementation for the installer option. I tried to do some funky stuff and require_relative 'config/environment', and then I got access to Rails.application. However, it's brittle because it can cause conflicts between dependencies as bundler has to be configured for our gem and the host Rails application.

[jarednorman]

Yeah, I've not looked at the source, but isn't this essentially what solidus_starter_frontend does currently? You just gem install it and then run the command it provides. It looked like it was just running a rails generator when I tried it.

[waiting-for-dev]

Yes, I wanted to confirm how many dependencies you need to pull, though. Currently, it depends on the whole rails gem, and it requires active_support on the executable. In my tests, we only need railties, which provide the generators. But maybe we're going to need everything for other stuff; I don't know.

[tvdeyen]

What about option three:

Shipping as engine with all the code and a bunch of generators helping to override a certain file/folder/feature.

Ie.

rails g solidus:frontend:overwrite:checkout

rails g solidus:frontend:overwrite:views

etc.

That way we would have best of both worlds.

Regarding updates: Rails generators have conflict management with visual diffs build in. You can simply run the same generator again and Rails will ask you what to do with customizations.

[jarednorman]

Aha, we submitted basically the same suggestion and almost the same time. 😄

[tvdeyen]

Seems like a good idea then 👍

[kennyadsl]

Just to be clear, are we talking about adding these generators to the extension and not into Solidus, right?

Some other things to consider:

• how do we handle assets? Are frontend assets (which we would like to keep at minimum) distributed via the assets pipeline or copied somehow in the host application? I'm assuming someone wants to use the provided ones with some small changes and someone wants to start from scratch.
• engine's routes are difficult to change/remove in the host application, not sure how we can copy routes in the generator task and even if we could, if someone removes the route in their config/routes.rb file, it will still be available.
• extensions are still relying on deface to add things to the frontend. We can switch to a generator for extensions as well that will just copy partials in the host application, for the frontend at least. It will be responsibility of the developer to decide where to render that partial. In extensions' specs, we can use deface to simulate the inclusion of those partials.

[jarednorman]

I'm not sure how we'd want to handle assets. We could potentially provide both options if we wanted.

Rails generators provide an API to add routes. I don't follow this part of what you said:

[...] if someone removes the route in their config/routes.rb file, it will still be available.

[hrdchz]

I'm liking what @jarednorman and @tvdeyen are saying. In the last year I came from other platforms and learned Rails to use Solidus. I think something that:

• uses standard commands
• populates the folder of "your app" with the necessary code to start customizing

Is a big advantage for the newcomer, because you get to observe the evolution from and empty Rails app, to something with Solidus The Gem installed, to a fully loaded app with a working frontend.

Perhaps it might be an additional convenience to include one blank model decorator with a link to the docs inside it?

It might also be nice if the installer is clever enough to see solidus_auth_devise installed and bring over those views as well.

[aldesantis]

I'm very much against the idea of allowing people to install solidus_starter_frontend as a gem, even just as an alternative to the generator strategy. I think we should be opinionated and make it impossible, or at least very difficult, for people who are new to the platform to make the wrong architectural choice, and we know for a fact that injecting storefront code at runtime is a bad idea, because it's impossible to maintain at scale and in the long run.

In fact, we moved away from providing any storefront-related code in extensions, because there's no way we can provide a sensible default given the variety of styles, technologies and architectures across different Solidus stores. There's even a section in the new guides that discourages extension authors from injecting storefront code of any kind.

All this considered, I think the only option we should provide is the ability to generate a starter storefront via a Rails generator that's provided by solidus_starter_frontend. The generator copies everything into your application and that's it—the storefront becomes your responsibility from then on. As @hrdchz suggested, it would also be nice if the generator was able to detect the presence of solidus_auth_devise and copy over the relevant view customizations.

There's a couple of technical challenges here, but I don't think they're unsolvable:

• As @filippoliverani mentioned, it's weird to install a gem just to run a generator and then remove it. I see a few different paths here:
  • Perhaps we could solve this via Application Templates? Not sure if it's a viable option, because it's a lot of files that we need to copy over and templates need to live in one file (unless we download external files from the Web).
  • Another option would be to explore the possibility of a gem that you can install via gem install but provides a binary which is run within the context of your Rails application—again, not sure how feasible that is, but I think we might be able to work something out.
  • A third option (the easiest), is to let people add the gem to their bundle, and then remove it as the last step of the install generator. This is still weird, but a bit less so because you don't have to do the removal manually.
• The other challenge, which came up in a chat with @kennyadsl, is that providing a generator as the only installation option makes it very annoying to develop the solidus_starter_frontend itself, because you'd need to run the generator inside a dummy app every time you change a file. Again, a couple of solutions here:
  • Allow the gem to act as a regular engine, but only in the development/test environment. If it detects that it's present in a Rails app in the production environment, it crashes the app.
  • Run the generator every time a file is changed via Guard or similar.

Note: I think this should also apply this philosophy to solidus_auth_devise, which right now injects a bunch of routes and views into the host app. This should just be a generator that copies everything into your app.