HNHacker News
TopNewBestAskShowJobs

opensas

47 karma · joined January 10, 2012

submissionscomments
opensas··on Thoughts on Svelte
the inconsistency comes from the fact that this reactivity, triggered from inside a function, is not taken into account to build the dependency graph and ultimately decide in which order to process the statements
opensas··on Thoughts on Svelte
top level variables are reactive even when updated inside a function, just give it a try:

https://svelte.dev/repl/44e3aece18294ddb834bcdfb4394af48?ver...

` <script>

  let name = 'world';

  const flip = () => name = name === name.toUpperCase() ? name.toLowerCase() : name.toUpperCase()

  $: console.log({ name })
</script>

<h1>Hello {name}!</h1>

<button on:click={flip}>flip!</button> `

opensas··on Thoughts on Svelte
> The $ label is one technical reason why I would be hesitant to adopt Svelte for larger projects. It's a core part of Svelte that you can't always avoid, and I think the potential for introducing bugs through it is high to start and very high at scale.

The reactivity system in Svelte is really a joy to use, once you get used to it there's no turning back.

But the author did hit one of the ugliest pain points about it. Svelte can NOT correctly infer transitive dependencies when the variable being updated is inside a function. Meaning that the variable itself will be reactive (it will be invalidated every time it's assigned, even inside a function) but Svelte is not using that information to build the dependency graph, and falls back to the order in which the reactive blocks were defined, which may or may not be right.

I created this issue https://github.com/sveltejs/svelte/issues/5190 a couple years ago documenting it.

It's not so common, but when it bytes you it's pretty nasty.

The workarounds I found are the following

These are the workarounds I found:

- a repl with the issue: https://svelte.dev/repl/640736d3c91d40d3971afcc3eef8b25e?ver...

- workaround 1: manually reorder statements, need to figure out by yourself (and maintain!) the dependency graph: https://svelte.dev/repl/3ecd6aa918e045999db32d379270fc1c?ver...

- workaround 2 (my favorite): provide a redundant update as "hint" to tell the compiler that setY updates y: https://svelte.dev/repl/cbf98bb35f5e4dd4b037d13254853c90?ver...

(thanks to TylerRick for this: https://github.com/sveltejs/svelte/issues/5190#issuecomment-...)

in practice it means to do something like: `$: { setY(x); y = y };`

- workaround 3: put the update operations in order in a single block (it's just the workaround 1 with improved legibility, IMHO): https://svelte.dev/repl/074df362bb934312bbe6fd3aeccab771?ver...

I still think we could do better, at least explaining the issue and how avoid to fall into it (perhaps some linting warning?)

But I really hope svelte developers start considering this an issue to solve, it's inconsistent (meaning the variable is reactive but that reactivity is not taken into account to order the operation in "topological order" (Hey, I learnt about that from one of Rich's presentations, see https://rethinking-reactivity.surge.sh/#slide=19) and as I said before, in the rare occasions you stumble upon it is not so easy to understand what's going on.

opensas··on Writing Reactive Apps with ReactiveMongo and Play
great article...
opensas··on Play Framework 2.0 Final released
and a shiny new play framework site http://www.playframework.org/
opensas··on Playframework + Google Guice
here's another interesting link http://www.dzone.com/links/dependency_injection_with_play_fr...
opensas··on First steps with Scala, say goodbye to bash scripts…
nothing - http://playlatam.wordpress.com/2012/01/13/first-steps-with-s...
opensas··on First steps with Scala, say goodbye to bash scripts…
I've found out that with the -savecompiled option the delay is not so pitiful... see http://playlatam.wordpress.com/2012/01/13/first-steps-with-s...
opensas··on First steps with Scala, say goodbye to bash scripts…
Why wouldn't it run on any unix, linux, or windows, or wherever a JVM can run? you should run it with "scala status.scala"

apart from that, I came to a similar conclusion: http://playlatam.wordpress.com/2012/01/13/first-steps-with-s...

opensas··on First steps with Scala, say goodbye to bash scripts…
yeap, python is pretty cool, see http://playlatam.wordpress.com/2012/01/13/first-steps-with-s...
opensas··on First steps with Scala, say goodbye to bash scripts…
thanks for the tip, here's my bash version http://playlatam.wordpress.com/2012/01/13/first-steps-with-s...
opensas··on First steps with Scala, say goodbye to bash scripts…
Thanks to everybody's feedback on this one... You encouraged me to write another article, mainly because I felt a little guilty for bashing (pun intented) bash and python ;-) Hope you like it http://playlatam.wordpress.com/2012/01/13/first-steps-with-s...
opensas··on First steps with Scala, say goodbye to bash scripts…
I tried it, and got:

sas@ubuntu:~/devel/apps/playdoces/documentation/1.2.4/manual/tmp$ ./status.scala error: script file does not close its header with !# or ::!# one error found

opensas··on First steps with Scala, say goodbye to bash scripts…
you're right jez, I guess I couldn't resist the temptation of a catchy title, just changed it to: First steps with Scala, a functional alternative to bash scripts… I think it's more appropriate: http://playlatam.wordpress.com/2011/12/05/first-steps-with-s...