-
-
Notifications
You must be signed in to change notification settings - Fork 434
Conversation
All tests now passing (locally at least — started getting failures on AppVeyor that appear to be connected to segment-boneyard/nightmare#1476), which makes me very happy. One major piece of missing functionality — if you have a route like
and you go from Instead, it should keep Aside from that, there's probably a bit of tidying up to do (e.g. we can improve the manifest slightly, I think) and then it's just a question of documentation. |
Ok, think this is just about ready — it now preserves each unchanged 'level' of component. There's still some tidying up to do but this PR needn't wait on it. One gotcha that I hadn't anticipated — if you preload data and then update those same keys after the component is rendered, they will get clobbered on route change: <!-- this will be 43 once oncreate runs, but if the
user navigates to a new route that preserves
this component, it will revert to 42 -->
{foo}
<script>
export default {
preload() {
return { foo: 42 };
},
oncreate() {
this.set({ foo: 43 });
}
};
</script> This is potentially a bit annoying but is understandable, and easily worked around. I don't think it's a dealbreaker. It's so nice being able to do |
In my opinion
_default.html should be renamed to index.html. If Layout.html is missing then index.html must be rendered. |
We talked about this in Discord a bit. Nothing is set in stone, but the reason we landed where we did is that the default page is likely to include nested components, and it makes more sense to have a There is something appealing about calling index pages On the other hand it feels odd to have @TehShrike You convinced me before that index content should go in |
That is how NuxtJs do nested routing https://nuxtjs.org/guide/routing and here is an example from Nuxt documentation https://nuxtjs.org/examples/nested-routes/ |
Yeah, I looked at Nuxt's implementation — I found it very confusing to be honest. The fact that you can have a file called The more I think about it, the more I lean towards your suggestion of having Concretely, to adapt this example from the original discussion, that would mean that to achieve an outcome like this for the <h1>Settings</h1>
<h2>Notifications</h2>
<h3>Email</h3>
<label>
<input type=checkbox>
email notifications
</label> ...we'd need the following components: <!-- routes/settings/_layout.html -->
<h1>Settings</h1>
<svelte:component this={child.component} {...child.props}/> <!-- routes/settings/notifications/_layout.html -->
<h2>Notifications</h2>
<svelte:component this={child.component} {...child.props}/> <!-- routes/settings/notifications/email.html or -->
<!-- routes/settings/notifications/email/index.html -->
<h3>Email</h3>
<label>
<input type=checkbox>
email notifications
</label> I'm adapting the PR locally and trying that design out on a couple of different apps, to see how natural it feels. |
Another change: it no longer makes sense to have this... import { routes } from './manifest/client.js'; ...since that object contains more than just an array of routes. Instead it is now this (with the equivalent change on the server): import { manifest } from './manifest/client.js'; |
@ansarizafar Thanks for that last-minute save. I've spent the day thinking about it and I'm very confident that we've made the right decision. Layout components are optional; if omitted, Sapper will use a default layout component: <svelte:component this={child.component} {...child.props}/> |
This is a big PR with a lot of moving parts. So far all it does is change how routes are created — instead of constructing route objects from an array of filenames (generated from a globbing pattern), it walks over a directory building up the intermediate components it needs. As well as enabling #262, this is arguably much simpler and more robust.
Next task is to change the manifest generation from something like this...
...to something like this:
After that, the middleware needs updating to make use of the new server-side manifest, then the runtime needs updating for the client-side manifest.
There are still some details that are subject to bikeshedding, e.g. what to call the property that contains child information for each branch. (I'm leaning towards
child
— it'd only be a problem if someone explicitly added achild={...}
property on the<svelte:component>
that introduced a child component, and the docs would tell you not to do that.)