-
Notifications
You must be signed in to change notification settings - Fork 381
Description
We've got around 2k routes and the call to mkYesodData is becoming a problem for us.
Fortunately, there's a relatively easy touch point to significantly improve this: allow nested routes to be generated separately.
Currently, we use the TemplateHaskell code to parse the routes in a standalone module. This module is imported, and we refer to the routes :: [ResourceTree String] when we call mkYesodData "WebApp" routes.
Each new route adds five things to this file:
- An entry in
resourcesWebApp- which is a copy/paste fromroutesas input. - A constructor in
Route WebApp(or, if it is nested, a new constructor in a separate datatype) - A parse route case
- A render route case
- a
RouteAttrscase
While we can improve other things, the biggest win will be in allowing the Yesod generate code to refer to prior work in other modules.
I suggest a function mkYesodNestedRoute :: String -> String -> [ResourceTree String] -> DecsQ, used like:
mkYesodNestedRouteData "WebApp" "AdminR" routesThat finds the AdminR route directory and creates the relevant data and functions for it.
Then, in mkYesodData, we do a lookup on the presence of the type. If AdminR already exists, then we don't bother generating it: we refer to it. Same with the other cases: if we have a function AdminR -> Set Text for route attributes, then we can delegate to it.