Closed oyeanuj closed 7 years ago
Hi @oyeanuj! Thanks for checking out this project.
Just want to clarify, are you looking for migration guide? Or what kind of guides that you are looking for?
@xkawi A migration guide would be amazing given that it could benefit a lot of people coming from https://github.com/erikras/react-redux-universal-hot-example/issues/1184.
But if thats too much effort, I was hoping to see the previous commits of changes you made from the earlier repo.
I am particularly interested in moving from the custom clientMiddleware and action-creator conventions to redux-saga, and seeing how to incorporate it with SSR.
Any of it is appreciated :)
unfortunately, I do not have any previous commits, though the short answer would be, I simply remove the duck pattern that resides in src/redux
and put redux-saga's real-world example structure in.
Though I could share some insights that I had when putting things together for this project.
Since clientMiddleware and action-creator is replaced by redux-saga (you can literally delete those portions from the codebase), writing side effect requires only 2 things, the actions and saga routines.
To illustrate this, if you look at src/actions/index.js
, there is loadUserPage
function (dispatched at src/containers/UserPage
) that returns action type of "LOAD_USER_PAGE". There is no other part of the codes that uses "LOAD_USER_PAGE" constant, except watchLoadUserPage
function in src/sagas/index.js
.
This simply means that, you have a saga routine that listen to action.type="LOAD_USER_PAGE"
and trigger a few side effects afterwards (in this case, it load user's repos and starred repos, and update the state once result is received, which trigger the re-render). These side effects can be any logic, it can be making multiple network calls, handling the result of the network call, dispatch other functions, or update reducers, and so on. You can think of it like, when A event/action type is triggered, what are the things that need to happen? you answer this with a few lines of codes in 1 single function and 1 single file, src/saga/index.js
.
This gives a better separation of concern:
src/reducers/index.js
(of course you can break the reducers down into separate files, so long it is combined and exported in index.js)To learn more about writing saga routines, feel free to spend sometime picking redux-saga, their official documentation should be enough to get used to it. http://yelouafi.github.io/redux-saga/
In terms of configuring redux-saga into your project, you can simply follow its real-world's example structure. You write the createStore function, attached some middlewares, and so on. In fact, redux-saga is just a redux middleware.
The trade-off here is that, you do not have the "duck" pattern, where everything is categorised into modules. Though IMO, it is a reasonable trade-off, because it can give a better separation of concerns, hence a more maintainable codebase in my opinion. This is subjective of course, and it always depends on the project requirement at hand. I am also happy to share that, the project that I built base on this, have been deployed and maintained for few months now, and there isn't major hiccups so far.
In terms of migrating your existing project, my take would be - if it is too much headache - you can reimplement your project from the start using react-universal-saga as base, and slowly port over the dump components that are reusable, followed by the actions, reducers, an then the containers. Ensure that everything is working fine, where dispatching an action would update reducers and trigger re-render. After that, then you can explore more on how you can use redux-saga to benefit your project.
If all this sounds intimidating, feel free to explore other alternatives mentioned in readme. Think those alternatives are worth checking out as well. 😃
Hope this give some lights in migrating your existing project. cheers.
@xkawi Thank you so much for this detailed guide! This is a perfect starting point, and what I was looking for.. I'll try it out and report back the results.
In the meanwhile, I'd love to see the categorization pattern you've mentioned and the project you mentioned here :
The trade-off here is that, you do not have the "duck" pattern, where everything is categorised into modules. Though IMO, it is a reasonable trade-off, because it can give a better separation of concerns, hence a more maintainable codebase in my opinion. This is subjective of course, and it always depends on the project requirement at hand. I am also happy to share that, the project that I built base on this, have been deployed and maintained for few months now, and there isn't major hiccups so far.
Thank you!
@oyeanuj The duck pattern that I was referring to is this one: https://github.com/erikras/ducks-modular-redux
react-redux-universal-hot-example is using this pattern to structure its codes: https://github.com/erikras/react-redux-universal-hot-example/tree/master/src/redux/modules
Essentially, react-universal-saga does not use this pattern, hence the trade-off I mentioned earlier.
I will leave this issue open for awhile, in case others would like to chime in as well.
Hi @xkawi! Thanks for creating this project!
I started my project with https://github.com/erikras/react-redux-universal-hot-example as well and was looking to potentially migrate to yours. It seems like the biggest change is around migrating to redux-saga and making it work on the server-side.
Are there any previous commits, guides or wisdom that you can share given that this project also started off from that repo?
Thank you!