Feature: Generators for React/Redux files

[aaronvb]

Are there any plans to implement generators for React components, stores, routes, actions, and Redux reducers, etc?

> rails g react_on_rails:react_component BlogPost foo bar
> rails g react_on_rails:react_action BlogPost updateContent updateTitle

Similar to how rails generators work for controllers, models, mails, etc.

> rails g model blog_post title:string content:text
> rails g controller blog_posts new create edit update destroy

[justin808]

We certainly could @aaronvb. Give it a try if you like!

However, even more important would be to move over the latest in the https://github.com/shakacode/react-webpack-rails-tutorial/ over to the generators. Specifically, the switch to CSS modules.

[justin808]

@aaronvb, @jbhatab You guys are thinking of the same thing. Pair up!

[aaronvb]

@jbhatab I'm down to pair up or talk about this. Lmk when there's good time to talk about this over Slack.

[justin808]

@jbhatab posted this to a merged PR

@justin808 @samnang @robwise @alexfedoseev As you would normally expect from me, I have to disagree with the 'rails way' here :P. I think for rails it may make sense, but for gems it doesn't.

Popular gems

https://github.com/plataformatec/simple_form. Simple form doesn't automatically include bootstrap and then allow you not include it.

https://github.com/plataformatec/devise Devise doesn't automatically setup users for you when you install it and then allow you remove it after.

https://github.com/thoughtbot/paperclip#installation Paperclip simply shows you instructions how to set things up and has their installer as a second class citizen.

http://activeadmin.info/docs/documentation.html Active admin follows the devise pattern of having two separate installers.

The most popular gems I know have generic installers that are simple and then sometimes have options that are second class citizens. And sometimes they even use the readme as the core of things.

Similar gems

Now more relevant to what our gem is, here are some good counterparts.

EMBER

https://github.com/emberjs/ember-rails. This is a very similar to gem to what this gem is. They install ember within your rails app. They have one generic installer and 4 options.

--ember-path or -d # custom ember path
--skip-git or -g # skip git keeps
--javascript-engine # engine for javascript (js, coffee or em)
--app-name or -n # custom ember app name

These are very non intrusive options imo compared to what we are doing. Like for us the equivilents would be choosing the custom folder name, skipping git, coffee or es6, and a custom app name. I like those options and they actually stack very well.

BACKBONE

https://github.com/codebrew/backbone-rails This one take an interesting approach I really like. They actually have one default generator and then they have secondary generators for models. Now I could see us having the default generator and then having a secondary generator for redux 'apps' and they can run it repeatedly. That's interesting actually.

https://github.com/meleyal/backbone-on-rails Now this one is closer to us in terms of options but they are secondary to the other backbone one, which I imagine played a part in this. Simialrly to ember js though, there options are much more stackable and are much more 'option' like. They are things like names of the folder, app name, coffee vs es6. I'm fine with as many options as we want for this but hello worlds, bootstrap, and to some extent hot reload doesnt fit in this paradigm. This one does do the same thing as the other backbone gem where they have a repeatable second generator.

POLYMER

https://github.com/alchapone/polymer-rails Polymer follows the same pattern of a simple single generator and then a secondary repeatable generator.

After looking at these I'm actually in support of doing a single simple generator for just the bare minimum files and then having a secondary generator to generate bundles. Then we have a redux or default option for that. Then with that generator we can add more options like flux or alt. I think this approach is the most fitting.

Would love to hear all of your thoughts on this.

[justin808]

@jbhatab I'd like you to take a first crack at how you'd change the generators such that there's 2 generator commands:

1. react_on_rails:install [options]: All the setup, non-bundle options. We can change the defaults to do the simple setup by default. However, since we're setting up the client dir and I consider JS linting 100% essential, we leave that as the default. So basically, we're just changing the default for boopstrap to be off.
2. react_on_rails:bundle bundle_name [options]: This would take basically the hello world bundle and make it possible to run this multiple times to create N bundles. I suggest we default to Redux/No-Redux based on the client/package.json, and that the user can override this, and thus specify either --no-redux or --with-redux to force this.

