I'm trying unsuccessfully to think of a non-contrived example that doesn't just use 0 vs >0. I'm guessing that's exactly how we ended up with this contrived example here?

You could imagine someone doing something cute like

exportconstmessages=["reticulating splines...","generating witty dialog...","swapping time and space...","640K ought to be enough for anybody","checking the gravitational constant in your locale...","keep calm and npm install","counting backwards from Infinity","I'm sorry Dave, I can't do that.","adjusting flux capacitor...","constructing additional pylons...","rm -rf /",];constloading_message=$derived(messages[$effect.pending()%messages.length]);

Oh. Cute, okay. My comment/question was less of a 'why does this feature exist?' and more of a 'what can we show here in the docs that doesn't feel contrived?'. I don't know that we'd want the distraction of an example like the one you just gave, though. I'm not sure.

yeah, that was my thought process too — figured this would get the point across most concisely

thought about something likethis and discovered that a) it doesn't decrement when it should and b) there's some weird NaN action happening 🤔

investigating

I think this would be useful to have an example of. What do you think about one or the other of these two "adding with an artificial delay" examples using a randomized delay?

(Also, some more explicit information about what happens to the slow update would be nice. I'm imagining it's just getting discarded?)

what about just linking to something likethis?

@Rich-Harris I don't think that quite answers the question I immediately get from this, which is "If update 1 finishes after update 2, does it clobber the result of update 2 or get discarded"?

Oh, maybe, for part of it. Synchronous updates (or as close as we currently have to synchronous updates) doesn't feel quite the same in terms of being a 'fast' update as a fast async update would, I don't think.

I don't know how fancy we want to get here in these examples. There are a couple of things going on here. One is synchronous updates continuing to happen while waiting for async updates. One is two different independent async updates happening independently. And one is multiple async updates of the same data happening, possibly completing out of order. If you want to gloss over at least some of these in this initial pass at the documentation, that's probably a reasonable idea.

Yeah, I do like the idea of not getting too bogged down in details because a) they might change before theexperimental flag comes off, b) we don't yet really know which bits people will find confusing and c) most people don't care about this level of detail anyway

(and if people want the answer to questions like 'does it clobber the result of update 2 ...' they can just try it and see)

will merge in the meantime, we can iterate as needed

@Rich-Harris I don't think that quite answers the question I immediately get from this, which is "If update 1 finishes after update 2, does it clobber the result of update 2 or get discarded"?