[suggestion] split reaction-core into modules

[newsiberian]

Hello reaction community.

There is a similar issue, but I've decided to open new issue, because I think this suggestion is more wide.

I am a newbie in Reaction, in Meteor and in programming, but I already have a suggestion to split reaction-core into modules and I am going to describe three reasons why it should be done. Please do not throw stones at me, if my suggestion would be silly.;)

There is a challenge before me to create a website with an integrated shop on Meteor platform, but the shop should be only one part of the website, available through url like «/shop». In the dashboard, it must also become the only one of the partitions, along with sections such as the articles, forum, etc. At the moment I have not found an opportunity to do something similar with the reaction-core out of the box, and as I understand by default it is not suitable for installation in any other system.

The second reason - as the UI Framework I should use Semantic UI, whose feature, as you know is a cool class naming. Also I need a custom design. I read about the possibility of creation themes for the Reaction, which in my opinion is not really suitable for the integration of Semantic UI. The only way to do that now is to use aldeed: template-extension, as did the author of reaction-foundation-theme. But this way is inconvenient for developers, because they will have to keep a track of changes in reaction-core templates.

The third reason - the application must be based on React, that involves the use of a kadira:flow-router or reactrouter:react-router, and again I need to change something in the reaction-core to move Reaction on React.

It is possible that I have missed the basic idea, and the challenges that are in front of me still can be resolved without modification of the basic reaction-core.

[aaronjudd]

Hi, Welcome and thanks for the great input. Why do I say great input? Because we're actually doing exactly this over this next release. reaction-accounts is taking the accounts UI templates, while we're going to move the templates into a core-templates package. We'll actually use this issue to track that - it's probably mentioned as a few issues, but I don't think there is a specific task for this.

I've been toying with moving the router as well, as there should be an easy way to swap routers but I've been wanting to move slowly there, so see how flow-router progresses, and also to see if Meteor is going to start providing some routing functionality as part of meteor core (there has been some community discussions about this, but I'd like to see it resolved a bit more).

Over the next release or two, I'd also like to see our packages move to a more general use case, for instance, where you could easily use reaction-paypal as your paypal package for a non-reaction, meteor package.

[aaronjudd]

We decided to hold off on moving templates out of core for a future release, as part of a layout/CMS solution. Still a good idea, but moving to backlog.

[newsiberian]

Hello reaction team.

This issue is very important for us, so we want to try to do research in this direction and may be suggest some changes if we will get any results.

The first and biggest difficulty is a routing which is deeply included in many reaction packages.
@aaronjudd have you considered the possibility of moving to flow-router? Anyway, we want to ask you about your vision on how to move all routing stuff (from all packages) to separate package?

[aaronjudd]

Very open to suggestions. I have the feeling that an official routing package may be on the way from Meteor, but can't confirm that. That's one of my hesitations right now. As well as I still am not convinced that flow-router is a better solution either (would love to hear why you think it's better - or maybe it's just a per project choice). We're relying more on our package registry tooling to identify routing, templates, etc now, so I do think that in the near future we should be able to pull routing out, and make it optional - so we'd rely on the packageRegistry to identify the routes, and then we could replace the routing package, and not have package include routing themselves (but let the package registry + specific reaction router package to register routes with different routers.) My goal is that any meteor package should only need an addition of a reaction registry file, to configure itself to work with reaction.

Just because I moved this to backlog doesn't make it any less of a priority - it's something I'd still like to do - but we'd like to focus on completing the core feature set right now. Really just trying to make it clear (in the waffle board) what our priorities are right now. The 0.9.0 had a lot of changes as well, and I felt like this was too much for that release, and the main goal was to make sure we are starting to give a solid stable base for development.

In any case, open to proposals...

[newsiberian]

@aaronjudd, thanks for quick response and for having brought into your plans.

As I mentioned in first post we do not have enough experience and for now we're guided by blog posts, etc. Here are two short opinions: first from Sashko, and second from Arunoda if you interested.

But the one thing is for sure – the flow router can support both: blaze and react, so with a flow router now will be easy to make reaction-templates-react in future.

Separately want to mention React. We have a feeling that React captures frontend market. And we beleave that in future there will be a lot of requests from people about making Reaction compatible with React. And maybe we are the first of them;)

[aaronjudd]

See #502 for work on splitting router out of core, and removing routing depenencies from packages.

[aaronjudd]

This is in progress, slowly, surely.

[aaronjudd]

Flow Router is implemented in https://github.com/reactioncommerce/reaction/tree/features-v0.12