Some needed options for 1) are:

• --webpack-dev-server to create the setup for the webpack hot reloading dev server. This should be optional given Rails can hot reload now (see https://github.com/shakacode/react-webpack-rails-tutorial/)
• Need to figure out if we still need the simple static assets generator. Basically this says just allow Rails to handle Sass. Since this is somewhat simpler, you could say we should keep this option, and we have the current code for this. On the other hand, the new mechanism allows both CSS modules and hot reloading.

@aaronvb @jbhatab Ball is in your court now. Let me know what you think.

[aaronvb]

I agree with @jbhatab on making the generators more simple and and adding a secondary generator for the bundles.

I think when we first started the generators, we wanted to show people how react_on_rails worked by generating the hello_world bundles for them. It allowed someone to start a project right away with the way we used react_on_rails. Looking forward I don't think there's anything wrong with that approach for people starting with a blank rails app, but for an existing project, I think it could cause more harm(or confusion) than good.

I'm a fan of how devise handles the generators. They provide a base generator install to setup the initializer, and basic structure to integrate devise in a new or existing app, and another generator to create the devise models.

The generator will install an initializer which describes ALL of Devise's configuration options. It is imperative that you take a look at it. When you are done, you are ready to add Devise to any of your models using the generator

---

@justin808 I think that's a great approach, let's do it.

@jbhatab We could also add to that with simple generators that can create components, etc. ie: rails generate react_on_rails:component component_name [options] if you wanted to skip installing the bundle. This would follow the devise and backbone way.

[justin808]

@aaronvb and @jbhatab big, big thanks for taking the lead on this!!!! The community will surely value this! I'm going to be focused on pushing the envelope for features to the core. Maybe there's some way we can get some community fundraising to help pay for your time?

[jbhatab]

@justin808 @aaronvb I still want to address some points before we start coding. I think that just attacking it could lead to some wasted efforts.

Here are my thoughts on what we could do. Would love input and feedback on this.

1. We should remove the concept of hot reloading completely from the generator. It's a preference.
2. We should remove bootstrap completely. It's a preference.
3. We should remove linters completely. It's a preference.
4. We should remove Heroku completely. It's a preference.
5. We should remove npm-shrinkwrap. This is a production issue and shouldn't be addressed in the gem.

[justin808]

@jbhatab, I'm not following you on removing what's working. What's the issue with npm-shrinkwrap?

[jbhatab]

@justin808 I main issues are maintenance, simplicity, and scope in relation to the generators. It has already been complicated to maintain the single installer and adding a component generator compounds that much more. To be able to adapt and keep all of our documentation consistant with ease it would help to remove a lot of these concepts. We can write blogs on a lot of these concepts that show you how to launch react_on_rails with bootstrap, heroku, linters, etc but I think they should be removed from the installer.

[justin808]

Hi @jbhatab. Thanks for the help. Here’s some examples that show the differences between generator runs: https://github.com/shakacode/react_on_rails-generator-results (sorry about some diff noise)

I’m all in favor of the change to make a new bundle generator.

How about if we just do that, as that will be useful to both existing and new installs.

We can discuss removing things later. So long as you can generate the full basic install, and then run the bundle generator, we’re OK.

Maybe create a fresh PR, pushing an empty branch, and we can put down the changes to the README first and agree on that for the new generator.

Please consider creating a simple repo that shows exactly what you want to generate from a given set of options to the bundle generator. That's the best to show this.

[robwise]

Getting webpack and rails to work nicely together is the main goal of people coming to this repo. Watching Blaine try and teach this stuff to people when he screencasts, I'm noticing that it's really difficult for developers to understand what is going on with the amount of stuff we generate that is tangential to just getting started. Also, there's an appreciable maintenance cost to all of it—a cost which is getting increasingly difficult to pay given how busy we are with internal projects.

This is why when I originally made the generators I purposely wrote the code in a way that would make it trivial to remove bootstrap and the linters, with the hopes that one day we would.

One thing missing from Blaine's list is removing the express server code. On an internal project, we tried doing the development on the express server first and then porting it over to the rails server, and it didn't work very well at all. Any changes to the Rails application layout must be duplicated to the express server's jade file to ensure styles will work correctly in both environments. There is a huge amount of code to add in order to get the express server to work, including an entirely fake API that can easily get out of sync with the Rails API (assuming it was ever in sync in the first place).

[jDeppen]

Thanks for creating this awesome project.

Getting webpack and rails to work nicely together is the main goal of people coming to this repo.

I agree with @jbhatab and @robwise on the removals. I've pulled out everything except bootstrap and hot reloading to make it easier to understand how everything works.

Speaking of screencasts, how about a paid screencast series? It could fund some of the work and would probably bring more contributors because the learning curve would be reduced.

Side note: I wonder if it would be helpful to add a second bundle to the tutorial code mostly to show how bundles could interact and how react-router would be configured.

[justin808]

@jbhatab and I discussed this. He's going to create some sample PRs for his upcoming tutorial in terms of what he'd like the generators to do. This will give us a possible idea of how this should work. Here's a simple example: https://github.com/shakacode/react_on_rails-generator-results/pull/227/files. This repo clearly shows what the different options do: https://github.com/shakacode/react_on_rails-generator-results

[thewoolleyman]

@jbhatab also asked me to chime in on this with some of the things I discussed on Slack.

It seems like this discussion is going in the right direction, but I'll try to summarize:

• This stack is very complex and hard to learn and debug, even for experienced web devs. It's a brave new world, turtles all the way down, but such high stacks of turtles! ;)
• So, the generators should definitely support a "bare bones" mode with all "bells and whistles" turned off. This will allow people to easily compare and contrast on their own what exact bits of code are involved in support any given "bell" or "whistle", e.g. hot reloading, or server-side-rendering.
• Each "bell" and "whistle" should ideally be independently configurable/enable-able, per the above point. E.g. I can generate with hot reloading but not server side rendering, or vice versa. AND they should all work independently. This in particular is very difficult to ensure in generators, I think, but still very valuable.
• Any "official" or "promoted" tutorials or blog posts (e.g. ones mentioned in the repo, on Shakacode blogs, or that you refer newbies to in slack or github issues) should be consistent with what the latest versions of the generators generate. Again, this is a very high-maintenance bar to achieve, but it's extremely confusing for newbies to webkit (and I'm talking about my personal experience) to stare for hours at the "example app" and the "generated app", where the webpack configs, structure, and naming conventions are very different, and try to grok exactly which one is the more "canonical" or "preferred" approach.

