Learn the fundamental pattern of building maintainable Redux applications: reducer composition, and how it can be used to update properties of an object.
I don't understand why you are passing
It lets the specific reducers(
visibilityFilter) self populate themselves (with default values) when the
todoApp reducer is first called.
This lesson seemed, to take a few extra leaps forward here, the pace previously had been easily understood and constant. The sudden appearance of the store and all the logs, utterly threw me, followed by the rather obfuscated explanation and example of the filters, which seemed almost abstract from the previous lesson. I had to double check I hadn't missed several steps, or even an entire lesson.
I prefer not to continually pause, rewind and play on lessons if its not necessary, but I have to admit, this lesson was a little slow on the uptake.
Dear Dan Abramov, If every time some action dispatched with whole state produced again, won't that effect the performance ? If I use redux to make a video player, which listen to timeupdate event and scroll event (all dispatch very frequently), won't that effect performance ? Or there another pattern to use ?
Making a function simpler to address one problem per time is not only good for maintenance but also good for tests. The visibilityFilter function in this tutorial is placed at the same level of todos. Can I put visiblityFilter in todos just like todo is called within todos reducer? The point is any guideline to organize these reducers?