🦋 Changeset detected

Latest commit:605a1f7

The changes in this PR will be included in the next version bump.

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

preview:https://svelte-dev-git-preview-svelte-14594-svelte.vercel.app/

this is an automated message

Playground

pnpm add https://pkg.pr.new/svelte@14594

While it's nice, this does feel more of a thing for a utility or animation library. I wouldn't call it a lifecycle function at least and expose it throughsvelte/reactivity instead.

Adjacent to#12441

Adjacent to#12441

I'm not sure it is at all. You definitely don't want to be updating the UI withDate.now() every frame, that's going to put a lot of pressure on the runtime for no real benefit. I'd imagine you'd only want to update the time in relation to your UI requirements, such as every second or minute. This is very much a user-space problem rather than a problem that Svelte should even attempt to solve.

Preview:https://svelte-dev-git-preview-svelte-14594-svelte.vercel.app/

Renamed toonAnimationFrame. I toyed with putting it insvelte/reactivity orsvelte/motion but neither felt right — I think you can make the case that itis a lifecycle function, and it definitely feels more natural to me to have it alongsideonMount than elsewhere

FWIW I still think this is not worth adding as it's so easy to replicate in user land - so if this is about cleaning the PR queue I'd rather close it.

It'seasy but annoying — you have to understand whether it's 'safe' to run the logic inside arequestAnimationFrame callback the first time or if it'll result in flicker unless you call it directly inside the effect, in which case you might need to faff about withuntrack unless you're usingonMount (you don't need to, because itis safe, but that means you have to callrequestAnimationFrame twice — once inside the callback, once to kick it off). And of course it's a lot more verbose — this...

$effect(()=>{letframe=requestAnimationFrame(functionnext(){frame=requestAnimationFrame(next);do_stuff();});return()=>{cancelAnimationFrame(frame);};});

...versus this:

import{onAnimationFrame}from'svelte';onAnimationFrame(()=>{do_stuff();});

The intent-to-noise ratio is much higher in the second case. It's something I've wanted often enough that I do think its presence is justified, it's not just about cleaning the PR queue.

I'm not saying it doesn't have any value, but not that it deserves to be in the same place as things like "real" life cycle hooks or other important stuff under thesvelte import space. It feels like something that can be put into a 3rd party lib likeruned

I'm not saying it doesn't have any value, but not that it deserves to be in the same place as things like "real" life cycle hooks or other important stuff under thesvelte import space. It feels like something that can be put into a 3rd party lib likeruned

We have something similar in runed :)https://www.runed.dev/docs/utilities/animation-frames