Separation of concerns

[dts]

I dig this example for a couple of important reasons, the structure is sensible, extensible and quite great. The big problem that I have with it is that a few of the core technologies are baked in very deeply, and to really get much use out of it, there is a very steep learning curve, involving reading a lot of 3rd party code. I would love to see a package evolve out of this stack that hides a lot of the details - it assumes the src/{components,helpers,containers,redux,theme,utils} structure, and does a sensible thing with it. There are a few core issues that I have been having that are small in scope and probably easy to tweak. I am pretty new at a lot of the core technologies here, but as a newcomer I feel it's my job to highlight the things that I find "weird" or "surprising". If they turn out to be good and/or essential then I'm happy to learn and adopt these things, but coming from a ruby/rails background, it kind of surprises me how much "glue" is involved in day-to-day node projects. Am I missing something? I find it difficult to justify needing to understand on a deep level all of the libraries that I use. Can't we simplify and/or standardize the APIs in such a way that I don't need to constantly refer back to source code in order to explain surprising behavior?

I don't mean to be inflammatory or anything, I am honestly trying to get an understanding of the npm ecosystem - I have just found it to be more jarring than I expected.

[adamsoffer]

@dts I totally agree. I'm also a newcomer and it's been a jarring experience wading through all the glue and third party code. I think abstracting some of the details into a package would make the starterkit more palatable for developers foraying into a universal redux app.

[NotBrianZach]

Personally, (also as a relative newcomer) I liked that the project included examples of how one could handle form and css styles, respectively.

[merriam]

I agree that we should add more help for newcomers. I'm working on a couple guides; c.f. #724 or Exploring the App for an example.

The kit is evolving rapidly and one could reasonably expect the extra file proliferation and large number of modules to slowly trim down. For example, a year ago there would have been Gulp or Grunt in the mix. I would be surprised to see any scss files or style loaders next year.

[bdefore]

@dts what you're describing sounds like very much the motivation i had for creating https://github.com/bdefore/universal-redux and submitting #626 and #685 ... I'd be curious to hear what you think.

[dts]

@bdefore that looks quite interesting, I haven't had a chance to try it out, but based on what I can see this is exactly what I'm asking for, so that's great! The question that occurs to me immediately is how easily it would accommodate tailor-made extensions, which would add functionality. Removing features until you're left with "the basics", which it looks like you may already have done. At that point, having extensions that work together with universal-redux to add features like react-hot-loader to the stack without needting to glue everything together.

[bdefore]

@dts thanks for having a look. there is already some amount of customization that is supported, primarily focused on Redux and Express middleware. it's documented more here: https://github.com/bdefore/universal-redux#customization. i would love to get more feedback about how people are using it (or this project) as a base in order to glean what additional customization needs there are.

the example you mention, react-hot-loader, is trickier. at this point, react-transform-hmr (successor to react-hot-loader) is built into universal-redux, since it is core to the functionality and should be as much as possible abstracted away from the developer.

[catamphetamine]

this whole thing is evolving too rapidly at the moment. yesterday you used flummox, today you hear of redux, tomorrow some kind of falcor or relay emerges. and react-router is already out of date the next week, and redux-router is declared stale, etc. it's chaos. when stability time will be half a year at least then there will be frameworks.

[catamphetamine]

(every time you masturbate another javascript framework is declared obsolete)

[catamphetamine]

Anyway, i thought about this issue too and wrote my very own react-redux library which incorporates a big chunk of the code from this project. https://github.com/halt-hammerzeit/react-isomorphic-render You can do something similar. The only question is what should be a part of such a library: incorporate too much and it will suit noone, incorporate too little and it won't solve the issue. UNIX way ftw + Charles Darwin way.

[dts]

I hear it, @halt-hammerzeit. I am giving @bdefore's solution (https://github.com/bdefore/universal-redux) a try, it appears to be a more mature set of things (I couldn't find anything about deployment/production in yours). We can fight to reduce the fragmentation by working on things that already exist, instead of constantly rolling our own. Is there a way we can merge universal-redux and react-isomorphic-render?

[catamphetamine]

@dts mine doesn't aim to give the user deployment facilities at all. it's just a react-redux isomorphic rendering facility.

[nicolabortignon]

Jokes aside, (although the one about the correlation between masturbation and Javascript framework dismissal made my day), it would be great to take the chance to draft a common gole and work together in either drive an existing framework to a better stage, or create a new one (only if there are no doable alternatives)

[bdefore]

Thanks @halt-hammerzeit ... it's great to see someone else taking a stab at it. You are absolutely right that the balance is tricky around how much you incorporate. I'd love to hear your feedback on mine. I'll have a further look at yours later tonight, but at a quick glance I'm keen on your separation into pieces that just focus on the isomorphic rendering. I'd been considering moving in that direction myself, and I could see pulling some of those into my package if they were their own modules.

[bdefore]

Also, in a bit of irony given the timing of these comments, React Router 2.0 release candidate just dropped. That's certainly going to have a ripple through redux-router and redux-simple-router. And I'm hoping it fixes an issue I'm having getting prefetching to work: https://github.com/bdefore/universal-redux/issues/16

[catamphetamine]

@bdefore I looked through your project and I think that it could be difficult to integrate my library into your project. They are very similar (clones) and I think there's no need for you to use my library because your code is absolutely the same. That's for you to decide of course.

As for the voting, I'm voting for @bdefore library then. All the issues will be reported in this repo, but all the commits will go to that npm module repo.

[bdefore]

React Router 2.0 support is now released and I've bumped to 3.0.0-beta1 (RR1 support will stay in 2.x)

@halt-hammerzeit for my next release i'd like to enable koa support (while maintaining support for express). it shouldn't really require much of a transport between them. i'd love to get your feedback for the general approach on https://github.com/bdefore/universal-redux/issues/25

[chosenvictim]

@bdefore Any update on Koa support ?

Edit: Sorry my bad, later i noticed that you have put koa support in your universal-redux. Thanks a ton for that. You are awesome.