Review requirements for Svelte5 upgrade

[tcompa]

We should review whether any dependency is blocking the Svelte 5 upgrade (including which node version would be supported/deprecated), and evaluate whether it's a goof time for this upgrade.

[zonia3000]

The application has been migrated to Svelte 5 in PR #789. I'm writing here some considerations about the changes.

Svelte 5 is very different from Svelte 4 (way more different than the jump from Svelte 3 to 4), in particular it is now necessary to explicitly mark which properties are reactive using the $state function. This makes it more similar to React.

Relevant migration issues

Loops in $effect

Old reactive blocks, e.g.:

$: {
  if (condition) {
    doSomething();
  }
}

has been automatically migrated by the migration script using $effect:

$effect(() => {
  if (condition) {
    doSomething();
  }
});

However, in several cases that caused infinite loops issues that has been manually fixed.

Warnings like this appeared during the migration:

Detected a migrated `$:` reactive block in `src/lib/components/common/StandardDismissableAlert.svelte` that both accesses and updates the same reactive value.
This may cause recursive updates when converted to an `$effect`.

In our code the infinite loops appeared mostly when we used a reactive block to detect the changes of a given property, similar to the problem described in this issue: sveltejs/svelte#10236

Sometimes I solved it using $derived (that allows to create a property based on another property), sometimes I had to introduce a second, not-reactive, variable, that was quite annoying.

For example, in our FilteredTasksTable, in Svelte 4 we had this block to automatically recompute some values when the task groups changed:

$: if (taskGroups) {
  setup();
}

In Svelte 5 the task groups need to be copied to another variable to prevent infinite loops:

/**
 * Needed to prevent infinite loop in $effect
 */
let storedTaskGroups = undefined;

$effect(() => {
  if (storedTaskGroups !== taskGroups) {
    storedTaskGroups = taskGroups;
    setup();
  }
});

Calling JSON.stringify on reactive variables

Another annoying thing is that now all reactive properties are a kind of proxy to the real object. This has an impact to the result of JSON.stringify. In some places we used JSON.stringify to make some comparison between old and new values of complex objects and that thing was broken by the migration. It is necessary to use the $state.snapshot function to extract the original value if we need to use JSON.stringify:

const original = $state.snapshot(originalSettings);
const edited = $state.snapshot(editableSettings);
// now comparison can be performed
return JSON.stringify(original) !== JSON.stringify(edited)

JSON schema form bindings

In our JSON schema form component we had a lot of these warnings:

[svelte] binding_property_non_reactive
`bind:value={formElement.value}` (components/src/lib/jschema/properties/StringProperty.svelte:34:3) is binding to a non-reactive property
https://svelte.dev/e/binding_property_non_reactive

I solved them changing all the FormElement classes to use a writable variable for the value field.

This required some more verbose code in all the properties.

For example, in StringProperty we had the following in Svelte 4:

/** @type {import('../form_element.js').ValueFormElement} */
export let formElement;

Now we need this:

/** @type {Props} */
let { formElement = $bindable() } = $props();

let value = $state();
formElement.value.subscribe((v) => (value = v));
$effect(() => handleValueChange(value));

Removal of @vincjo/datatables

The changes impacted also the usage of our dependency @vincjo/datatables, which we used in version v1, that was not compatible with Svelte 5.

The library has a migration guide to v2, that supports Svelte 5 https://vincjo.fr/datatables/docs/server/getting-started/migration

I followed the steps but realized we were using the library incorrectly, making it difficult to port to v2. The library has two variants: client-side table (where pagination, sorting and filtering are done client side) and server-side table (where all the logic is done server side). We were using this library only in the jobs tables, where we don't have pagination. While we needed client-side sorting and filtering, we also required background updates for running jobs. In v2, updating the table in background was possible only doing some ugly workaround, because the library updates the table calling automatically the configured backend endpoint when the user performs some action (like clicking on a sorting button). Moreover, we used SlimSelect for the filtering, and we were handling the filtering manually. So, at the end, we were using the library only for the sorting, while doing everything else manually. I ended up removing the library completely and handling manually the sorting too. This resulted in cleaner code and fewer limitations.

---

I've also upgraded some other dependencies:

• vite-plugin-svelte: from 3 to 4
• eslint-config-prettier from 9 to 10
• eslint-plugin-svelte from 2 to 3
• prettier from 2 to 3
• prettier-plugin-svelte from 2 to 3
• vitest from 1 to 3

I tried also to upgrade to Vite 6 but I had some issues. Let's keep 5 for the moment.

[zonia3000]

Release v1.18.0 uses Svelte 5.