What's Next After 2.0?

[dillonkearns]

Here are some ideas that are on my mind after releasing elm-pages 2.0. There's no set timeline for any of these and they may end up being rethought or not being priorities, but I wanted to get my current thoughts down for future reference and for anyone who is interested. Feedback and other ideas are welcome!

These items are roughly in order.

elm-review integration

Goals:

• Provide a nice way to check literals are valid Routes, Image Paths, or even use the DataSource API in even more creative ways to integrate with elm-pages

Error feedback for invalid routes

• Shadowed routes with pre-rendered route that will never match because of shadowing - should be a build error.
• Invalid characters in routes, like RouteParams "/" or RouteParams "", should be build errors most likely. Otherwise the user can create routes that will do nothing but give no feedback so they are silently failing effectively.

elm-markdown scaffolded

Goal:

• Make it a nice experience (and possible) to use DataSource within the core dillonkearns/elm-markdown package. Philipp's package has some helpers for this, but it's somewhat advanced to reach for that extra package and know how to set it up. It should be in the path of least resistence to be able to use DataSource from elm-markdown.
• It would also be nice to make it easy to use elm-markdown. What should the plugins setup look like? Right now, I have a folder of common plugins I use in my own personal projects that includes a distill helper to get optimized markdown.
  • The Codec for markdown should be shipped with dillonkearns/elm-markdown
  • The distill helpers could be nice to include in a published package

Serverless/On-Demand Builders

Goal:

• Have a nice API for the DataSource.ServerRequest module, to allow a page to depend on HttpRequest info (similar to the information you would use in the req argument of an ExpressJS app
• Have an adapter API to allow using different platforms, like Netlify, or Vercel, etc., to put code in the appropriate places to set up redirect rules, etc. to enable serverless elm-pages responses.
  • With Netlify, add a setup for on-demand builders that gives an error if you use an invalid pattern that can't be translated to the netlify redirect rules (because it doesn't allow for regex, it needs to be hardcoded routes only)

Better DataSource.Port caching

Goal:

• Detect when JS source code for a DataSource.Port has changed in order to bust its cache and do a hot reload. Right now, we only know if the entire file has changed, but we don't have granular knowledge of which port changed, and we don't know if any files that it depends on change. Likely solution is to use esbuild to fingerprint the bundle of a given port with all of its dependent files, and split out each port JS to a separate file so it can be individually bundled/fingerprinted.
• Non-goal: providing a way to use webpack/babel/other arbitrary tooling. This would only allow whatever standards esbuild supports out of the box and nothing more. Otherwise the project would turn into a bundler project and would get out of scope.
• This still doesn't cover the case of when to bust the cache when the source code doesn't change. For example, if you have a DataSource.Port for the last modified time of a file, elm-pages has no way to know that it should bust the cache whenever that file changes. Maybe there could be a JavaScript function within ports (injected as an argument?) to let the user say which files to watch for this port to bust its cache?

404 page helper

Goal:

• It should be easy to add a 404 page and have it render to the appropriate place.
  • Should it output a single file, like 404.html? Not sure what the best practice is there, what do tools like NextJS do?

Script tag API

Goals:

• Have a way to do blocking JS scripts (like adding dark-mode class to body to avoid flash)
• More high-level way to do font imports, pre-connects, etc.

Optimize Shared.Data

Goals:

• Shared.Data is not currently split out separately, it is included separately for each page. It should be shared to avoid loading that data again

API for offline PWA support

Goals:

• Use elm-pages' knowledge of how to load the content.json for a given page to make a high-level API that lets you say which caching strategy (stale-while-revalidate, offline-ready, etc., using workbox under the hood) to enable users to make any page available offline, and take care of caching the skeleton to make the app installable

Check for version when navigating to page

Goals:

• When doing a single-page navigation to a new page, you could get in a state where the code and the content.json that are loaded are a mismatch. Similar to NextJS, elm-pages should have some sort of hash to compare versions, and if they are out of sync, it should make sure it doesn't use incompatible code and data (probably by doing a full page navigation instead of a single-page navigation). The current behavior just tries to decode the DataSource for the page, and if it fails it does a full-page navigation.

OptimizedDecoder optionalField optimization

Goal:

• Right now, zwilias/elm-json-exploration uses a value decoder with andThen to do optional fields. This gets the correct result, but deoptimizes the JSON stripping of unused fields because it considers the entire JSON to be used for that section that was decoded with value. It would be nice to make a contribution to the upstream package to make optionalField optimized.

Preview mode

Goal:

• Have a way to use serverless rendering to show realtime responses (not pre-rendered pages). Probably, similar to NextJS, based on the presence of a cookie. Would need a route to set that cookie, and a helper or route to clear the cookie. Then a redirect rule (in the adapter files?) to redirect to the preview route if the cookie is present? And check the cookie value to make sure the user is authorized to use it.

Improve DataSource.map2/combine performance?

Customizable templates

Similar to elm-spa, it would be nice to have a way to customize the elm-pages add ... templates.

API to control dev server caching for DataSource.Http

• It might be nice to have a way to say how long to keep Http cache around. Right now, you can do elm-pages dev --keep-cache, but maybe there could be a way to set the time-to-live for cached responses?

Clean up SEO API