Unable to use return in reactive expression

[taylorzane]

When using a return statement in a reactive expression/block an error is thrown:

'return' outside of function (L:C)

Since the reactive expression contents is wrapper in a function at compile time, this shouldn't cause any syntax errors at runtime.

I imagine this will require changes to the svelte compiler and also the eslint plugin rules.

See a simple repro here:

https://svelte.dev/repl/8ca16f5088c34dd89574a064868d9b4d?version=3.4.1

[EmilTholin]

Hi @taylorzane! You can make the if statement reactive directly if you prefer.

$: if (count <= 10) {
  bar = 'bar' + foo
}

[taylorzane]

Hey @EmilTholin, I appreciate the advice. I know I could rewrite the expression as a whole to suit the existing syntax, and perhaps this is a wontfix since it's not "technically" valid JavaScript when uncompiled, but I figured I'd bring it up since the end result would still be valid JS.

[tivac]

Labels not being treated as a function by the compiler comes back to bite me a lot since I prefer to use early-outs whenever possible.

$: {
    if(!case) {
        return;
    }

    doWork(case);
}

This case can obviously become a simple if/else, but they're not always that simple. The inability to use return or continue or some other form of "stop executing this block" is a fairly frequent annoyance for me in v3.

[taylorzane]

👆 That right there is exactly why I'd like support for this. It also keeps nesting at one level lower than using a wrapping if/else.

[EmilTholin]

Yeah, I can see the appeal, but I would personally rather opt for using an IIFE than start treating blocks as functions.

$: (() => {
  if (count > 10) {
    return
  }

  bar = 'bar' + foo
})();

[tivac]

I think in my ideal world the svelte compiler would be able to see that pattern and remove it to keep the code streamlined, paying the cost for IIFE every time a reactive statement runs isn't something I'm super comfortable with.

[ryanatkn]

A possibility would be to have the compiler interpret a bare function following the $: label as an IIFE, because right now it's a no-op. This is somewhere in between the IIFE workaround and the proposed reactive blocks-as-functions.

$: () => {
  // this could be interpreted as an IIFE instead of a no-op: "anonymous reactive function"
}

There's tension between the code you'd ideally write (returns in blocks with compiler smarts) versus code that matches expectations of JS and works better with e.g. TypeScript. I'm curious what Svelte's philosophy is here, what costs will be paid to write more ideal code. Elm is a good example of a language+framework that pays seemingly anything to get to its ideal form.

[Rich-Harris]

This is a little trickier than just deciding to allow return — we would also need to hack around Acorn so that it accepted a return outside a function (the same could go for break or continue or whatever). It would also get tricky in terms of the generated code — if you add another reactive line...

let count = 0
$: {
  if (count > 10) return;
  bar = 'bar' + foo
}
	
$: somethingElse = bar + 'whee';

...Svelte generates this:

$$self.$$.update = ($$dirty = { count: 1, foo: 1, bar: 1 }) => {
  if ($$dirty.count || $$dirty.foo) { {
    if (count > 10) return;
    $$invalidate('bar', bar = 'bar' + foo)
  } }

  if ($$dirty.bar) { $$invalidate('somethingElse', somethingElse = bar + 'whee'); }
};

In other words it would fail to update somethingElse.

These aren't intractable problems, but it's definitely not something that's straightforward to fix. @tivac's suggestion is the one I like the most — Svelte could generate this from that example:

function $$update_bar() {
  if (count > 10) {
    return
  }

  $$invalidate('bar', bar = 'bar' + foo);
}

$$self.$$.update = ($$dirty = { count: 1, foo: 1, bar: 1 }) => {
  if ($$dirty.count || $$dirty.foo) $$update_bar();
};

[thgh]

It's not valid JavaScript so it would break prettier and other tools. 🤔

[trbrc]

Unless the benefit is proven to be very substantial, I don’t think additional creative interpretations of JS semantics will be good for Svelte. I object to it being included on a whim. I’m afraid that this stuff will pile up and lead to unexpected issues in the future.

Using an IIFE as @EmilTholin suggested looks like a good choice. I see at least three solutions to @tivac ‘s performance objection to it:

• Measure whether it’s even an issue. Is an IIFE expensive in the real world? I don’t know much about JS engines, but unless it’s known to be difficult to optimize, I wouldn’t sweat it.
• Use a plain function declaration, instead of an IIFE, and call it as a reactive expression passing in the variables that should invalidate it as arguments. ($: myFunc(count, foo);)
• Make Svelte analyze a reactive declaration with an IIFE and “unwrap it” when possible. (As @Rich-Harris points out, it might be tricky in plenty of common cases though)

[taylorzane]

It seems like there's a decent amount of overhead for an IIFE compared to no IIFE (see benchmark). Obviously that's a very naïve test and not indicative of actual usage in a Svelte component. Personally, I have no preference as long as we can get some sort of bail early functionality.

[ryanatkn]

@taylorzane

as long as we can get some sort of bail early functionality

Svelte supports IIFEs already, they just don't look great - https://svelte.dev/repl/99fd078d1bbd46088bcd6fc59e761d4d?version=3.4.4

[tivac]

Yeah, they do work but they're not handled specially so every time they run they're recreated. 😑