You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The docs' reducer example and its usage of exhaustive doesn't seem that helpful. When matching a complex data type like a tuple consisting of two unions with 4 entries each, a true exhaustive check would need to handle 16 possible combinations. Explicitly handling all those cases wouldn't be meaningful. As the docs state:
only a subset of these events make sense for each given state
What is actually happening in the example is that each value for event.type is manually exhaustively checked. If you add a new event type in the given reducer example then there would be no ts error indicating you need to handle a new event type.
It would be extremely helpful to select a subtype of the matched pattern which should be exhaustively checked.
The docs' reducer example and its usage of
exhaustive
doesn't seem that helpful. When matching a complex data type like a tuple consisting of two unions with 4 entries each, a true exhaustive check would need to handle 16 possible combinations. Explicitly handling all those cases wouldn't be meaningful. As the docs state:What is actually happening in the example is that each value for
event.type
is manually exhaustively checked. If you add a new event type in the given reducer example then there would be no ts error indicating you need to handle a new event type.It would be extremely helpful to select a subtype of the matched pattern which should be exhaustively checked.
E.g. something like
Amazing work! 🌟 Happy new year
The text was updated successfully, but these errors were encountered: