Sapper: 0.29 planning

Created on 21 Sep 2020  路  19Comments  路  Source: sveltejs/sapper

I would like to propose the following breaking changes for 0.29:

breaking

Most helpful comment

@benmccann how about https://github.com/sveltejs/sapper/pull/1427 ? :)

All 19 comments

I believe there are people currently using the fact that segment is undefined on error pages as a workaround for detecting that situation, so I think it would be nice to expose this information officially on the $page store in the same version as we remove segment. There's a PR open for this, but I have not looked at what it does or how it does it.

Ah, good call out. That PR looks pretty solid. I'll probably merge it after one more review iteration

Please leave #824 open for discussion. Maybe even move this to the next release. I think we should first see some real world examples, side by side, to make sure this change doesn't unnecessarily increase the codebase of your average (and/or more complex) sapper application.

The segment prop is useless and can be easily replaced with $page.path which has nested route support (such as '/path1/path2').

After thinking about it, I do not have any problem with segment, but how layouts work. It would be better if sapper has layouts that work similarly to nuxtjs.

The segment prop is useless and can be easily replaced with $page.path which has nested route support (such as '/path1/path2').

When marketing Svelte people often make the point that the amount of bugs in your project increases as your codebase grows. This is why I would like to see a real world example before we make changes like this. If this way of doing things increases the amount of code we have to write, removing the segment prop would be a total waste. Its presence is and/or does not have to hurt anyone.

NASA wouldn't launch a rocket without testing each individual part and group of parts separately. We shouldn't either.
Especially when it is a breaking change like this one that will require people to possibly rewrite a lot of small parts of code.

Here: https://svelte-materialify.vercel.app/getting-started/installation/
The highlighting of left navigation items is taken care of using the page store.

Here: https://svelte-materialify.vercel.app/getting-started/installation/
The highlighting of left navigation items is taken care of using the page store.

In some other components of the docs you still use 'segment'. Idk if you've committed the changes already.
https://github.com/TheComputerM/svelte-materialify/blob/master/packages/docs/src/routes/_layout.svelte

Imagine a application with a sidebar, a top navigator, secondary top navigator, both navigators having multiple modals and dropdowns each being their own component, a footer with differently styled sitemaps, bla bla bla.
One simple sidebar isn't a good example because often applications have more than that.

Ofc there is also the fact that if you have an application like this segment may not always be sufficient. I get that. But that is exactly why I want to see a real world example of an application that has slightly more going on. The changes being in 1 simple commit would be ideal so we can compare the amount of code and if the tradeoff is worth it.

I upvote the "Remove trailing slash from service worker manifest" as it has broken my references to global.css, as I reference them like this global.css?v=TIMESTAMP. My stylesheets don't load anymore after the service worker has been activated. The bug can reproduced by simply adding on "?v=2" to the reference to global.css in template.html.

@benmccann how about https://github.com/sveltejs/sapper/pull/1427 ? :)

@benmccann how about #1427 ? :)

Looking forward to this one too. Also the other pull that adds the 'focus' event listener.
edit: https://github.com/sveltejs/sapper/pull/921

Remove leading slash from service worker manifest by reverting <-- please and thank you ! 馃憤

Needs to base it self off the url given in server.js

Also, after working with both rollup and webpack in sapper, better support for webpack would be beneficial as webpack provides inbuilt HMR and better bundling.
Even Rich Harris has written that Use webpack for apps, and Rollup for libraries
Maybe integration with snowpack would be easier with better webpack support?

sveltejs/svelte#5428 is not part of Sapper. It's part of Svelte which is released and upgradeable independently

sveltejs/svelte#5428 is not part of Sapper. It's part of Svelte which is released and upgradeable independently

Whoops! I read my personal open issues list wrong 馃檲. Consider that question never asked!

@TheComputerM That article is no longer correct in any way, Rich's view have changed since then. And his views have also changed since his views changed. That article was written over 3 years ago.

@benmccann Do you think moving segment to a utility would be a good idea? I agree that it is a bit funky with how it currently works with layouts, but I understand there are some people who currently rely on the feature and like the minimal code.

Was thinking a utility that worked something like this might be a good middle ground -->

import { pageSegment } from '@sapper/app';
const segment = pageSegment();

https://github.com/sveltejs/sapper/issues/824#issuecomment-716760125

Do you continue to make changes to the sapper? but we never will see the v1.0?

Sapper will likely go into a maintenance mode. Svelte Kit is the primary development focus. See this video for details.

Sapper 0.29 is out with quite a few fixes. We didn't get done with everything on the list above with SvelteKit on the way, but still got lots of good improvements in anyway

Was this page helpful?
0 / 5 - 0 ratings

Related issues

UnwrittenFun picture UnwrittenFun  路  4Comments

milosdjakovic picture milosdjakovic  路  3Comments

mylastore picture mylastore  路  3Comments

Rich-Harris picture Rich-Harris  路  4Comments

nikku picture nikku  路  4Comments