This morning I worked on fleshing out pagination on various pages that need it (viewing posts in a group, your “pings,” and the unified activity stream). I had previously punted on implementing it, but it’s definitely a requirement for the MVP. This was also an excellent opportunity to refactor some of the routing logic in Elm.
I ended up extracting a Pagination module that takes a Connection of nodes and renders the prev/next buttons. This is one area where Elm really shines. After all, everything – including HTML definitions – is just function.
In the afternoon, I turned my attention toward something that feels like an area of risk: Markdown rendering. When I upgraded to Elm 0.19, I switched to using elm-markdown to render post and reply bodies. The old hack I was using to inject server-rendered HTML into a
<div> node was eliminated (for a good reason), so I took a crack at using the Elm library (which just wraps marked.js at this point).
This works great for just rendering plain output. But, I had already begun layering on more preprocessing to post bodies on the server-side, such as HTML sanitization and special styling for @-mentions. It seemed like a daunting task to figure out how to accomplish all this processing on the client-side in tandem with elm-markdown. (You can’t just traverse the Elm virtual DOM and swap out nodes to my knowledge).
So, I began entertaining the possibility of once again injecting server-rendered Markdown, this time using a Custom Element. (See this follow-up post for details about how I did it).
I’ll be keeping an eye on performance and potential bugs with this custom element approach, but for now, it seems to be working just fine and makes me feel relieved that I (probably) won’t have to embark on a massive effort just to get posts rendering how I’d like them to.
Update on Aug 31: Spun out custom element instructions into a separate post