A component author has no way of knowing which state changes a consumer will want to override, but state reducers handle this problem by allowing the parent component to override any state change.
Badhiya, very nice :)
For something like this, I think another decent approach would be to have the Toggle just emit the (toggle)
event, but not change the internal state. Then, have the App listen for that, and change the [on]
property as needed. Kind of like a "controlled input" in React.
@Ben, yes, that would be a reasonable way to do it for this case. That makes the toggle component into a stateless presentational component.
Sometimes you want to maintain some local state inside your component, but you also want to give users the ability control that state if they want. That's what the state reducer pattern lets you do. The decision here is basically who should be in control of the state changes.
Controlled input (stateless component) - All state changes must be defined by the user of the component State reducer - Component provides a default state change behavior, but users can override that behavior if they want
@Isaac, I can dig it—it's interesting stuff. I hadn't seen this pattern before. Though, to be fair, my experience with reduces, in general, is extremely limited. I appreciate the fresh perspective.
This is a good course but I don't think this pattern would scale well in a enterprise application.