Build dynamic routes

[YerkoPalma]

As commented here this issue is to keep track of the state of dynamic routes build.

IMO this should be supported because is a basic feature of almost any app, and because previous versions of Bankai supported this. The problem is that the server side rendering for the build command is hard (for start, @Flet push some commits that support it in #310). So here is my first proposal/question, can we just disable SSR on dynamic routes, and leave that to choo?

Also my guess is that dynamic SSR requires a smart server, so could be an option that, if we detect dynamic routes, then we add a simple server.js file that would handle SSR on dynamic routes.

[goto-bus-stop]

So here is my first proposal/question, can we just disable SSR on dynamic routes, and leave that to choo?

Do you mean eg building only a catchall non-SSR index.html if there are dynamic routes? Or maybe build SSR-able routes like now, and for dynamic routes build a separate 200.html or so catchall? I think both of those can make sense

[yoshuawuyts]

200.html

Might be an interesting solution. Defining a /200 route should get you there already right now, if you combine it with choo-redirect or similar, I think.

[YerkoPalma]

@goto-bus-stop I though on keep building everything for static routes, and a catchall for dynamic, so the 200.html would be fine. Maybe also a 404.html if there is a /* route defined

[YerkoPalma]

I think we have another option for serving dynamics routes. We could use a cached template and a service worker to render dynamic routes, like this

// sw.js
self.addEventListener('fetch', function (event) {
  var params = getParams(event.request.url, route)

  event.respondWith(    
      caches.match('/article-template.html').then(function (response) {
        return response.text()
      }).then(function (responses) {
      var template = responses[0]

      return new Response(renderTemplate(template, params), {
        headers: {
          'Content-Type': 'text/html'
        }
      })
  )
})

This would give a server-renderlike experience, and since pages are cached it would make it really fast. The only downside I see, is it would force the use of a service worker.

What do you guys think?

[yoshuawuyts]

@YerkoPalma ohh, as a general idea this is quite interesting!

e.g. "What if we did server-rendering... on the client! - to cover cases where the client doesn't yet have a unique URL". That's definitely interesting hey.

I feel there would be more than a few edge cases, but sounds like it'd make for a cool experiment to scope out which exactly those are - might turn out to be a very reasonable approach!