(preact-iso) - support route parameters

[JoviDeCroock]

Resolves: #298

[github-actions]

Size Change: +205 B (0%)

Total Size: 693 kB

Filename	Size	Change
demo/dist/chunks/compat.********.js	15.3 kB	-1 B (0%)
demo/dist/chunks/index.********.js	190 B	+1 B (+1%)
demo/dist/chunks/prerender.********.js	2.45 kB	+1 B (0%)
demo/dist/error/index.html	623 B	+1 B (0%)
demo/dist/index.********.js	6.92 kB	+172 B (+3%)
demo/dist/index.html	713 B	+31 B (+5%)	🔍

ℹ️ View Unchanged

Filename	Size	Change
demo/dist/about/index.html	636 B	0 B
demo/dist/assets/Calendar.********.css	702 B	0 B
demo/dist/assets/style.********.css	386 B	0 B
demo/dist/chunks/class-fields.********.js	201 B	0 B
demo/dist/class-fields/index.html	612 B	0 B
demo/dist/compat/index.html	1.48 kB	0 B
demo/dist/env/index.html	692 B	0 B
demo/dist/files/index.html	654 B	0 B
wmr.cjs	661 kB	0 B

_{compressed-size-action}

[rschristian]

Might be useful to add a route with parameters to the preact-iso ReadMe too.

[developit]

Here's a few simplifications.

[smeijer]

I've been able to try this branch, and the routing part works great! Can't wait to see this being merged.

But... the useLocation hook does return these parameters. I think being able to retrieve and use these parameters, is what would make this truly useful.

[JoviDeCroock]

@smeijer You mean like useLocation().parameters would contain all the :id, ....

[smeijer]

@smeijer You mean like useLocation().parameters would contain all the :id, ....

Exactly! Extending the example from the docs in this PR:

const App = () => (
	<LocationProvider>
		<ErrorBoundary>
			<Router>
				<Home path="/" />
				<Profiles path="/profiles" />
				<Profile path="/profiles/:id" />
				<Profile path="/profiles/:id/:tab" />
			</Router>
		</ErrorBoundary>
	</LocationProvider>
);

When on example.com/profiles/123, useLocation().params would be

{
  id: '123',
}

When on example.com/profiles/123/hobbies, useLocation().params would be

{
  id: '123',
  tab: 'hobbies',
}

That's matching behavior with react-router#useParams. Having a separate hook for it named useParams would ease migration for users of react + react-router.

[developit]

@smeijer the trick with useLocation().params is that the location object returned from that hook is global to <LocationProvider>, so it's possible to have multiple routes (and their path patterns) simultaneously be "current":

const App = () => (
  <LocationProvider>
    <ErrorBoundary>
      <div id="app">
        <header>
          <Router>
            <Profile path="/profiles/:profile" />
          </Router>
        </header>
        <Router>
          <Profile path="/profiles/:id" />
        </Router>
      </div>
    </ErrorBoundary>
  </LocationProvider>
);

Another option that was floated was to allow passing a path pattern to useLocation() itself:

const { id } = useLocation('/profiles/:id').params;

It's more direct, but I wonder if it'd be workable?

[smeijer]

@developit, I understand. I've made a small sandbox to show that react-router doesn't care about that. Don't get me wrong, I'm not saying that this project must follow their example, I respect that this is a different project, and can have its own approach. Just sharing to show that my first expectation would be due to my experience with them.

Your example const { id } = useLocation('/profiles/:id').params; is definitely a nice start. It does have an impact on the developer experience tho, as we now need to connect components to url (patterns) ourselves.

As an alternative, I was thinking to simply merge all the paramters, and return the merge result instead. Your example from above would lead to const { id, profile } = useLocation().params in both Profile components, because one specified id, and the other profile. But that might lead to unexpected side effects.

Ideally, the params would be scoped to Router instead of LocationProvider.

It's more direct, but I wonder if it'd be workable?

Definitely workable.

[developit]

Merging all parameters seems like a pretty reasonable default. I'll have to noodle on how to implement it though...

Another option I thought of would be to have <Router> re-define the useLocation context object. That would let each Router pass only its current { url, path, query, params } object through the tree, which would support the react-router approach your sandbox uses. Maybe that's the easiest way to go.

[smeijer]

The "other option" looks to me like the preferred way to go. (to have <Router> re-define the useLocation context). If that's the easiest one too, we have a win-win situation. (It's also what I meant with:

Ideally, the params would be scoped to Router instead of LocationProvider.)

Merging looked like the easy solution to me in case the above wouldn't be possible, but the side effects might not be worth it. Especially if the better option can be done.

I mean, merging creates the situation where one might depend on the absence of params, while another unrelated route is setting them. When developers work with generic names like /:view/:tab/:page/:id it's a matter of time before that happens.

[JoviDeCroock]

Superseded by #354