Tech enthusiast, passionate software engineer and hardcore dark mode advocate
Antoine
Loading...
One should make a quote-of-the-day-like API from inspiring Patak posts
There is more and more good ones to pick from!
I want to talk about being a software engineering manager in a world where AI is changing everything all at once.
First, change is hard on humans. Even good change is stressful. People are built for survival, which means: if you aren’t dying, keep doing whatever already “works”
It's not that bad of a point by itself, because you can now opt-_out_ of the reactivity if you somehow need to, and you get the ability to be more expressive with $derived.by in the template, but yeah
The main issue is about reactivity related to Svelte block, something hidden from the user before. Is an {#each} loop variable a $state? Is a snippet prop a $state?
This requires either codebase layers digging or internal knowledge, which can only be mastered by tooling or time
Honest feedback about this after migrating everything in SC
Pros:
- Same mental model as in the script tag
- Same syntax as in the script tag
- Native syntax
Cons:
- More verbose (with deriveds), especially for simple things like `{let Component = $derived(icon)}
- But the worst part for me is...
It's probably a tooling issue, though: the LSP should tell you if you miss reactivity, as it does in the script tag with state_referenced_locally.
It successfully throws it as soon as you introduce a $state or $derived and depend on it in another {let ...}, but not with external data sources.
So yeah, TL;DR I *love* the feature and using it, but a tooling improvement would be welcome, if possible, to avoid having to _think_ about reactivity in the template! :D
I desperately need a big whiteboard in my office
Planned for a year and still haven’t got my hands on one
It’s very handy for things like–purely generic and hypothetical–software breakdowns and redesigns
...the "fear" of accidentally losing reactivity.
With @const, reactivity was taken for granted (as for every state used in the template); now, you have to be careful about it.
It's the other side of the coin of my "same syntax" pro-point: explicit reactivity made its way into the template.
