I was working in my Redux app today and was facing the question of how best to submit a “create” API call to the backend and then transition to a “confirm” page. I wired up my router to be sensitive to the Redux store, so a reducer could trigger the page change. I’m using redux-pack to handle async events, which I find quite pleasant so far (though I haven’t gotten deep into testing it, which is a bit awkward because it requires faking out some internals). One solution is to have the component that is handling the “submit” button dispatch the API call action and then use the Promise that redux-thunk provides as a return value to chain the router action. But, the Promise will always resolve when the action completes, even if the API call was not successful, leading to some awkwardness in detecting if the create actually happened without error before doing the redirect. I also have a fantasy of generically dispatching actions via POSTs on the backend (“isomorphic Redux,” if you w
I’ve been building a toy app to feel out server-side React, Redux, GraphQL, &c . to explore ways to build my next webapp(s). One thing this has introduced me to is react-router . react-router has good support for SSR because it lets you statically determine the set of Component classes that match a route so that you can load their data before rendering them. Its route descriptions allow nesting, which translates interestingly to your rendered UI. Here’s my routes.js file: <Route path="/" > <IndexRedirect to="/rails/rails" /> <Route path=":ownerName/:repoName" component={App}> <IndexRoute component={IssueListPage} /> <Route path=":number" component={IssuePage} /> </Route> </Route> This is used to make pages that look something like these: (When in doubt, make a GitHub viewer.) The App component renders the header with the repo name, and react-router passes it a child component,