Sorry this is very hand-wavy and idealistic for someone who doesn't intend to pitch in and make it better, but HTH anyway :)

-- Chad

[justin808]

@thewoolleyman Did you find the https://github.com/shakacode/react_on_rails-generator-results repo helpful?

[thewoolleyman]

I skimmed them, that looks good and a lot like what I suggested!

However, it's still only certain combinations. E.g., skip bootstrap but with server side rendering is not shown. And I know it was discussed above, but it would be great to see examples without the added complexity of hot reloading.

I also notice some "spurious" changes in the comparison branches - e.g. bumping the rails version when it's unrelated to the generator option.

Seems like this should be automate-able? Just have a script that runs through the generator with everything turned off, then commits that to a clean repo on master branch. Then, iterate for each individual option enabled, and commit the changes to a branch, then resetting back to master and repeat. Then, when done, force push all the branches up to an existing or new repo.

And, perhaps one more set of iterations that progressively adds each option in on top of the previous, to catch incompatibilities (at least when options are added in that specific order).

That would also be a great integration test of the generator to ensure it doesn't rot.

And also, a lot of work to implement and maintain. Again, I'm full of suggestions but not time to implement them.

-- Chad

[justin808]

Chad, we have automated this: https://github.com/shakacode/react-on-rails-generator-results-automation. You've always had the commit bit here. 😸

And regarding tests, we have an amazing system that actually runs the generators and runs specs the generated apps.

