Learn how to avoid the boilerplate of passing the props down the intermediate components by introducing more container components.
If the parent component does not update when the store updates, then FilterLink will re-render with a stale value
It's probably a mistake on my part to wrap my head around this without hands on experience, but I do have a question: When would not updating the parent component, be of consequence to the FilterLink (a child component)? Can you please give me an example?
Up to this point the tutorial is excellent, but I have a problem with this lesson.
The FilterLink component in this lesson is not following the rules in React.
This error is removed in later chapters and is not the way things are done in Redux, so it is just confusing. And it is not needed in order to get an understanding of how things are done in Redux either.
Let me explain the problem:
The contract of a a react component is that the result returned from render should only depend on this.state and this.props and nothing else.
See the component spec
In this lesson we have for FilterLink
const state = store.getState()
and then state.visibilityFilter() is used when setting up the returned Link element. That is, render() depends on something else than this.state or this.props which is simply illegal in React.
The proper way to do this is to use this.state instead. This is done by reading the value from store.getState() in the subscribe listener and call this.setState() of the component.
this.unsubscribe = store.subscribe(() =>
const state = this.state; // NB No access of store here!
When done this way the forceUpdate call is not needed, since re-rendering will be triggered properly through setState.
Here is an example where the parent component gets re-rendered but the children don't. In essence this depends on the optimizations in the implementation of React rendering. It assumes the components follow the contract: if props and state are unchanged render should return the same thing, so calls to render can be optimized away. Exactly how this is done is an implementation detail and not specified. But it's not a problem: as long as your components follow the contract they will be re-rendered properly. (Then, if you don't break things, you don't need to worry how to fix it again)
Here is a discussion where Sebastian Markbåge make some good clarifications on this topic.
This tutorial is just an approximation of how connect() from React Redux works. Please watch series to the end, which is where we start using it and remove the “wrong” code. Technically connect() uses setState() but this is irrelevant implementation detail to this tutorial which is why I went with forceUpdate(). It really doesn't matter because this code is temporary and is later changes to use connect() instead.
I'm confused about the use of
props.filter here. It seems like
filter should be an explicitly defined argument to the FilterLink "constructor", instead it's not explicitly defined as a required property but it is implicitly relied upon. How are users of
FilterLink to know which props they should set on it, which it supports and which are required?
I'd love to see this intermediate impl (using react state) between the quick-and-dirty impl here and the final black-box connect impl. Lars's comment mostly covers it I guess :)
I tried it at first but it made things super confusing because the word “state” now refers to completely different things: React state (an implementation detail) and Redux state (the thing we’re trying to teach). It’s so easy to confuse one for the other so I decided not to mention React state at all, especially considering that this hack is going away in the next lessons.
In my Moz FF49 browser FilterLink is re-rendered anyway along just as the rest of the application, componentDidMount and componentWillUnmount do not get called at all. So I'm not sure I understand your point - why use componentDidMount at all?
Is this just a place to explain updates between Redux store and React?