Alternative implementation for #if

[adiguba]

Hello,

I'm not sure where is the best place to put this, but I have some thoughts on the implementation of {#if} in Svelte.

1. There is no real else/if, since it actually turns into several nested $.if() call.
2. When using transitions, the order of the elements is not fixed (blocks are added at the end of the anchor, unless the transition is canceled).
3. On large if/else, SSR code will generate multiple couple of markup comments like <--[--><--]--> or <!--[!--><--]-->
4. Tree shaking can be performed on the server side, but not on the client side (where it is most useful).

I tried to make an alternative implementation, and I wrote a new function $.choose() to replace $.if() (which I kept for compatibility)

1. An unique $.choose() is used for an {#if}{:else if}{:else}{/if} block, whatever the number of else/if.
2. The order of the elements are respected (useful with transition).
3. SSR will generate only one couple of markup ( <--[--><--]-->, <!--[1--><--]-->, <!--[2--><--]-->, ... or <!--[!--><--]-->
4. Client code is an JS if/else statement, so it can be tree-shaked properly.

You can play with it here : https://adiguba-svelte-5-test-git-if-alt-adigubas-projects.vercel.app/
And check the code here : https://github.com/adiguba/svelte/tree/if-alt

---

A simple example (see generated code) :

• Current Svelte : REPL
• New implemention : REPL

=> The generated code is a little shorter, but it is above all a real if/else in javascript !

Another exemple with transitions : elements are added to the DOM based on others conditions, so when using transition the blocks are on the same position.

• Current Svelte : REPL
• New implemention : REPL

=> On current Svelte elements are added from the bottom, unless we interrupt a transition.
So sometime the IF is below the ELSE...
On the new implementation the IF is always before the ELSE.

---

Remark :
I launched pnpm test, and it break 2 tests :

• runtime-legacy transition-js-deferred, because the order of the elements is now fixed.
• runtime-legacy if-block-else-conservative-update is also broken, because when a signal is emitted, the conditions will be checked again in order, contrary to the current behavior.
  I don't think there is a solution to this that is compatible with tree-shaking, so it's a breaking-change

I think this can be a good PR and I would create it if it makes sense...
But perhaps post 5.0 ?

Thanks for reading

[7nik]

Have you seen #13246 (comment), in particular the last example?

[adiguba]

I hadn't seen.
I'm looking at that...

[adiguba]

I have looked at #13246 and the expression metadata in order to generate a good old if(), but it seems complex to me and with incompatibility, for a small gain.

For the last example about the inner block, it's not a problem with my implementation.

See theses examples :

• Svelte 5 : REPL
• New version: REPL

---

Also this implementation is already compatible with tree-shaking since it uses a good old if().

=> Currently this code :

{#if DEV}
	<BigDebugComponent />
{/if}

is compiled to

	$.if(node,
		() => DEV,
		($$anchor) => {
			BigDebugComponent($$anchor, {});
		});

And the tree-shaking cannot do anything better than that :

	$.if(node,
-		() => DEV,
+		() => false,
		($$anchor) => {
			BigDebugComponent($$anchor, {});
		});

But with this new version, the {#if DEV} will be compiled into this :

	$.choose(node, () => {
		if (DEV) {
			return [
				0,
				($$anchor) => {
					BigDebugComponent($$anchor, {});
				}
			];
		}
	});

which allows tree-shaking to remove much more code :

	$.choose(node, () => {
-		if (DEV) {
-			return [
-				0,
-				($$anchor) => {
-					BigDebugComponent($$anchor, {});
-				}
-			];
-		}
	});

And the $choose() will handle the possible mismatch in hydration...

[farfromrefug]

@adiguba i love this and really need this. However i would need this on svelte 4 as we cant switch to svelte 5 anytime soon (we need a custom renderer ).
Do you think your implementation can be ported to svelte 4?

[7nik]

I don't really get why you need this. It only brings in tree-shaking of unused branches. And in Svelte 4 ifs are tree-shakable.
Svelte 4 and Svelte 5 internally are entirely different, and Svelte 4 is much harder to comprehend.

[adiguba]

Yes after looking at the generated code on the REPL, in Svelte 4 this code :

{#if CONDITION1}
	CONDITION1
{:else if CONDITION2}
	CONDITION2
{:else if CONDITION3}
	CONDITION3
{:else}
	ELSE
{/if}

is translated into something like this :

	function select_block_type(ctx, dirty) {
		if (CONDITION1) return create_if_block;
		if (CONDITION2) return create_if_block_1;
		if (CONDITION3) return create_if_block_2;
		return create_else_block;
	}

Which is already tree-shakeable...

[farfromrefug]

@adiguba @7nik thanks. From my tests it was not tree shakable. But it seems as you say that it is!
My test was a bit "bigger" and that might have been the problem.
I wanted to create a custom component like this:

{#if __IOS__}
    <slot />
{/if}

The idea behind that would be to not have to do :

{#if __IOS__}
    ...
{/if}

in my code but instead be able to do :

<ios>
 ...
 </ios>

It already works but i wanted tree shaking to work the same in both cases (like remove it all if __IOS__ is not defined).
My first tests show that the <ios> component was still there. Maybe even if the #if is actually tree shaked, the <ios> component is while still being empty

[adiguba]

@farfromrefug : yes if you create a component, the only thing that can be tree-shaked is the <slot/> call in the component.
But the caller code will still contains all the stuffs...

=> You have to use an {#if} for that !

Another solution would be to use a preprocessor.
Quick example :

function createIOSPreprocessor() {
	// regexp to find <ios> ** </ios> :
	const regexp = /<ios>(.*?)<\/ios>/gs;
	// replacement (preserve the content on IOS, or strip all)
	const replacement = __IOS__ ? "$1" : "";

	return {
		name: 'IOS-Preprocessor',
		markup: ({ content }) => {
			const code = content.replaceAll(regexp, replacement);
			if (code !== content) {
				return { code };
			}
		}
	};
}

And in your svelte.config.js :

const config = {
	// Consult https://kit.svelte.dev/docs/integrations#preprocessors
	// for more information about preprocessors
	preprocess: [createIOSPreprocessor(), vitePreprocess()],
	
	...
}

[farfromrefug]

@adiguba amazing idea. love it! Will do exactly that. Thank you!

[trueadm]

@adiguba It would be great if you could put up an up-to-date PR for this. I'd love to dig into the failing test case and see if we can resolve that.

[adiguba]

@trueadm : I wouldn't have time for that right now, but I could do it in a few days...

[trueadm]

I can create a new PR that adapts your code on top of my changes. I have some further optimisations that we can do to improve the runtime overhead.

[adiguba]

Nice !

[adiguba]

@trueadm : actually there was no conflict and I was able to merge it quickly.
I have to open a PR or do you do it directly ?

[adiguba]

@trueadm : I opened the PR : #14551
Close it if it's easier for you to create another one...