Writing UI components in the react-states architecture removes a lot of complexity when writing UIs. All state management, data fetching and environment effects related to the domain of the application is not the concern of any components defining UI. They rather consume this as feature hooks. That does not mean UI components does not have state or side effects, but they are tied to the UI itself, not the domain of the application.
With explicit statesyou get a super power when consuming the feature to create a UI. We can ensure that any state the feature can be in is actually covered by the UI implementation. This is done by matching over the states of the features.
If any state is added, changed or removed in the feature you know that the usage of match will notify you about that change in the UI implementation. That means you should favour using match as it gives more predictability.
Matching to styles
The match can map to anything, for example the styling of en element.
Deciding what logic should be contained within a feature and what is strictly UI related can sometimes be difficult, but you can not really do it wrong, it is only a matter of consequences. The rule of thumb when bringing logic like state and effects into a UI component is to identify if that state and logic is tied to the UI itself, not something related to the application. An example of that would be:
The createReducer utility is not restricted to features. You can use it in components to deal with complex UI changes and interactions. An example of that would be drag and drop: