Rename $derived.call to $derived.lazy

[Rich-Harris]

Describe the problem

In #10240 we added $derived.call(fn) alongside $derived(expression), and somehow overlooked the fact that Function.prototype.call is a thing.

Strictly speaking this is fine — these are runes, not functions, and we can do what the hell we want. But realistically this is going to be a source of confusion at best and annoyance at worst for many people.

Describe the proposed solution

Programmers often talk about 'lazy evaluation', which basically means providing a function to compute some value rather than the value itself.

Even though the under-the-hood mechanism of $derived is that it's always lazy, meaning that this...

let value = $derived(expression);

...is syntactic sugar for this...

let value = $derived.call(() => expression);

...I think the conceptual framing is the right one. I therefore propose $derived.lazy:

let a = $derived(expression); // evaluated eagerly
let b = $derived.lazy(() => expression); // evaluated lazily

We'll also need to add an error message for anyone who is already using $derived.call, of course.

Importance

would make my life easier

[trueadm]

To me this API implies that the $default way isn't lazy somehow. I think I prefer $derived.thunk the function can't take arguments.

https://en.wikipedia.org/wiki/Thunk

[Rich-Harris]

'Thunk' is a nonsense programming word. It means nothing to most people. If you google it, this is what you get:

Svelte needs to have broader appeal than people who learned esoteric terminology while studying Computer Science

[dummdidumm]

$derived.fn 🙃

[MotionlessTrain]

This is actually more of a problem than it may look (other that being confusing):
It also messes with the Typescript definition of $derived: As $derived is typed as a function, $derived.call is automatically typed as Function.prototype.call, so $derived.call is only useable when you are not using typescript, or disable that line for the typescript compiler

Maybe $derived.invoke could work?

[Rich-Harris]

Other ideas that have come up — $derived.using(fn) and $derived.from(fn).

The main reason we didn't go with $derived.from is that we might want to use that in future for other things:

$derived.from(observable);
$derived.from(store);
$derived.from(async_iterable);

But as soon as you have one $derived.from usage in your codebase, the code for all the things it supports must be included (i.e. not treeshaken). Without a clear sense of what values we'd eventually support, and how much code they would involve, the cautious thing to do would be to avoid .from.

Another naming consideration is how we talk about these things in the abstract. One thing I particularly like about .lazy is that it allows us to talk about a 'lazy derived' (or 'lazily derived state' to be pedantic); none of the other options I've seen have that characteristic.

[lucaesposto]

1. Does $derived.lazy executes a Lazy Evaluation ?
2. Does $derived not behaves this way, instead?

If one of the answers is no, i don't think $derived.lazy can be the right choice.

[brunnerh]

I do not like this name; it cannot be lazy because the function has to be evaluated immediately to determine the dependencies. As pointed out by Dominic, it evaluates on access.

Still, the name is odd if this is just different syntax and everything is lazy by default.

[navorite]

I honestly think the original name — $derived.fn is the best one. It does exactly what it is. I don't see using full names here as a problem as it wouldn't add any value.

On the other hand, I'd rather it be $derived.call than $dervied.lazy because this gives a false impression about $dervied and would add more confusion than the current one.

[trueadm]

I do not like this name; it cannot be lazy because the function has to be evaluated immediately to determine the dependencies.

The opposite is true actually. We don't evaluate them immediately ever, and only lazily invoke them when needed. We don't need to know about their dependencies until an effect or another derived needs to know about them.

[Rich-Harris]

Things I don't love about $derived.fn:

• it's an abbreviation (and not even an acronym at that) — we generally try to avoid this in Svelte. Abbreviations aren't always obvious to people
• it's not even a universal abbreviation for function. Many people use func, for example. Some people use fun
• it's often necessary to describe interfaces in the abstract, and in this case that means $derived.fn(fn). That makes me shudder

[lucaesposto]

Things I don't love about $derived.fn:

• it's an abbreviation (and not even an acronym at that) — we generally try to avoid this in Svelte. Abbreviations aren't always obvious to people
• it's not even a universal abbreviation for function. Many people use func, for example. Some people use fun
• it's often necessary to describe interfaces in the abstract, and in this case that means $derived.fn(fn). That makes me shudder

I strongly agree.
Can we properly say that the function we provide to $derived.something is a callback?

In that case, two options come to my mind:

• $derived.callback
• $derived.fromCallback

[gterras]

let a = $derived(expression); // evaluated eagerly
let b = $derived.lazy(() => expression); // evaluated lazily

I don't understand lazy at all in this context, if I see this in someone else's code it heavily implies that something different will happen under the hood and that I should go and check the docs to understand what. There is no way to intuitively tell yourself "ho lazy just means I can pass a function" it makes no sense.

I suppose it's been discussed but couldn't find it in the other thread, what's the technical limitation to just have

let a = $derived(expression); 
let b = $derived(() => expression); 

[Rich-Harris]

what's the technical limitation to just have

If I was king of programming, overloads would be illegal. The cases where they're appropriate are vanishingly rare; they almost always end up being a source of regret.

Aside from being inherently confusing, a practical issue is that the derived value is often itself a function:

const filters = {
  all: () => true,
  done: (todo) => todo.done,
  pending: (todo) => !todo.done
};

let filter = $state('all');
let filter_fn = $derived(filters[filter]);

This won't work, because Svelte will try to set filter_fn to the result of calling the filter function (without an argument, which may or may not immediately error). To fix it you have to do this...

-let filter_fn = $derived(filters[filter]);
+let filter_fn = $derived(() => filters[filter]);

...which means you have to know to do that, which means having a deeper-than-should-be-necessary understanding of the underlying mechanics. It's just bad API design.

I'd be very slightly less opposed to it if we could say that the distinction is based purely on whether you pass a function expression rather than any function value, but there's no way to make that work with TypeScript.

[mimbrown]

What about $derived.explicit?

[Not-Jayden]

Things I don't love about $derived.fn:

• it's an abbreviation (and not even an acronym at that) — we generally try to avoid this in Svelte. Abbreviations aren't always obvious to people
• it's not even a universal abbreviation for function. Many people use func, for example. Some people use fun
• it's often necessary to describe interfaces in the abstract, and in this case that means $derived.fn(fn). That makes me shudder

I suppose there's no reason it couldn't just be $derived.function if fn is the main hangup, other than it feeling a bit gross using a reserved keyword as a method name.

I do want to defend the compute suggestion from the original PR as a contender one last time.

Thinking on it more, compute would be my leading choice at this point given it will be familiar/consistent with the API for people coming from Vue, Solid, and Angular land.

'derive' and 'compute' are essentially synonyms in this context, so I think that would be rather confusing.

Though they are more or less synonymous, I don't think the familiarity for people coming from those frameworks should be discounted, given that compute already has strong associations with the callback syntax. Plus to really split hairs, there is at least some distinction in compute being a verb suggesting it will do something with (call) the function it receives.

calling, lazy, thunk, using, from all seem like fine options to me otherwise.

[xyzqm]

What about something like $derived.complex? I think the only major difference between $derived and $derived.whatever is simply the ability of the latter to support a more complex sequence of operations.

[brunnerh]

$derived.via or $derived.by?

[qwuide]

What about $derived.do(() => expression)? And, if and when the do expressions proposal gets accepted, it can be deprecated in favor of $derived(do { expression }).

[svelte-kit-so-good]

Puruvjdev originally suggested a property on $derived, called 'function'; I suggested the universally understood shorthand 'fn'.

I still don't understand the aversion to the shorthand 🤷‍♀️. If the argument is that you'd like to keep valid-English names in Svelte, there's 'props' (a CS specific shorthand for properties?).

Edit: $derived.use would be in the spirit of Svelte re-using named concepts 😅

[gterras]

This won't work, because Svelte will try to set filter_fn to the result of calling the filter function (without an argument, which may or may not immediately error). To fix it you have to do this...

-let filter_fn = $derived(filters[filter]);
+let filter_fn = $derived(() => filters[filter]);

...which means you have to know to do that, which means having a deeper-than-should-be-necessary understanding of the underlying mechanics. It's just bad API design.

But there isn't a case where you don't immediately notice something is wrong, error or not, right? And the problem is strictly the same with the (unknown to the user) existence of a dedicated method? What if I expect this behavior to happen for whatever reason?

If I were to be stuck in this situation my first instinct would be to wrap it in a function, because that sounds worth a try, is simple and quick enough to try, and many frameworks use this in pseudo-similar cases. And that's general JS behavior too.

You have a built-in tutorial right here, simple, intuitive and easy to remember.

In any other case I am doomed to scroll through the docs in quest for a method that will not be clearly named whatever it is, and that I will have to recall and call, and also adapt my code if I switch from one to the other, and most likely wonder why Svelte compiler can't do this work for me.

That might be (arguably) better API design but that a way worse DX here.

The struggle to find the right naming in this thread and the initial one is because there is conceptually nothing to name.

[Rich-Harris]

IMHO the similarity between $derived.do(() => {...}) and $derived(do {...}) is a mark against it — when the time comes to deprecate it, it'll be confusing to say 'get rid of all your derived do occurrences and replace them with derived do'.

If the argument is that you'd like to keep valid-English names in Svelte, there's 'props' (a CS specific shorthand for properties?)

Yeah, we have $props and we tried like hell to come up with an alternative. But it's in such universal usage among UI frameworks that we'd spend the rest of our days responding to people asking 'why didn't you call it props?' But no, it's not a CS thing, it's a colloquialism that gained traction organically.

But there isn't a case where you don't immediately notice something is wrong, error or not, right?

The emphasis is on the wrong word! It should be on the something. An error like 'true is not a function' is only so helpful when you're trying to figure out what happened.

And the problem is strictly the same with the (unknown to the user) existence of a dedicated method?

...no? I'm not sure what you mean here. Without an overload, the behaviour is consistent and predictable — even if I don't know about the variant, I can always do $derived(whatever()) to get the same result.

In any other case I am doomed to scroll through the docs in quest for a method that will not be clearly named whatever it is

That's just not true. You'll learn about $derived and $derived.whatever at the same time, and all you need to remember is that the .whatever follows $derived. Autocomplete will take care of the rest, as soon as you type $derived..

[Rich-Harris]

By the way, I'll grant that there are convincing arguments here against lazy. The challenge I'll set for the crowd is this: come up with a word that will feel as natural in actual usage —

"we're going to create some state here, and then we're going to have some derived state, and then — because this is a more complex bit of logic — we're going to create a <x> derived"

"ah, looks like we're going to need to turn that derived into a <x> derived"

etc. I think @danielzsh's suggestion of 'complex' is probably closest, though it seems less like a description of the thing itself than a description of a frequently co-occurring property of the thing

[eddiemcconkie]

What about $derived.run()? It seems similar in meaning to call, but without the naming conflict

[mimbrown]

• $derived.spelledOut (rune pun)
• $derived.byCalling (or just calling)
• $derived.fromFunction
• $derived.extended
• $derived.multiline
  @eddiemcconkie beat me to $derived.run

[gterras]

The emphasis is on the wrong word! It should be on the something. An error like 'true is not a function' is only so helpful when you're trying to figure out what happened.

something cannot refer to anything else than the couples of lines involved, this would take a few seconds to debug at most even to beginners. It happens once and you are now good to go, your brain picks it up because it's familiar and intuitive.

Plus the error case is highly specific to some constructs like this one (not used by beginners), else it just works or worse case you just got a non-working reactivity like you already can today in many ways.

...no? I'm not sure what you mean here. Without an overload, the behaviour is consistent and predictable — even if I don't know about the variant, I can always do $derived(whatever()) to get the same result.

But.. I have to know this and also have to come to a point where it doesn't behave like expected first? So strictly the same situation?

That's just not true. You'll learn about $derived and $derived.whatever at the same time, and all you need to remember is that the .whatever follows $derived.

Which screams your own words you have to know to do that and it's just bad API design :

"Here's own to do a thing, but wait, don't forget to scroll down and learn this other thing else you will get stuck at some point".

That's truly terrible, half of the readers won't go that far and those who will will wonder why this can't be done automatically. Brains don't like to pick what they deem superfluous.

So now not only you have to go through the docs (I can't just say to my teammate "use the $derived rune") but most likely you have to do it twice!

Autocomplete will take care of the rest

The amount of people under-using or not using at all autocomplete is extremely high, don't count on autocomplete for anything.

The tremendous struggle to name this thing isn't there randomly.

[arxpoetica]

Apparently I'm in the minority, but I really like .lazy().

[svelte-kit-so-good]

• $derived.spelledOut (rune pun)
• $derived.byCalling (or just calling)
• $derived.fromFunction
• $derived.extended
• $derived.multiline
  @eddiemcconkie beat me to $derived.run

I can't help but hearing/seeing "gogoGadget.spelledOut, gogoGadget.byCalling, ... "

[iamim]

Other suggestions:

• $derived.compute
• $derived.project
• $derived.using

[aradalvand]

initially liked the proposal to use do, but it seems to be that it will result in .do(do {}).

It won't. The do { } feature will be a replacement for $derived.do, if implemented.

[mimbrown]

$derived.block is growing on me.

[iamim]

initially liked the proposal to use do, but it seems to be that it will result in .do(do {}).

It won't. The do { } feature will be a replacement for $derived.do, if implemented.

Perhaps I didn’t read the RFC close enough, just took a glance. I thought it would be a syntactic sugar for functions.

[iamim]

One more suggestion that is more in line with what Rich-Harris was asking:

• $derived.expressive, an expressive variety of derived that allows you to go beyond just $derive(a + b)

[mimbrown]

$derived.expressive, an expressive variety of derived that allows you to go beyond just $derive(a + b)

Probably confusing if $derived.expressive is the one that doesn't take an expression

[joshwashywash]

what if $derived.whatever was the normal $derived? you'd do $derived(() => {...}); and the expression version would be the thing that requires a rename. $derived.expression(x + y);

is there anything there?

for what it's worth, when i first saw the derived rune i thought it was a little odd that it takes an expression and not a function.

EDIT: i only thought it was odd because the derived store in svelte 4 takes a function.

[brunnerh]

It is an expression in the first place because it's short and convenient.
There would be just about zero point in having $derived.expression, compare:

const z = $derived.expression(x + y);
const z = $derived(() => x + y);

[gterras]

It is an expression in the first place because it's short and convenient. There would be just about zero point in having $derived.expression, compare:

Though the same could be said for the whole topic, compare:

const z = $derived.anything(() => x + y);
const z = $derived(() => x + y);

[PatrickG]

It is an expression in the first place because it's short and convenient. There would be just about zero point in having $derived.expression, compare:

Though the same could be said for the whole topic, compare:

const z = $derived.anything(() => x + y);
const z = $derived(() => x + y);

TBH, I don't understand why they introduced this rune at all. If you need this functionality, you can use a IIFE.

const z = $derived.anything(() => x + y);
const z = $derived((() => x + y)());

Or - if you want it a bit cleaner - use a normal function.

function whatever() {}
const z = $derived(whatever());

[paulovieira]

Make the runes API simple:

• remove the original $derived(expression) variation
• $derived() should only accept a function value, nothing else

In practice this means adding () => before the simple expression. Not great, but seems like a good trade-off to have a simple API.

Before:

let doubled = $derived(count * 2);

After:

let doubled = $derived(() => count * 2);

EDIT: Another advantage is that $effect, $effect.pre and $effect.root also seem to only accept function values (right?). So in retrospect it seems like $derived(expression) is the "odd rune".

---

This reminds me of inline events handler. In svelte it's normal to do this (for simple expressions):

<p on:click={() => { count++ }}>
<button on:click={() => count++}>

And no one complains that it could be simplified to this:

<p on:click={count++}>

[7nik]

What should or shouldn't accept $derived and how was discussed in #10240. This discussion is about the new name for .call().

[Rich-Harris]

@paulovieira we debated that option at length and concluded it was the wrong choice

[iamim]

In my opinion, the need to return a function from $derived is pretty rare so maybe it shouldn't be optimized for?

What if $derived() is overloaded to take both expression<T> and function<T> and behave like most would expect: both are evaluated to return T. The special case ($derived.whatever) should be for the rare case when you do want to return an unevaluated function. And so it would be natural to call it something like $derived.unevaluated.

const a: number = $derived(1 + 2)
const b: number = $derived(() => 1 + 2)

const c: (() => number) = $derived.unevaluated(() => 1 + 2)
const throwsOrMaybeTypeNever = $derived.unevaluated(1 + 2) // cannot not evaluate an expression

[7nik]

@iamim it also already was discussed: #10240 (comment)

[Rich-Harris]

Yeah, the same arguments against overloads apply with interest to 'overload but also another thing'. That would be needlessly chaotic.

We're not going to find a good descriptive noun-ish word for this (and $derived.fn continues to be unappealing - aside from being an ugly abbreviation, nouns in function names should describe the output, never the input), so we instead have to find the right filler word.

After conversing with other maintainers, the most logical option is $derived.by. 'Derived by' is a bigram in common usage, and it accurately describes what's happening here...

foo = $derived.by(bar);

...foo is derived by bar. Bonus: it's short.

[gterras]

nouns in function names should describe the output, never the input

Although .by() is the less sad of all propositions it doesn't describe the output at all? It can vaguely make sense when you're fully focused on the subject but once this PR is merged and people actually start working on their code it won't mean anything.

Average user :

• by what ?
• why can't it be derived by an expression ?
• what does $derived(x) mean, surely not derived by x then ?

.via() seems more descriptive although still heavy source of confusion. Until your brain picks that .whatever() means pass a function which it will fight against heavily.

the same arguments against overloads apply with interest to 'overload but also another thing'. That would be needlessly chaotic.

I think this thread is needlessly chaotic. A simple and intuitive syntax that would work exactly as expected for the vast majority of users, would require a couple of seconds of thinking for the others and cause maybe 3 people to create an issue isn't. By the time it's an actual problem it won't be the only part of the syntax to break change anyway.

I understand you want the new direction to be as robust as possible but perfect is the enemy of good.

It feels like a replay of the first version of $state. At the time the only possible solution was this clunky mess, yet here we are with the best version of it. The lesson I've learned from this is that there is always a svelte way.

[enyo]

@gterras your examples of issues with a .by function are all discovered at the time of writing your code and some are solved by autocomplete and type hints. If you don't know that .by exists it doesn't matter since you simply use an iife or create a function instead.

But if $derived is overloaded and handles functions differently than other values, then you won't notice anything is off until execution. It will be difficult to find what is going on and how to fix it (and the fix is ugly).

---

My 2c on naming: I also think that .lazy() is a bad solution because as others have pointed out, that suggests to me that other uses of $derived are not lazy.

I think that .by() is great.

[gterras]

But if $derived is overloaded and handles functions differently than other values, then you won't notice anything is off until execution.

Yes that's pretty much the only raised case against this despite the on:eventname directive working exactly the same, which never seemed to be a problem (the docs doesn't even mention it) despite been asked on the discord probably hundred of times.

