make server asset pipe-line and pre-rerendering agnostic relative to framework and gems

[catmando]

Currently full server support is only "easily" done by using the react-rails gem.

So if you want pre-rerendering in any situation where you cannot use react-rails you have to brew your own. For example Sinatra or if you want to use react_on_rails gem.

Likewise for the asset-pipeline.

Instead we need to devise some API that can used to easily build an adapter for any environment.

The below are just initial thoughts...

Looking at this from the existing functionality here is an initial list (some things might be missing) that we have to support:

render_component method which calls the lower level react_component methods

providing the mechanism to deliver shared .rb code (i.e. from views/components directory, and from models/public director if using reactive-record) and client only code.

I believe only the react_component method depends on react-rails. The rest is standard opal-rails stuff.

react_component works by passing all the rendering params, the controller, and the name of the component as a hash to a single "top level" component, that finds the actual component from the component name + controller, and then passes the params.

There are some other things that go on before generating the top level component that implement the mechanisms in React::IsomorphicHelpers, which allow data to be shared (and recorded) during prerendering, and then delivered to to the client.

Probably the biggest piece of the puzzle, is making React::IsomorphicHelpers independent of any react-rails assumptions. This should be quite doable

[RedFred7]

I fully concur with this. As someone who uses Sinatra and Cuba more often than Rails, I'd love to be able to use reactive-ruby without having to shoehorn it into my app. A generator task for non-rails projects would be ideal.

[catmando]

From a discussion from the chat area it would seem the best approach is to divide this into separate gems:

reactrb-prererendering-support that takes provides anything a prererendering pipeline needs (i.e. getting server context information, and providing isomorphic helpers, etc)

reactrb-rails that uses reactrb-prerendering-support to integrate with rails...
reactrb-sinatra that integrates with sinatra...

etc

gems like reactive-record can then just require reactrb-prerendering-support and be framework agnostic.

The advantage of having two gems is that the prerendering support would not be included in the base payload for apps that are not doing prererendering.

[sollycatprint]

This issue was moved to ruby-hyperloop/hyper-react#129