RFC: Remove `segment` prop from layouts

[Conduitry]

With the introduction of the page store in Svelte v3 Sapper, the segment prop passed to _layout.svelte components feels somewhat vestigial. I don't think there's anything that can be done with it that can't be done (in a more uniform, if slightly more verbose, way) with $page.path.

There seems to be a bit of confusion around segment, about how to gain access to other parts of the URL, and about how to inject other bits of data into the layout. These would hopefully all be avoided if we never actually passed any props into _layout and we instead had the docs tell people to just always use the stores.

Thoughts?

[Conduitry]

We could perhaps ease people into this a bit, by issuing warnings rather than immediately breaking. It should be pretty straightforward to check at build time whether a given _layout component defines a segment prop, by inspecting the vars array returned by the compiler. We're already doing this elsewhere to check for the presence of preload.

[pngwn]

As I mentioned, I have moved away from using segment at all. I find it easier to work with the page store which covers all segment usecases and many more besides. Layout's are pretty static so working out which part of the path they correspond to is pretty straightforward.

Removing segment would make the API more consistent, would be easier to teach and, as you said, remove the question of 'can other props be passed to layouts'. While the change might be slightly controversial, I think in the long term it will make for a clearer more consistent API.

If we do choose to adopt this proposal, transitioning to it gently with a deprecation notice seems like a nice idea, especially since the segment prop is probably quite widely used.

[Rich-Harris]

I do find it useful for e.g. controlling which nav button is selected (including nested, secondary navs). If we were to remove this — and I agree, it's weird and vestigial — what about adding a $page.segments array in its place? Or is it better for the user to derive that from $page.path?

[pngwn]

I wondered about adding a segments array to the page store, it would obviously be useful but its also incredibly straight-forward to derive from the path. Maybe if you needed to do it extensively across an app it could get tedious but in my mind the segments are really just used for navigation or navigation related pieces of UI. I don't know if people use them much outside of the odd navigation component.

[njbotkin]

That's funny, I just started using segment as a clean way to ask, "are there any sub routes mounted to this _layout?" In segment's stead, I might suggest current; the _layout's path. All child segments can be had with $page.path.slice(current.length).

Ideally exposing $page would be a bit less laborious, but I imagine there's a discussion on that elsewhere.

[Conduitry]

$page is already exposed. These stores can be used in every component, including layouts,

[njbotkin]

Sorry, I meant exposing the reference to the page store. It feels a bit icky to have to const { page } = stores() each time. To be clear, I have no better ideas.

[pngwn]

I don't know what "icky" means. I think it is explicit and i like that.

[njbotkin]

It's entirely subjective and appears to be derailing the discussion, so let's move on, I guess 😅

[swyxio]

i like this idea. i'd love to also link this RFC in the docs to warn users. is this kind of PR welcome?

[intrikate]

One thing I believe can’t be done with $page.path alone is error route differentiation, mentioned in #948 (correct me if I’m wrong, but we’ll have to resort to hacks like let isError = segment === undefined && $page.path !== "/" to do that). Other than that, they do seem like one too many, and $page wins everywhere.