What's frustrating about this is that @robwise and I did a huge amount of work to get this all going, and we're more than happy to guide somebody to help us, but nobody is volunteering the time to get this done. @yorzi had also helped in the past and did an incredible job. And of course @aaronvb did the initial implementation.

So what we have is extremely solid, but it mainly needs the update of the new recommended way of handling CSS using CSS modules, which also includes hot reloading Rails in dev mode.

Any ideas on how we can fund the development of this? I'm happy to donate ShakaCode's time in doing the code reviews, etc. Plus, this is a great way for new people to get involved in open source.

[thewoolleyman]

Wow, you already have it automated. I had assume it wasn't since some of the branches had pending pull requests (?) We should put a link to that automation repo in the results repo readme (I would but I'm not positive if the generation of the readme itself is automated?)

Yes, the new CSS approach seems to be the crux of a lot of my confusion as well, at least when I was trying to get Jasmine or Karma working.

Also, I think that the "basic" version basis for comparison should be considered to be the absolute minimum "everything turned off", even things that are on by default like bootstrap. That is the least amount of confusion (I opened an issue for this )

As for helping paint the fence, I must continue to be selfishly focused on my current hack project, because that's all I have time for on the side (and not enough of that). But hopefully later this year I may have it to the point I want, and then I will try to consider helping move react_on_rails forward. I think it's very solid and has tons of potential. Once I can focus on it and dig in to finally grok the details (and looking at these generator diffs is a great approach), I can be of more use besides pedantic pontificating.

[aaronvb]

Sorry for the slow responses. Similar to @thewoolleyman, the time I'm volunteering is also between my side project and day-to-day work. A complete rewrite of the generators might be more than my bandwidth can allow, but I want to see this through and will volunteer as much help as I can.

Also, I have some other features I want to see in react_on_rails (like react-stdio as an alternative to therubyracer/execjs) that I want to prioritize as well.

[justin808]

@aaronvb I agree with you that the react-stdio is much more important.

[justin808]

@jbhatab I think we could accomplish your goals with the following as an interim step:

1. Make bootstrap an option rather than the default
2. Make the hot reload server optional since we're not rails hot loading. I prefer not to remove it since it is really good for certain uses cases of prototyping.
3. Make the hello_world string a parameter so you can call it "todos" or "blogs" etc.

With just those small changes you'll be able to create a simple Rails app, and you can rely on the asset pipeline for assets (css, css images, etc.).

Let me know what you think of that.

I will later change the bootstrap option to bootstrap-loader and use the new Rails hot reloading.

[jbhatab]

@justin808 I think making things optional is great. The only remaining issue would be multi options support. If we add the component generator and it needs to support server rendering, client rendering, bootstrap, hot reloading, and linting as options then it will have to have a ton of options that will be hard to maintain.

Also, what do you think about moving things like the hot reloader and bootstrap setup to a blog or wiki? That way it doesn't need to be so precise and people can adapt it to their needs.

[justin808]

Having worked intensely on this:

Also, what do you think about moving things like the hot reloader and bootstrap setup to a blog or wiki? That way it doesn't need to be so precise and people can adapt it to their needs.

I don't see any need to throw it away. It needs to be updated to the latest. On the to-do list.

[jbhatab]

@justin808 I respect and appreciate the previous work but I want to make sure that looking forward we can make the most pragmatic decisions to make the gem the best experience for the people using it.

I don't think we need to throw it away but it is very difficult and time consuming to keep them in. If you keep things like the hot loader and bootstrap in the default generator as options then you need to have those corresponding options on the component generator. It also makes maintaining the giant blogs, tutorials, and examples quite difficult. If we just had modular blogs, we may not even need to update them all as we transition through various versions of the gem. The core of them would still be the same and people would figure out how to apply them to their projects as needed. It also opens up flexibility for us to have other small blogs like integration of foundation 6 or material into react_on_rails without having to change the core of the gem.

[jbhatab]

I made some example generators for the installer and component generator.

https://github.com/jbhatab/react_on_rails-generators.

They are in the pull requests if anyone wants to look it over.

[seoyoochan]