[MotionlessTrain]

But if $derived is overloaded and handles functions differently than other values, then you won't notice anything is off until execution.

Yes that's pretty much the only raised case against this despite the on:eventname directive working exactly the same, which never seemed to be a problem (the docs doesn't even mention it) despite been asked on the discord probably hundred of times.

What do you mean with on:eventname working the same (overloaded)?
If I don't supply a function to an on:click handler, the repl gives an error about expecting an object. If I supply an object without call signature, nothing happens
So the event handler just expects a function. Typescript will also correctly given an error if you supply something else

[gterras]

What do you mean with on:eventname working the same

I mean the same thing as then you won't notice anything is off until execution :

on:click={console.log('clicked')}

No TS error in this case, you have to run it to realize something's wrong. It probably happened to most people trying Svelte for the first time but was never considered a problem, and the solution is quite intuitive.

[MotionlessTrain]

What do you mean with on:eventname working the same

I mean the same thing as then you won't notice anything is off until execution :

on:click={console.log('clicked')}

No TS error in this case, you have to run it to realize something's wrong. It probably happened to most people trying Svelte for the first time but was never considered a problem, and the solution is quite intuitive.

I do get an error "Type void is not assignable to type 'MouseEventHandler | null | undefined" when I try to write that myself

Still, the event handler requiring a function is indeed quite intuitive (it is the same in vanilla JavaScript), but for $derived having an overloaded type like the following is not intuitive at all:

declare function $derived<T>(expr: T): T
declare function $derived<T>(func: () => T): T

Especially in cases where "T" would be a function like () => string, typescript will not be able to help you without specifying generics, and even then, you may be typing the generic wrong, yielding a different result than you thought you would have got
Having a signal being $derived.by the function makes much more sense, won't give typescript or JavaScript ambiguity, and you can say that nicely as well. And it won't mess with future plans for $derived

[enyo]

@gterras

I mean the same thing as then you won't notice anything is off until execution

That is never ideal of course, but there's a big difference IMO when something always works in a certain way, and you're using it the way you always do, but suddenly it behaves differently and there is no error / warning.

[mstachowiak]

By the way, I'll grant that there are convincing arguments here against lazy. The challenge I'll set for the crowd is this: come up with a word that will feel as natural in actual usage —

"we're going to create some state here, and then we're going to have some derived state, and then — because this is a more complex bit of logic — we're going to create a derived"

"ah, looks like we're going to need to turn that derived into a derived"

etc. I think @danielzsh's suggestion of 'complex' is probably closest, though it seems less like a description of the thing itself than a description of a frequently co-occurring property of the thing

$derived.wrap or $derived.wrapped

[olehmisar]

if fn is a concern, $derived.function is a good alternative

[Rich-Harris]

if fn is a concern, $derived.function is a good alternative

It took me a long time to understand my own negative reaction to $derived.fn beyond the ugliness of the abbreviation, but I eventually figured it out: function naming just doesn't work like that. What I mean is that when a noun is part of a function name, it always refers to the output, not the input. (I'm referring here to return-something functions rather than do-something functions, which in my ideal language would be separate constructs that used different keywords.) I'm sure people will come up with exceptions, but search your heart — you know this to be generally true!

A filler word like by, for any flaws it may have, sidesteps this issue. Based on the emoji reactions, most people are at least okay with this option (or at the very least, no-one will move to Canada over it) and so I've opened #10445 to put this mega-thread to bed at last.

Thank you everyone for the spirited conversation and for setting me straight on lazy — that would have been a bad choice and I'm glad we avoided that mistake.

[imcotton]

To me, $derived.later feels more neutral and to the point than lazy or by.