Passing additional Props to component

Thank you for making the only Svelte router that has just worked. A huge bonus - it matches the documentation! 😄

I was hoping for a change to the Router component to be able to pass additional props to the rendered component.

Given a router definition the inclusion of the {props} attribute would allow arbitrary data to be passed to the rendered component.

const props = { id: "1234" };

<Router {routes} {prefix} {props} />

Changes required:

1. Include new exported member: export let props; (similar to routes, prefix)
2. Include the {...props} into the component declaration
    {#if componentParams}
      <svelte:component this="{component}" params="{componentParams}" on:routeEvent {...props} />
    {:else}
      <svelte:component this="{component}" on:routeEvent {...props} />
    {/if}

Rendered component can now access these props in the standard way using export let id;

As per: https://svelte.dev/repl/74593f36569a4c268d8a6ab277db34b5?version=3.12.1

Appreciate your consideration on this additional feature.

[matt-psaltis]

Hi @ItalyPaleAle sorry I’ve been unresponsive to this I would have liked to contribute with the pull request, thank you for doing so on my behalf.

With this change, it looks like the props are exposed as part of the routes configuration and I’ve successfully been able to add them via routes. One difference in the original suggestion was having the props variable exported so that it can be supplied directly on the router component from the parent component rather than via the routes config. Just curious if you can spare a moment 😃 thanks again!

[ItalyPaleAle]

Hey @matt-psaltis thanks again for the contribution and for the convincing argument above!

I initially merged the change just as you proposed above. However, after some testing, I decided to alter the design for two reasons.

1. The first is that I know that once I “opened the floodgates”, users would have asked for that, so might as well just do it right away and offer the most flexible option. The reason why I think that is because at the same time as I was merging your code change, I was working on #73 (support for dynamically-imported components). My initial design had a lot of proposals that were “less flexible”, such as having a single component to show as placeholder while routes were loading, for all routes. Users’ feedback was that they preferred a way to have a different loading component for each route, to be set in the wrap method. So, I assumed that similar conclusions could be made for this code change too.
2. The second reason is related to issue #98. Assume the router passes the prop foo to the component Bar. If Bar doesn’t have that prop (ie., Bar doesn’t say export let foo), then you get a runtime warning while in development mode. This is just a warning, and doesn’t appear when compiling in production mode, but it has gotten users annoyed. There’s an issue open with Svelte upstream, but they don’t seem too interested in fixing it. So, I didn’t want to create even more situations when users could see runtime warnings.

I know that the new API design is a bit more complex than just passing a prop to the router component… But I hope that the gains in flexibility (and the less annoying warnings) will compensate for the minor additional annoyance of having to use wrap.