Ensure AnimatePresence executes exiting animations in sequence

[regexyl]

This PR fixes #2462.

It also fixes 3 tests (i.e. "Only renders one child at a time if mode === 'wait'", "Fast animations with wait render the child content correctly", "Fast animations with wait render the child content correctly (strict mode disabled)") where not enough leeway is given for exiting elements to completely exit from the DOM.

Before

framer-motion-bug.mov

Now

Screen.Recording.2024-01-06.at.00.54.36.mov

[regexyl]

Removed presentChildren for clarity - filteredChildren, exitingChildren and allChildren are enough to maintain the status quo

[regexyl]

@mattgperry I'm not sure why the test under framer-motion-3d is failing - do you have a clue?
edit: it's passed, maybe flaky? 👀

[JaeSeoKim]

In the past, I've written PR to fix errors in this regard. I'm linking because I think it would be good to refer to!

• Fix AnimatePresence won't unmount fastly changing content #1569

[regexyl]

Thanks @JaeSeoKim! Just had a quick look-through, and it seems like there are two main problems the PR was trying to solve - (1) bringing useRef to exitingChildren (also later separately solved through #2113), and (2) the algorithm that decides how exiting, current and entering elements mesh together.

This PR tries to solve a different problem where a quick waterfall of existing elements do not exit in sequence (i.e. elements exit in quick succession, but in different times), instead of how the exiting/current/entering elements should be rendered - though it seems like a pretty interesting problem to solve 🦄

[mattgperry]

Thanks for the excellent PR and apologises it's taken a while to get to. I'll merge and publish today.

[mattgperry]

Ah apologises. I had to revert this PR because of these lines:

    const filteredChildren = useRef(onlyElements(children))
    filteredChildren.current = onlyElements(children)

The intention here is to update filteredChildren every render. But filteredChildren is essentially a mutable here and React renders are theoretically pure.

Therefore, it's only safe to assign a ref during render on the initial render:

    const filteredChildren = useRef(null)
    if (!filteredChildren.current)
      filteredChildren.current = onlyElements(children)

(Which obviously isn't the intent of this line)

Otherwise what we have is a situation where React could prospectively render something with a children list that isn't ever committed, and an Effect or onExit being run on a filteredChildren list that isn't the one we think it is.

[mattgperry]

Another issue - or maybe it's been fixed in the meantime? - is I ported the tests in this PR to main 8ee3628 and they pass already so I don't know if they capture the behaviour in the linked issue