-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
useTransition API rewrite #2540
Copy link
Copy link
Open
Labels
area: corerelates to core classes // parts of the libraryrelates to core classes // parts of the librarykind: requestNew feature or request that should be actionedNew feature or request that should be actionedrelease: major
Metadata
Metadata
Assignees
Labels
area: corerelates to core classes // parts of the libraryrelates to core classes // parts of the librarykind: requestNew feature or request that should be actionedNew feature or request that should be actionedrelease: major
Type
Fields
Give feedbackNo fields configured for issues without a type.
A clear and concise description of what the feature is
Rewrite
useTransition(packages/core/src/hooks/useTransition.tsx) around a declarative enter/leave model — presence made explicit, "obvious on first read" — without the render-prop bookkeeping it has today:Would also subsume #2136 (per-property configs should fall out of the new model rather than be bolted on).
Why should this feature be included?
useTransitionis the library's most-reported source of confusion — the same friction recurs across years:itemdown in the view section and don't know where it comes from."useTransitionAPI to trigger a #1281 (2021) — confusion over wherestatefits once the API takesitems.leavetransition can have an effect?" — exit timing isn't discoverable.Related issues
<Presence>component; the enter/exit primitive a cleaneruseTransitionunlocks.layoutId, tracked separately).Scope / non-goals
animated.*that create/own springs internally — that inverts the model (see the reasoning on [feat]: Create an animation abstraction for spring and gesture #1826).