Practical Redux, Part 1: Redux-ORM Basics about marks-dev-blog-comments HOT 6 OPEN

Original author: Liam Doran @liam_doran
Original date: 2016-12-06T19:14:19Z

Thanks for doing this series! I had a question on the "Setting Up the Store and Reducers" section. Specifically, I'm having a hard time understanding the differences between your approach and redux-ORM's. They seem pretty similar for this specific case, other than the fact that you're generating the base reducer for the orm branch, and that your reducer could be made into a generic "update entity" reducer (like you do in Part 2.) Is that why you're doing it yourself here, or is there something else that I'm missing?

from marks-dev-blog-comments.

Original date: 2016-12-07T01:55:38Z

Hi, and thanks for the question! In the specific example I showed, there's not really any difference in actual behavior (which was kind of the intent). Overall, the main difference between using `schema.reducer()` (Redux-ORM's suggested approach) and "manually" setting up a reducer is that the `schema.reducer()` approach wants you to write all your reducer logic as part of your Model classes. There's not anything specifically _wrong_ with that, but it definitely puts more of an emphasis on the Models as the center of attention. In my case, I'm trying to keep the focus on my own reducer logic, and using Redux-ORM's capabilities as a helpful tool in that process. So, slight difference technically, slightly bigger difference philosophically, perhaps.

Having said that, Tommi Kaikkonen is close to releasing Redux-ORM 0.9, which will actually invalidate a large chunk of what I wrote in these two posts. For example, updates will be applied right away, so you won't have to do that `session.state = session.reduce()` trick I talk about in Part 2. Also, looking at the latest commit in the currently open pull request, the docs have changed and now recommend the "standalone reducer" approach instead, although it seems that "attached reducers" are still acceptable. The PR with the 0.9 features is at https://github.com/tommikai... if you want to look through it.

I definitely plan on writing a follow-up post on what's changed in 0.9 and how to use it after 0.9 comes out and I've had a chance to play with it a bit.

from marks-dev-blog-comments.

Original author: Liam Doran @liam_doran
Original date: 2016-12-08T14:24:34Z

Gotcha, that makes sense. I checked out the 0.9 PR, looks like he's doing some cool stuff, I'll look forward to your post on it!

from marks-dev-blog-comments.

Original date: 2016-12-07T01:55:38Z

Hi, and thanks for the question! In the specific example I showed, there's not really any difference in actual behavior (which was kind of the intent). Overall, the main difference between using `schema.reducer()` (Redux-ORM's suggested approach) and "manually" setting up a reducer is that the `schema.reducer()` approach wants you to write all your reducer logic as part of your Model classes. There's not anything specifically _wrong_ with that, but it definitely puts more of an emphasis on the Models as the center of attention. In my case, I'm trying to keep the focus on my own reducer logic, and using Redux-ORM's capabilities as a helpful tool in that process. So, slight difference technically, slightly bigger difference philosophically, perhaps.

Having said that, Tommi Kaikkonen is close to releasing Redux-ORM 0.9, which will actually invalidate a large chunk of what I wrote in these two posts. For example, updates will be applied right away, so you won't have to do that `session.state = session.reduce()` trick I talk about in Part 2. Also, looking at the latest commit in the currently open pull request, the docs have changed and now recommend the "standalone reducer" approach instead, although it seems that "attached reducers" are still acceptable. The PR with the 0.9 features is at https://github.com/tommikai... if you want to look through it.

I definitely plan on writing a follow-up post on what's changed in 0.9 and how to use it after 0.9 comes out and I've had a chance to play with it a bit.

from marks-dev-blog-comments.

Original author: ianastacio @ianastacio
Original date: 2017-02-11T08:55:10Z

Hi Mark, just a small note, Normalizr does have denormalization support since version 3.1.0 https://github.com/paularms...

from marks-dev-blog-comments.

Original date: 2017-02-11T18:53:24Z

Yeah, saw that. My comparison was accurate at the time of the original post :)

Glancing at the API docs, it looks like Normalizr's `denormalize()` function will do a complete load of the relevant object graph at once. That's not necessarily bad, but could be more than you really need done. On the other hand, Redux-ORM looks up relations in a somewhat lazier way, when you access the relation wrapper fields.

Still, it's a good addition to Normalizr, and I appreciate the pointer!

from marks-dev-blog-comments.