-
-
Notifications
You must be signed in to change notification settings - Fork 6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore(create-app): update svelte templates #2611
Conversation
…in-svelte Adds technical considerations to README Remove unnecessary complexity from store
006d00f
to
f85b94b
Compare
@antfu we already discussed this with @GrygrFlzr in Discord, and I tested both templates locally. I think we can merge after your review. |
Though: it is interesting that the Svelte plugin will live out of Vite's monorepo while the Vue and React plugins live in Vite's monorepo. I don't think it is bad since it is good that the Svelte team can modify the plugin without going through Vite's PR process. Maybe at one point in the future, the Vue and React plugins may also end up being maintained in separated repositories. |
export function getStore<T>(id: string, initialValue: T): Writable<T> { | ||
return stores[id] || (stores[id] = writable(initialValue)) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be best if we only export a counter store? This might probably break HMR, but it's weird to have this pattern in the starter template.
Or we can also simplify this and have a normal count
variable in Counter.svelte
with // @hmr:keep
per rixo's idea in Vite Land?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this getStore function originated from a playground in svite where i used it for testing purposes. I think it is overkill in a minimal starter template and may not even be a good idea in production use in general.
+1 for a more simple solution
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From what I can tell our options are:
- straight up an external
writable()
store with no id:State is preserved across all updates except toimport { writable } from "svelte/store"; export default writable(0);
store.js
itself, which is intuitive, but also doesn't reflect how people use local state in components. // @hmr:keep
on the single counter variable// @hmr:keep-all
on the componentpreserveLocalState
invite.config.js
- but this was disabled by default for a reason.
With options 2-4, state is lost upon updating App.svelte
, as the Counter
component is recreated. We're just picking which flavor of poison to go with.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I discussed this further with dominik over Discord and decided on a fifth option: the default of no local state preservation. The crux of the issue is that its complicated enough to hide behind flags, so like @sveltejs/kit
it's likely best to keep disabled, and the behavior can be explained in the README.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I strongly believe we should go with option 2. It sidesteps most difficulties, and hints just the right amount of information to maximize people's understanding and learnability.
Enabling preserveLocalState
by default goes against the grain of "no friction HMR", I believe, because its behaviour is hard to anticipate and predict intuitively. Because of this, it makes HMR feel more fragile and unreliable than it actually is, hence lessening its value for the user (HMR value is all about being confident that your change are reflected the same way they would be without it, any glitch or unpredictability eats hard into this confidence). Furthermore, the difficulties created by preservation of state are all but exacerbated in Svelte, since any random let
variable is a piece of state in Svelte components.
Stores sure are cool and all, but I don't think they have much to do with HMR at this point. State existing in other modules that are not traversed by a HMR bubble is always preserved (otherwise that wouldn't be HMR). Also, there's little doubt that a user of Svelte will soon enough be exposed to lot of documentation and information about them. As such, HMR-wise, I'm pretty neuter to have them or not to have them in a starter example.
On the contrary, most people will never read any bit of HMR docs (we don't want them to have to), and so illustrating that the capacity (preserving local state) exists, and demonstrating the existence of the // @hmr-keep
comment is probably the best we can achieve. It non-obstructively hints people about the situation, giving them some hook for something to search about, if they're so inclined.
Other magic HMR comments like // @hmr:keep-all
are kinda out of scope for a starter, to me... People will find about them, googling for // @hmr:keep
, if they're interested into it. Otherwise, they're not so useful I guess. And HMR is not about HMR, it's about a nice dev experience, and so less docs / information / noise about it is probably the better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@GrygrFlzr To be clear, my last comment was started and sent before your last one, that I just discover. I still personally believe having the behaviour and magic comment trick illustrated rather than documented would probably be the best trade off, but I'm rather good with any direction this can take, except for enabling preserveLocalState
by default. This one has really proven confusing and detrimental to the HMR experience in the past, and I much more prefer having the occasional user that is disappointed not to have their counter keep its value, which is really a minor inconvenience, than risking to feed and grow a general sentiment of "yet another broken HMR".
I'd love to see this merged rather sooner than later. |
ec417e7
to
abd51a8
Compare
@svitejs/vite-plugin-svelte
to@sveltejs/vite-plugin-svelte
Going forward, this will be the maintained version.
globals.d.ts
tosrc/global.d.ts
to match SvelteKit (and iircglobal.d.ts
is the more common name).import.meta.hot
usage, turns out normal external stores work fine across HMR updates.