API Clarifications

[bdefore]

API Clarifications

[dts]

And I forgot about:

4. Is there a plan to support app-splitting in the way that react-router is designed to support? It seems reasonable to assume that there is a reasonable way to split up the redux components in a similar way.

[dts]

VIs-a-vis 2), I just spotted the section in the readme (derrr) that explains this a bit. Does this solution mean there is now one entrypoint for the app? When you type npm run dev, how does it know about the right entrypoint?

[bdefore]

1. This is where the react-redux-universal-hot-example project had fetchData and fetchDataDeferred along with some logic to manage the serverside rendering. Unfortunately it's not working with redux-simple-router and so I've disabled it for now, see #16. I expect we'll be seeing React Router 1.1.0 drop very shortly in which case a solution should follow shortly for that issue. That said, I'm not sure if I'll take the same approach, vs. building out my own. I'd like it to be as transparent for project developers as possible.

2. I think you've figured out how to add Express middleware now. Effectively there is one Webpack entrypoint (main) to the app, but you can specify Express routes independently of that. For example, in my JWT example, I respond to any calls with /api by passing through through a proxy API.

3. That's an interesting idea, but I think I'd be wary of wrapping history that way, as it's changing so fast. Within your project, you can do import { pushPath } from 'redux-simple-router'; then map pushPath to state via connect, and then call this.props.pushPath('/your/path'); ... an example repo showing this route changing would be very helpful.

4. I have not considered any plans for app splitting in the same project that is using a single universal-redux dependency. I was thinking along the lines that multiple apps would be their own projects, and whatever shared code they had would be managed through npm dependencies.

Good questions @dts, let me know if I didn't explain enough.

[dts]

I think 1) needs to be done in as simplistic of a way as possible. Resource retrieval is an insanely complicated problem, and different users will need to support different levels of complexity. I'd make sure there are convenient hooks in place and make sure that it is relatively easy to build out different extensions for resource retrieval. Making this baked in somehow makes it harder for different users to build out different styles of asynchronicity. Making sure that this exists is a 100% requirement IMHO - delivering ready-to-display markup in most cases is the big reason I am moving to universal js.

2. Yep.

3. Importing push path from redux-simple-router is satisfactory.

4. App splitting is a relatively important piece that should not be super difficult in principle. Splitting apps the way you describe is more ungainly, and means that you can't hyper-optimize the apps. In my mind, I'd like to build my apps so that every page is treated as a different app loading piece, so as you navigate you keep getting new snippets of code that drive each piece - not the whole app up front.

[bdefore]

As for 1) I agree that it's very important, and something well within what universal-redux should offer. I did some exploring this morning using react-fetcher (https://github.com/bdefore/universal-redux/tree/react-fetcher) ... but it will need some resolutions in React Router to be fully working.

As for 4) I'd be curious to hear more about what you're speaking of. I would think you could add more entries in additional custom webpack configurations, but I'm unaware of any implications to React Router. Or perhaps have an minimal example running independent of Universal Redux that I could test with?

[dts]

1. react-fetcher takes one approach, but I suspect that this is a component that developers will want to customize a bit more heavily than a one-size-fits-all. The basic requirement on the UR side is to have a hook in the routing stack that lets components say "wait for me!"

For 4), https://github.com/mattkrick/meatier/ does this, and webpack supports it trivially. https://github.com/rackt/react-router/tree/master/examples/huge-apps is the canonical example that the react-router guys give - basically, you split the routing into separate dependencies that are loaded as those parts of the trees are loaded.

[dts]

For 4), I think the correct thing to do is to add support for https://github.com/yelouafi/redux-saga, if the user is using it, and "wait" for any sagas that are active when rendering to complete before sending the resulting data to the client.

[bdefore]

@dts Closing this for now, but feel free to create new issues for what remains in this discussion, which I see being a universal fetching implementation, and RR friendly app-splitting.