Labs Feedback: @lit-labs/router

[justinfagnani]

The @lit-labs/router package is a set of controllers for client-side routing. The controllers allow for a declarative configuration of routes with associated templates, and update their host element when the route changes. We are experimenting with a Lit-specific router as opposed to using a generic routing library because using reactive controllers simplifies the host/router integration, and we can use new platform features like URLPattern.

We want to collect your feedback on your experiences with @lit-labs/router as we iterate on it according to our Lit Labs process and move the package towards possible graduation or retirement.

• Status: Prototyping
• Major known issues:
  • [labs/router] goto() and link() don't work for global routes #3352
• Issues: [labs/router]
• Docs: README
• npm: @lit-labs/router

Please try @lit-labs/router and tell us about your experience. Leave comments with your thoughts; highlight what issues or missing features you're blocked on; give a link to a project that uses it; etc.

And so we can have some numbers to look at, you can add reactions to this comment to indicate your experience with this package:

🚀 I have tried this package and it works great. I need it. Ship it!
👍 I have tried this package and it seems like a good idea.
😕 I have tried this package and would use it, but it has serious bugs or missing features.
👀 I am interested, but haven't tried the package yet.
👎 I'm not interested in this package.

Note: other reactions like 😄, 🎉, and ❤️ don't mean anything as part of this scheme. You probably mean, and please use, 🚀, 👍, or 👀.

[gadd-gj]

It's okay. 💯
But I don't know how to use router with 'a' tags

[zandaqo]

I've been using the router since it appeared and it's great: simple, intuitive, and close to the metal--all the things I love about Lit in general.

