4 ms·
Overall, I think React is a great step forward in supporting isomorphic apps. The last hurdle, at least for me, is its limited support for asynchronous renderin
by Todd 12y ago
Overall, I think React is a great step forward in supporting isomorphic apps. The last hurdle, at least for me, is its limited support for asynchronous rendering server side.
The biggest problem is that renderToString follows a different component life-cycle path. In particular, componentDidMount isn't called. Although this makes sense (there is no actual DOM to mount, just the virtual DOM), this is typically where server-side interaction is handled. Without this life-cycle hook, it's more difficult to build components that behave similarly on the client and the server.
In addition, one must set up abstractions around things like API request transports (e.g., jQuery on the client and request on the server) that have different environmental requirements. This part is more manageable.
- andrewingram 12y agoI just use superagent for requests, works fine on client and server.
- deleted 12y ago[deleted]
- insin 12y agoThe fact that componentDidMount only gets called on the client seems like it would make it a good place to hook up progressive enhancement after rendering a basic isomorphic version on the server (e.g. a <select multiple> which you enhance with dynamic features only when JavaScript runs on the client) - for server rendering, it would be too late as you only get one render and need to do everything up front. I've been playing [1] with isomorphic forms using react-router - it uses a static willTransitionTo() hook on the constructor of components which do route handling for the equivalent of request handling, which seems to work well in the limited cases I've tried so far. For API requests, you can use a request library which has the same API on client and server - superagent and axios seem to work well. [1] https://isomorphic-lab.herokuapp.com/addthing https://isomorphic-lab.herokuapp.com/addthing
- Todd 12y agoI'm also using react-router. I've been pretty happy with it. I will take a look at willTransitionTo again. In the meantime, I'm doing what you suggest--rendering a basic initial view. In the end, you are only going to be able to go so far on the server before you have to wait for the client side mounting event. You can render a complete page, with forms and the rest, but it won't be interactive until the mount anyway.
- insin 12y agoIt can be! That's one of the the benefits of the isomorphic approach - for the bits you want to use it in, it should degrade to regular forms 'n links round-tripping.
- williamcotton 12y agoKeep your server-side interactions (aka state) outside of the scope of your components and pass in data as properties. There is an intrinsic connection between state and external environment that must be grasped before you can start building isomorphic modules. I'm not sure why jQuery and React would ever be used in the same project. If you want an isomorphic solution to retrieving data check out https://www.npmjs.com/package/browser-request https://www.npmjs.com/package/browser-request and enable and convince 3rd parties to enable CORS on HTTP endpoints.
- Todd 12y agoYou make valid points and, in general, the top-down prop passing convention is the recommended approach with React. This works well if most of your state can be managed client-side with, e.g., Flux stores. There are some cases, though, such as large scale paginated data sets, that require out-of-band requests to a service (even if they are managed through stores). This is the case that's problematic. For these components, I just render out scaffolding and a loading indicator. Thanks for the recommendation. The only reason for jQuery is the occasional external dependency and the XHR wrapper.