4 ms·

If you use Redux and React server side rendering, you can quite easily wrap forms/interactions on your page with a <form /> tag and a hidden input with the Redu

If you use Redux and React server side rendering, you can quite easily wrap forms/interactions on your page with a <form /> tag and a hidden input with the Redux action name, and then handle the actions/reducers on the server. I've played around with it in the past and managed to convert a SPA which was using redux-form heavily to work fully without Javascript enabled, and it was only like ~200sloc.

RussianCow 9y ago
I wouldn't say it's "quite easily" done. The most obvious challenge is components that depend on data loaded asynchronously: If the only thing the component renders is a "loading" message while it fetches something from an API, that's all that the server is going to render as well. So you have to figure out a way to render asynchronously on the server-side, and then you also have to come up with a generic way to handle cookies, redirects, fallbacks for interactive features, etc. So it might be easy for really simple apps, but it gets incredibly involved as your app becomes more complex. The nice thing about this, though, is that most of the work happens up front, and as long as you develop the app within the proper constraints, server-side rendering is more or less "free" after that.
- madjam002 9y ago
  Agreed, but the overhead of coming up with "generic" ways to handle all of these interactive features like data fetching, redirects, etc, isn't that big (at least from what I've experienced). It's good to have a standardised way of doing all of those things anyway, and when you do, you can make sure they all work on the server.
  - RussianCow 9y ago
    I don't agree. Dealing with asynchronous API calls in a generic manner is, in my experience, non-trivial. It's been a little while since I've tried it, so maybe things have changed, but when I tried this, the React server rendering API converted the immediate rendering of the component to a string, which means you effectively have to pre-load all the relevant data outside the React app, which may be really difficult depending on how you've architected your app. All the other stuff is pretty easy, though. :)

RussianCow 9y ago

I wouldn't say it's "quite easily" done. The most obvious challenge is components that depend on data loaded asynchronously: If the only thing the component renders is a "loading" message while it fetches something from an API, that's all that the server is going to render as well. So you have to figure out a way to render asynchronously on the server-side, and then you also have to come up with a generic way to handle cookies, redirects, fallbacks for interactive features, etc. So it might be easy for really simple apps, but it gets incredibly involved as your app becomes more complex. The nice thing about this, though, is that most of the work happens up front, and as long as you develop the app within the proper constraints, server-side rendering is more or less "free" after that.

madjam002 9y ago
Agreed, but the overhead of coming up with "generic" ways to handle all of these interactive features like data fetching, redirects, etc, isn't that big (at least from what I've experienced). It's good to have a standardised way of doing all of those things anyway, and when you do, you can make sure they all work on the server.
- RussianCow 9y ago
  I don't agree. Dealing with asynchronous API calls in a generic manner is, in my experience, non-trivial. It's been a little while since I've tried it, so maybe things have changed, but when I tried this, the React server rendering API converted the immediate rendering of the component to a string, which means you effectively have to pre-load all the relevant data outside the React app, which may be really difficult depending on how you've architected your app. All the other stuff is pretty easy, though. :)