Vision for client-side routing?

[achou11]

Have you had any ideas on how client-side routing would work in yeet? Would it be something that can be implemented in yeet itself or would you defer to some other library/implementation? Would an in-house implementation be similar to how Choo works?

For me, I feel like that's the last missing piece of making yeet something I can be productive with when it comes to building SPAs, so just curious if there were any thoughts on that

[tornqvist]

My thinking is to keep yeet as lean as possible and to rely on external libraries for most of the application orchestration. It makes it easier to iterate on concepts without worrying about breaking changes. Ideally even the components would be external but atm. the rendering needs to be aware of how to handle the components. I should say though that I have a rewrite in the works which improves first reder (by a lot) and also does isolate the components a bit more from the core, though not completely.

Regarding the router, I have been sketching on an idea similar to the router in Choo which works like a Ref where you get the current resolved route on a router instance. This would allow for routers to be used by any component at any depth of the application and one could even implement nested routing. Let me know what you think.

import { html, Component } from 'yeet'
import { Router } from 'yeet-router' // or whatever

export default Component(function (state, emit) {
  const router = new Router()

  router.on('/foo', () => import('./foo.js'))
  router.on('/bar', () => html`<div>bar</div>`)
  router.on('/baz', () => Component((state) => html`<div>${state.baz}</div>`))

  return function () {
    return html`
      <div id="app">
        ${router.current}
      </div>
    `
  }
})

[achou11]

thanks for the explanation! very cool to know that you're iterating on ideas and personally super excited to see how it materializes. regarding the router, looks solid to me! being able to nest routing is definitely a big plus :)