Merging react-rails and react_on_rails?

[justin808]

Would it make any sense to consider merging react-rails and react_on_rails?

A long time ago, Merb merged with Rails:

• https://yehudakatz.com/2008/12/23/rails-and-merb-merge/
• https://rubyonrails.org/2008/12/23/merb-gets-merged-into-rails-3

Data Points

1. The core API of react_component is essentially the same, react_component
2. Both projects should leverage https://github.com/shakacode/shakapacker as much as possible

What else?

I think we can build more together than working separately.

[BookOfGreg]

Hi Justin,

I hope you'll allow me to clear the air for a moment as it may be confusing as to why I keep ignoring you and how I want this to change going forward.

Having seen some of your conference talks about React-rails and react-on-rails from years ago, at the time I was not comfortable with the idea of you contributing in a major way to this gem, as I did not feel at the time that the philosophy of maximalism and common breaking changes shown on react-on-rails was compatible with the more low touch approach of react-rails. I also did not like some of the 'better than you' attitude of the past from those conferences, and even though I respect you must drum up support to fund your business, please respect that I felt it was overly aggressive and disrespectful at the time. For me open source is about working and building together and I felt you were trying to knock this down.

That being said however, times change and it has been years I think it's time I put ego aside and hear you out here.

What is it that you are proposing, and where is a good venue to discuss what this could mean for both us and these communities in your mind?

[justin808]

Hi Greg!

Awesome to hear. Let's jump on zoom sometime and see how we can work together.

And yes, many things have changed!

Feel free to book a time.

Or jump on our React Plus Rails slack.

In terms of a merge, I think we'd want to:

1. Ensure a smooth migration
2. spell out what would not be supported
3. Ensure smooth integration with https://github.com/shakacode/shakapacker

@BookOfGreg, what features in react-rails should be deprecated?

For example, I think there should be an explicit move away from including React from the asset pipeline/sprockets and using shakapacker.

The UJS part is something that I'd need help with.

Other parts like SSR and view helpers are mostly 1:1 between the projects, with React on Rails providing a bit more.

Should we skip the component generator as too bound to a particular style of React?

Overall, I find this very exciting! 😄

[radiantshaw]

@BookOfGreg @justin808 Sorry to jump in the conversation midway but I wanted to add a few points which might be worth considering.

• Removing any bundler dependency (like rails/webpacker or shakacode/shakapacker, or any other bundler like esbuild or rollup)
• Having React and ReactDOM as peer dependencies (in a general sense; not like adding it inside the "peerDependencies" array inside package.json)

What that allows the consumers of this package to do is:

• Use either of the following: webpacker, shakapacker, Import Maps, Sprockets (and Propshaft probably later when it's stable)
• Use any React/ReactDOM version

I do have some ideas on how we can do it theoretically, but the practical aspects might be different as we have to see what's possible and what's not. So feel free to discuss anything.

[justin808]

Hi @BookOfGreg, What's the next step?

I think we should do a big cleanup of old issues and pending PRs.

How can I help?

[radiantshaw]

@BookOfGreg @justin808 Any updates on this?

[justin808]

Earlier this year, I was focused on Webpacker ==> https://github.com/shakacode/shakapacker.

I'm open to spending more time in the future figuring out how react-rails and react_on_rails will both serve the Rails community over the short and long term.

Please do join our React Rails Slack.