[lit-labs/router] Add onRouteChanged callback to Router

[LasseRosenow]

Feature Request

I like the new @lit-labs/router package very much, but it is missing on one functionality that I really need, which is the ability to execute a callback whenever the route changes.

Use Case

In my application whenever I navigate from one page to the other, I need to set the windows scroll position to 0, as it is expected to be on any page based website. Also when I have a single page navigation that uses the scroll position as navigation, I don't want to set the global scroll position to 0, when the route changes, but scroll to some specific element.

So this cannot be a default setting within the router, but needs to be made configurable. This is why I would lilke to have some sort of callback to realize this, kinda like a common enter

Possible API design:

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) => {
      window.scroll({
        top: 0,
        left: 0,
      });
    },
});

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

[zandaqo]

Second this. I'd go with an event--it's more general and in line with the rest of the API:

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>`},
    ]
  });

  connectedCallback() {
    super.connectedCallback(); 
    this.addEventListener('lit-route-changed', this.onRouteChange);
  }

  onRouteChange(event: RouteEvent) {
      window.scroll({
        top: 0,
        left: 0,
      });
  }

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

This way you can also have multiple subscriptions including from other components (e.g. listening on window when the event bubbles).

[LasseRosenow]

I don't think that events would be more in line with rest of the API, as routs for example do use callbacks for this kind of functionality like "enter" for example.

Also what I don't like about events in this situation is that those would be somewhat hidden and we can only find out about them by looking into the docs, whereas a callback is visible through the constructor parameter type.

Of course there are other places in lit, where events are nice like inside webcomponents, because they are strongly integrated with each other and the IDE can know about them and make recommendations on the html tag etc. that this html element can fire certain events. etc.

But in this regard I think callbacks would be the better choice

[zandaqo]

Callbacks are extremely limiting. Consider other use cases, you'll likely need to react to route changes from other components: set breadcrumbs, highlight navigation panel elements, etc. With the callback, there is no way to decouple that code from the router, you have to do it all in the single callback and likely end up firing an event there anyway.

[LasseRosenow]

It could be argued if it would make sense to execute the callback also if some nested route changed. This way that problem would be solved. Also what about just having both? A callback and an event? This way people could just choose, what would fit theirs needs best :)

[spdowling]

Wouldn’t using enter() (enter callbacks) give you the same control?

[LasseRosenow]

No. The enter callback would need to be set up for every route, which would create a lot of avoidable redundancy and seems like a bad practice for setting up common behavior.

[spdowling]

I can see how it might feel redundant. Personally I have my own router controller that took an approach more similar to the existing reactive controller examples.

I separate the rendering function from the routing and instead update a state value on the controller instance. That way the state is exposed for use after triggering a requestUpdate() on the host.

This allows me to access the router state from the host during the standard update lifecycle, capturing changes by interrogating the router state.

This also has the benefit (maybe a personal preference) of keeping the rendering state-driven and localised to an elements render() function.