Special tag {@run ...}

[phcoliveira]

Hello folks.

SolidJs has a very useful component: <Navigation />. With it, we can programatically navigate to another route in the template.

While it is easy to implement such a component on Svelte, I thought of something more general.

Consider this:

{#if somethingIsTrue}
  <!-- show something -->
{:else}
  {#await goto('/somewhere-else')}
    <p>loading</p>
  {:catch error}
    <!-- handle error -->
  {/await}
{/if}

However, I usually enable loading in an app-wide system using beforeNavigate() and afterNavigate(). Also, I handle the error in a hook.

I cannot simply {#await goto()}.

An alternative would be to use $effect().

<script>
$effect(() => {
  if (!somethingIsTrue) {
    goto('/somewhere-else')
  }
});
</script>

{#if somethingIsTrue}
  <!-- show something -->
{/if}

However, such effect would not be necessary with an analogous Navigate component. But why limit ourselves with just navigation? We could invoke a function in the template, in a similar manner that {{did-insert-helper ...}} does for Ember.

{#if somethingIsTrue}
  <!-- show something -->
{:else}
  {@run goto('/somewhere-else')}
{/if}

This new special tag would invoke the function without producing any content. That's it.

[adiguba]

Hello,

I have trouble seeing the point of such syntax, but you can do this :

{#if somethingIsTrue}
  <!-- show something -->
{:else}
  {goto('/somewhere-else')}
{/if}

[phcoliveira]

I can do that, but the returned value will be converted to a string and exposed as text. Even undefined is rendered.

[adiguba]

In Svelte 5 undefined is not rendered.

But otherwise you can use a function which returns an empty string :

<script>

   function then_goto(page) {
      goto(page);
      return "";
   }
</script>
{#if somethingIsTrue}
  <!-- show something -->
{:else}
  {then_goto('/somewhere-else')}
{/if}

[phcoliveira]

Thanks for pointing out that undefined, and also null, are not converted to a string and rendered on Svelte 5. That way, there is no need to return an empty string. This would do:

   function then_goto(page) {
      goto(page);
   }

However, I don't think such solution would be as refined as having a dedicated {@run } special tag. Consider this:

{goto('/foo')}

It still interpolates to [object Object] because goto returns a promise. You would have to "mind" what the returned value is and, depending on it, wrap a function in another function just to make it return void. Not great DX.

Furthermore, {@run } could be like a function to be used with use:. For example:

<script>
function track() {
  myTracking.track('view');

  return () => myTracking.track('left');
}
</script>

<h1 use:track>Foo</h1>

Ember also "suffers" from this in the sense that it recommends a modifier. But this also means that a modifier has to be attached to an element, just like the use: seen above.

In fact, the function track() does not depend on any element, as it does not modify it in any way. As I said, Ember also has this problem. The invocation of track() should not be tied to an element.

With {@run }, which would correspond to ember-render-helper, the invocation of track would be independent of any element.

[rChaoz]

You can also use:

{goto('/foo') && null}

Which does exactly what you want, doesn't render anything. If the first function returns null, it's all good, else you force the value to null with &&.

Edit: Apparently the void operator exists, which is probably better.

[brunnerh]

I don't think it's a good idea to have side effects in the template, it is not intended for that.

[phcoliveira]

You could use a wrapper function:

<script>
  import {track} from 'my-tracking';
  const { foo } = $props();

  function canShow() {
    if (!foo)
      track('cannot show foo');

    return foo;
  }
</script>

{#if canShow()}
  <!-- ... -->
{/if}

(Though there might not be any guarantees how often the function will be called in practice. Again, an issue with having side effects in the template.)

I am going to check if this works, as I am afraid that canShow() is not reactive. I believe that you would need a $derived state, like this:

<script>
import {track} from 'my-tracking';
const { foo } = $props();

const canFoo = $derived.by(() => {
  if (!foo) {
    track('cannot show foo');
  }

  return foo;
}
</script>

{#if canFoo}
  <!-- show foo -->
{/if}

But that would be much worse, IMHO. Firing an effect while deriving a state is analogous to have an effect while computing a getter in classical OOP.

[brunnerh]

(My statements were specific to the navigation use case. There it is better to not load a page in the first place if you were to just navigate away immediately anyway.)

[brunnerh]

I am afraid that canShow() is not reactive.

It's reactive as long as the prop is reactive (example).
$derived adds nothing except caching, which could be useful here to prevent calling track more than necessary.

[phcoliveira]

Cool, thanks! I will take that in consideration.

[phcoliveira]

Since Svelte 5 does not render undefined or null, this works:

{#if foo}
  <!-- foo -->
{:else}
  {void goto('/somewhere-else')}
{/if}