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
This is a proof-of-concept intended to provoke some discussion about why the RoutePattern data type is as it is, and whether it can be modified to give users more power to write modular routing code.
I would like to write combinators for RoutePatterns, but it isn't possible to do anything very useful without duplicating the code that is in the internal function matchRoute. Examples of useful RoutePattern combinators would be matching either of two patterns, or both.
However, I noticed that matchRoute turns any RoutePattern into a function that would fit in the Function constructor. So, why do we need the other constructors?
This patch shows that if we move the logic from matchRoute out into the capture and literal functions, then the need for the various RoutePattern ADT constructors vanishes, and thus users' own combinators for routes no longer need to handle the different cases of RoutePattern.
see #156 :
commit of interest : 01906eb
The text was updated successfully, but these errors were encountered: