So basically $derived is a calculation and $effect is a watcher? Btw, that is golden. First example on RU-vid that clearly shows the concept of runes. I wasn't very excited with the syntax I saw till now. And that $props thing is fascinating. That's gonna ease a lot of parent/child communication
The way I understand it is that $derived helps us keep values up to date in a simple way. If we have const testValue = $derived( variable1 + variable2 + variable3); Then if any of the variables inside of $derived change, testValue will get recalculated. I believe (I could be wrong) that in the old versions of Svelte, if you just said "testValue = variable1 + variable2 + variable3" the client would not update to the up to date value in certain cases. So the reason for the different syntax is to ensure the value will always be up to date. $effect can be understood as a way to introduce functionality 1. On initial component load and 2. When variables within the $effect change. It differs from $derived because within the effect we can create any functionality we want (whereas $derived is just a recalculation), although my was simple, you can create any functionality specific to the effect which is really interesting. Hopefully this helps! I'm also just learning the new syntax along you all but have done enough working around to create an intro video on it, glad the video was helpful for you :)
$derived is very similar to useMemo in React. I primarily use it for derived states. A more real-world example would be if you want a Select Option to change based on the currently selected state (like filtering them) let selectedColor = $state("red") const colorOptions = ["red", "green", "yellow"] const allFoodOptions= [{ color: "red", value: "apple" }, { color: "red", value: "tomato" }, { color: "green", value: "spinach" }, { color: "yellow", value: "banana" }] let foodOptions = $derived( allOptions.filter((option) => option.color === selectedColor ) ) ---
Not exactly. It's just made way better. You will not run into many pitfalls like in the React (f.e. all of the weird implicit useEffect() behaviors) But it will actually make codebase simpler, because now Svelte scripts will be JS in 100%. They will not change the semantics like with export let (which defined a prop instead of exporting a module). So f.e. you can write some logic, put into into Svelte file and it will behave exactly the same way like in normal JS. And you can also do it the other way around - you can now also use Svelte features outside of Svelte files f.e. use $state() and $derived() in some external JS files
@@DEVDerr "...use $state() and $derived() in some external JS files" That indeed would be very useful. When I've run into that problem, I've used lihautan's work-around(s), found on RU-vid under "How to use Svelte store in .js file?"
@@nickstaresinic4031 It was not a workaround really. The only way to use Svete's reactivity outside of Svelte files was actually using a Svelte's built-in store. Which wasn't that big of a problem really, it was actually nice that you could update/retrieve data in some JS/TS files and I love that (especially while creating games). But now it will be even better, because $state and $derived behave more like primitives. You can compose them together and create reusable stateful logic (like with Hooks in React) but with all of the Svelte's performance and DX benefits