The only major issue for me: observability (partially raised here #2512). I'd like to know when a route is matched (preferably with an event) and what the current route is. For example, to highlight the currently active element in navbar. At the moment, one has to add enter methods to each route to achieve this.

I understand that for some people this router might seem too simplistic, maybe they want more magic akin to Remix--those people are wrong.

[CICCIOSGAMINO]

I'm just trying this package and i get bit confused about how i can goto to routes i've declared on main component (eg. app-lite), in child component (eg. home-view, one-view etc) i set method to respond to click event so i'm used to trigger an action on main Router as with @vaadin/router calling window.Router.go('/other-view') in the child method to trigger the routing in the main component ... i'm actually try to implement @lit-labs/router but i'm not able to trigger main component routing from child ....

[justinfagnani]

This is definitely a missing part of the API that I and @AndrewJakubowicz have ben talking about recently. It should be roughly captured by #3352

[CICCIOSGAMINO]

Just to let you know .... i'm trying with the same code i'm using with other router and seems with @lit-labs/router only miss to update the top bar URL when i'm triggering from child with this code .... window.router.goto(/${page}) .... but of course i'm not sure if it's the right call when i'm using Lit controller, because i'm used to use to instantiate the controller in all component where i need it and access there the variables i need ....

[LasseRosenow]

What I am missing the most is some kind of common enter callback that would be executed whenever the route changes.

My Use-Case is, that I would for example always reset the scroll position to 0, or scroll to some specific place regarding the current route.

Right now, I would have to call my scroll function on every single enter callback of every single route. That is really redundant. So I propose something like this:

class MyElement extends LitElement {
  private _routes = new Routes(this, {
    routes: [
      {path: '/', render: () => html`<h1>Home</h1>`},
      {path: '/projects', render: () => html`<h1>Projects</h1>`},
      {path: '/about', render: () => html`<h1>About</h3>`},
    ],
    routeChanged: (route) => { // <----------------------------- See here
      window.scroll({
        top: 0,
        left: 0,
      });
    },
});

  render() {
    return html`
      <header>...</header>
      <main>${this._routes.outlet()}</main>
      <footer>...</footer>
    `;
  }
}

I already created a discussion about this some time ago with more information: #2529

[CICCIOSGAMINO]

I think will be useful have a method as enter() but for doing work after the element is in the renderRoot ....

[gero1992]

In general I would say that I like it. It's very simple to use for basic purposes. Nice job :)!

Unfortunately I tried to implement a navigation drawer with two levels and got a bit confused.

At first I used nested routes, but they require a new configuration, new container and provide an additional outlet.
The specified in the main router fallback got missing for the nested routes, so I needed to add this to the additional Routes configuration as well. Also dealing with multiple configurations for this use case was some how not optimal.

I ended up registering the routes like this:

[
    {path: '/parent', render: () => html`<h1>Parent </h1>`},
    {path: '/parent/child1', render: () => html`<h1>Child 1</h1>`},
    {path: '/parent/child2', render: () => html`<h1>Child 2</h1>`}
  ]

It works fine, but the base path gets duplicated and I think it would be pretty handy to be able to distinguish where a route belongs not only judging by the path - e.g. to render the navigation elements based on the router configuration.

I think it would be useful to support child routes in the configurations.
Maybe something like this:

[
    {path: '/parent', render: () => html`<h1>Parent </h1>`,
    children: [
        {path: '/child1', render: () => html`<h1>Child 1</h1>`},
        {path: '/child2', render: () => html`<h1>Child 2</h1>`},
    ]}
  ]

[quincarter]

This is a great idea for sure. I think if you look at one of the most used routers for Lit right now, vaadin, that implementation is pretty full featured, but not actively maintained on the javascript side (that i can see, it is still used, but it does not have active commits happening).

I would love something built by the Lit community to be the router of choice.

with that said, i have tried this lit-labs package and so far it works pretty well. I can't opt to use it in my packages until it is closer to GA, but i have it in a couple of personal projects and it works as a basic router for now. :)

[mmcnl]

@justinfagnani Does this currently work with search? While this works as expected with URLPattern,

const p = new URLPattern({ pathname: '/:collection', search: ':param=:value' })

const results = p.exec('https://example.com/about?tags=foo')

console.log(results.search.groups.param)  // "tags"
console.log(results.search.groups.value) // "foo"

I'm having trouble getting it to work with the lit labs router (v ^0.1.1), ie while this matches

    pattern: new URLPattern({ pathname: '/:collection' }),

if I add the search to the pattern I can never get it to match

    pattern: new URLPattern({ pathname: '/:collection', search: ':param=:value' }),

[vid]

Are there examples of how this is all meant to work? I feel like it's aimed at people who are already very familiar with certain implementations of routers. Some parts aren't clear to me, like how a route is supposed to access the controller router (specifically to use link). Thanks.

[vid]

I added a minimalist example of how I got it to work* here: https://github.com/vid/lit-router-example
one inflection is it has a flag to use hash routing.

I am not an expert in any of this so probably got parts wrong, in particular it seems odd to have to pass around the router manually, but it does work.

• does not work in firefox

[kenwenzel]

The router does currently not listen to "pushstate" changes.
It would be nice if I could somewhere just use history.pushState({}, '', "/new/path"); and the top-level router instance triggers the goto action.

Then the following code at

lit/packages/labs/router/src/router.ts

Line 69 in f60a3a2

if (href !== location.href) {

could just omit the this.goto(...) line as it would be automatically handled:

    if (href !== location.href) {
      window.history.pushState({}, '', href);
      this.goto(anchor.pathname);
    }

[tbroyer]

The router listens to popstate so this should work

[kenwenzel]

It works only for history.popState (navigating backwards) but not for history.pushState.

[kenwenzel]

OK, if just discovered that there is no pushstate event :-)
https://stackoverflow.com/questions/4570093/how-to-get-notified-about-changes-of-the-history-via-history-pushstate

[tbroyer]

Oh, looks like I misremembered how this works and push state doesn't actually fire a pop state event, sorry. Can't wait for the new navigation API to be globally available

[christophe-g]

@justinfagnani - interested to know if there are any plans to work on the router in a near future ?

[felixapitzsch]

I appreciate the work on this new lit router a lot. However, I miss documentation for the following use case with a main-component implementing routing like this:

<header-section></header-section>${this.router.outlet()}<footer-section></footer-section>
... for a number of non-nested routes, where the header-section or one of its sub-components needs to render something (for example, a matching header-icon for each route) based on the same non-nested routes that the main-component sees and uses to determine its outlet.

The current documentation covers only nested routes. Is it possible to do routing for the same non-nested routes at multiple points (in multiple components)? It would be nice to have documentation on this topic.

[felixapitzsch]

I have been using the router for some weeks now and at first, I was looking for something like a leave() callback, which is probably what @CICCIOSGAMINO asked for more than a year ago:

I think will be useful have a method as enter() but for doing work after the element is in the renderRoot ....

First, I gave it a thumbs up, but now I realized that the updated() callback of my app-router component is where I can put my respective code - in combination with using the ref() directive in the router's render() callback. If this pattern works for a number of relevant use cases, maybe it is worth adding an example in the documentation for users looking for a leave() callback.

My use case was adding a general scroll-to mechanism when a hash was specified in the URL:

#router = new Router(this, [
    { path: PATHS.home, render: () => html`<home-page ${ref(this.#currentPageRef)}></home-page>` },
    { path: PATHS.otherPage, render: () => html`<other-page ${ref(this.#currentPageRef)}></other-page>` },
]);

...

updated(){
    const targetElement = this.#currentPageRef.value?.shadowRoot.getElementById(location.hash.slice(1));
    targetElement?.scrollIntoView({behavior: 'smooth'});
}

Obviously, using updated() here, the update is only complete for app-router and depending on home-page or other-page, the relevant section/id might not be rendered yet and might be missed by getElementById().