Exchanging custom data between routes and data functions in a page module?

[ringods]

Hello,

I'm in the process of migrating my blog to elm-pages v2 as a way to learn Elm. So far, I already learned a lot of Elm idioms and I like it a lot.

I do have an elm-pages specific question. I have a page module for my blog articles which contains this piece of code:

type alias RouteParams =
    { year : String
    , month : String
    , slug : String
    }

routes : DataSource (List RouteParams)
routes =
    Posts.all |> DataSource.map (List.map (\post -> RouteParams post.year post.month post.slug ))

data : RouteParams -> DataSource Data
data routeParams =
    routeParams
        |> findFileByRouteParams
        |> DataSource.andThen 
            ( \filePath -> 
                filePath
                |> MarkdownCodec.withFrontmatter Data blogPostMetadataDecoder TailwindMarkdownRenderer.renderer
            )

In the Posts module, a Post is defined like this:

type alias Post =
    { year : String
    , month : String
    , slug : String
    , filePath : String
    }

As you can see, I'm dropping the filePath property from a Post because the information in my RouteParams has to match based on the location of my page module, in my case ./Year_/Month_/Slug_.elm.

But when the RouteParams is passed back into my data function, I have to look up the matching Post again using findFileByRouteParams to read the data. Would there be an option that, besides the RouteParams, I can also return some extra data which is passed verbatim to the data function?

Ringo

[dillonkearns]

elm-pages has an intentionally lean architecture and mental model. The model is:

Given a URL (which will be parsed into RouteParams for a given Page Module), what DataSource should I go get?

That's it. If there was a way to carry over data as part of pre-rendering routes, then it would mean the dev server would need to pre-render all routes each time in order to give you the data for a specific route (that's bad for performance). The same performance cost would apply to rendering a single page in serverless mode (a feature that's currently in alpha).

elm-pages would also need to carry over the underlying data from building up the pre-rendered routes from that DataSource. If you don't need that data, should elm-pages still carry all of that data over and include the underlying JSON just in case? That could lead to bloated pages, and unexpected results where the user wouldn't realize they are adding extra data just by changing which routes are pre-rendered.

So instead, elm-pages has that simple model: given a Route, what DataSource should I got get? That's all it is. What that often means is that you'll want to create code abstractions to help share data between different routes if you use things more than one place. It also means that you notice it when there is implicit data. For example, if you want to handle getting files ending with my-page/index.md or my-page.md, when all you have are the RouteParams telling you the slug is my-page, where do you go look? That complexity is now visible, and I think that's a good thing. The complexity isn't hidden, so we're more aware of the complexity in our designs.

In your case here, with a consistent naming pattern, you can go look up a file based on all the information in the RouteParams, so that simplicity pays off by allowing you to go read the file simply.

Hope that helps clarify the design and mental model.