Conversation
🦋 Changeset detectedLatest commit: e686e94 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
|
|
||
| ## `$effect.pending` | ||
|
|
||
| When using [`await`](await-expressions) in components, the `$effect.pending()` rune tells you how many promises are pending in the current [boundary](svelte-boundary), not including child boundaries ([demo](/playground/untitled#H4sIAAAAAAAAE3WRMU_DMBCF_8rJdHDUqilILGkaiY2RgY0yOPYZWbiOFV8IleX_jpMUEAIWS_7u-d27c2ROnJBV7B6t7WDsequAozKEqmAbpo3FwKqnyOjsJ90EMr-8uvN-G97Q0sRaEfAvLjtH6CjbsDrI3nhqju5IFgkEHGAVSBDy62L_SdtvejPTzEU4Owl6cJJM50AoxcUG2gLiVM31URgChyM89N3JBORcF3BoICA9mhN2A3G9gdvdrij2UJYgejLaSCMsKLTivNj0SEOf7WEN7ZwnHV1dfqd2dTsQ5QCdk9bI10PkcxexXqcmH3W51Jt_le2kbH8os9Y3UaTcNLYpDx-Xab6GTHXpZ128MhpWqDVK2np0yrgXXqQpaLa4APDLBkIF8bd2sYql0Sn_DeE7sYr6AdNzvgljR-MUq7SwAdMHeUtgHR4CAAA=)): |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
You could imagine someone doing something cute like
export const messages = [
"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 /",
];
const loading_message = $derived(messages[$effect.pending() % messages.length]);There was a problem hiding this comment.
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.
There was a problem hiding this comment.
yeah, that was my thought process too — figured this would get the point across most concisely
There was a problem hiding this comment.
thought about something like this and discovered that a) it doesn't decrement when it should and b) there's some weird NaN action happening 🤔
investigating
Co-authored-by: Conduitry <git@chor.date>
|
|
||
| — instead, the text will update to `2 + 2 = 4` when `add(a, b)` resolves. | ||
|
|
||
| Updates can overlap — a fast update will be reflected in the UI while an earlier slow update is still ongoing. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
(Also, some more explicit information about what happens to the slow update would be nice. I'm imagining it's just getting discarded?)
There was a problem hiding this comment.
what about just linking to something like this?
There was a problem hiding this comment.
@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"?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Yeah, I do like the idea of not getting too bogged down in details because a) they might change before the experimental 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
There was a problem hiding this comment.
(and if people want the answer to questions like 'does it clobber the result of update 2 ...' they can just try it and see)
There was a problem hiding this comment.
will merge in the meantime, we can iterate as needed
|
|
||
| — instead, the text will update to `2 + 2 = 4` when `add(a, b)` resolves. | ||
|
|
||
| Updates can overlap — a fast update will be reflected in the UI while an earlier slow update is still ongoing. |
There was a problem hiding this comment.
@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"?
As well as docs this adds
$effect.pending()to the$effectnamespace so that you can use it without squigglies. A more organised person would have done this as part of the original PR, but, alas,Before submitting the PR, please make sure you do the following
feat:,fix:,chore:, ordocs:.packages/svelte/src, add a changeset (npx changeset).Tests and linting
pnpm testand lint the project withpnpm lint