Customizations

[simoneferrari]

I had the same idea as you LOL. I hate the new svelte syntax but I also hate the dollar sign.

I've written my own preprocessor which is not as good as yours but allows declarations such as

    let iconSize = r.calc(size == "sm" ? 16 : 20)
    let count = r.state(10)

    r.effect(() => {
        console.log(iconSize)
    })

where the r stands for 'reactive'

And to access these functions at design time, I copied how svelte is declaring $state, $derived etc...

Basically my suggestion is to allow customization as in v1 and not force people to use the dollar sign which is also reserved by svelte anyways so it can create headaches. For me for example it is causing issues with $props() rune (using sveltekit)

Just some ideas and keep going with this project, great job :-)

I know a lot of people won't like the new svelte syntax and they will use it I think.

[KilDesu]

@simoneferrari Although this approach is customizable, I think it makes the preprocessor lose its original purpose: make the syntax more concise. I also wanted to find a way to make the functions' name changeable but it would be a pain to add the global type for them, as it would means having to dynamically write the global type. I think the only approach to make this possible is to create a CLI helper to create the project.

Concerning the bug with the $props rune, I'll try to debug that as you don't seem to be the only one who experiences it.

[KilDesu]

Basically my suggestion is to allow customization as in v1 and not force people to use the dollar sign which is also reserved by svelte anyways so it can create headaches. For me for example it is causing issues with $props() rune (using sveltekit)

It shouldn't pose any problem for Svelte's reserved keywords as the preprocessor removes them, so Svelte's compiler doesn't see them. The problem with $props was fixed in 2d675cd687c478effb708493dc511e3d0f628f22