I agree with @jbhatab. If the default generator includes bootstrap as options, then people will look forward to adding other libraries as options like Materialize, Foundation, etc. I think it's expensive to keep the hot reloader in the default generator. it'd be worth lowering the high maintenance bar with reducing several options.

[justin808]

@seoyoochan Let me know if you want an invite to our slack room. We're looking for more code contributors!

[seoyoochan]

@justin808 sure. invite me with supergnee@gmail.com

[agmcleod]

Curious on something with this. Love the idea of generators for react & redux files, but im wondering if the install generator this has now should keep the hello world components. It's great to have examples, but can be a lot to cleanup/rename as well.

[jbhatab]

@agmcleod we are slowly building towards this. Right now we are stripping the main installer down of options so the component generator will be more manageable. We'll be removing the hello world component in the installer generator when we add this in.

[seoyoochan]

@agmcleod yeah, ideally, the hello world examples should be easily named by the name argument that user passed in when he activated the install generator.

[agmcleod]

Awesome, love to hear it. Very cool project so far, as i'm digging through it. Hats off to you all :)

[jbhatab]

@seoyoochan @agmcleod feel free to message me on the shakacode slack. My username is blaine.

[patrickgordon]

Love where this project is heading.

Agree with one of the earlier comments about the difficulty of bringing this in to an existing project, particularly the introduction of all the HelloWorld items. I appreciate why it is done but not great for existing projects IMO.

Also fond of the idea of including generators for creating components & redux actions.

Keep up the good work!!

[justin808]

Hi @patrickgordon, we've got a plan for breaking up the current generator into something more suited to both existing and new projects. Personally, I've been focused on the core functionality. @jbhatab is helping with the generator work.

For anybody interested in helping, we're always super happy to have more join the party!

[patrickgordon]

Cool @justin808

I'd offer to help but I'm a bit of a hobbyist programmer and would probably hinder more than help 😄

[wearethefoos]

Hi, I was looking for generators to generate bundles. Seems I was a bit late to the game with the idea to make some generators. I totally feel like the approach mentioned by @justin808 in issuecomment-186682640 seems like a good idea, but wouldn't it be good to put the generators in a separate gem?

A lot of people (purists? 😄) don't like to use generators, but if you want to build - say - a quick MVP, you could optionally install the react_on_rails_generators gem. That way it's not in the way of future development of this awesome! project, and we could slowly develop on it (happy to help where I can) and even have it hook into the default rails scaffold generators if that's what people want.

We could use the Comments example here as a starting point: https://github.com/shakacode/react-webpack-rails-tutorial for --with-redux maybe?

I know I'm repeating stuff that was already mentioned here, but for the sake of clarity I hope.

Either way, great stuff here, thank you. And happy to help develop some basic generator gem to start with.

[patrickgordon]

@foxycoder Interesting to move it to a separate gem... Is this a common practice? I'd be interested in some other examples if you know of any.

[justin808]

@foxycoder @patrickgordon Stay tuned. @jbhatab and I are actively working on this.

[justin808]

@jbhatab is actively working on this. Should we leave this open for now?

[wearethefoos]

To improve the React experience for many people it could be nice to have a
basic CRUD app that people can extend in their apps. That could be great to
familiarize Rails developers with things like Redux, while seamlessly
integrating with the "Rails way" of building RESTful apps.

Again, happy to help with this. :)

[justin808]

@jbhatab @foxycoder @patrickgordon Let's get the next stage of the generator going.

Should we close this issue, as it's a lot of scrolling at this point. I'm thinking a new issue where we build off of what's in V6 would be better.

[justin808]

@jbhatab Any update?

[justin808]

@jbhatab @foxycoder @patrickgordon, please see #584 where we're updating the redux example.

[justin808]

@Luke-Popwell

not sure if this is the right way to add to this, but i put this gem together yesterday to be able to add component and container generators to the react_on_rails gem. It's the first gem I've tried to build, but any feedback would be appreciated. https://rubygems.org/gems/redux-gem and heres the github link https://github.com/Luke-Popwell/redux-rails-gem

#681

Let's make this a PR!