Replicating v8 useTransition behaviour without 'unique' prop

[lawrence-witt]

I've been scouring the docs and issues but can't seem to find an explanation of why the unique prop has been removed from useTransition in the v9 release. It's causing me some confusion at the moment as I've upgraded my project to use v9 in order to fix some bugs, but some of the transitions relied on unique being false and I can't see an obvious way to replicate the old behaviour.

Consider this demo which utilises useTransition to swap out routes: https://codesandbox.io/s/v9-route-transitions-r9w0h?file=/src/App.js.

 const location = useLocation(); const transition = useTransition(location, { key: item => item.pathname, from: { transform: "translateX(-100%)" }, enter: { transform: "translateX(0%)" }, leave: { transform: "translateX(100%)" } }); return ( <div className="App"> <div className="container"> {transition((style, item) => { return ( <a.div className="wrapper" style={style}> <Switch location={item}> <Route exact path="/" component={A} /> <Route exact path="/a" component={A} /> <Route exact path="/b" component={B} /> </Switch> </a.div> ); })} </div> <Link to="/a"> <button>Go to A</button> </Link> <Link to="/b"> <button>Go to B</button> </Link> </div> ); 

The behaviour I want:

1. Transition from A to B makes A leave right and B enter from left.
2. Routing back to A while the transition is in motion will make a new A component transition in at the from position. (i.e unique: false)
3. Routing to A while A is already mounted will not transition in a new A component.

This is the default behaviour in v8, with keys specified by location.pathname.

The current behaviour:

Without key:

1. true
2. true
3. false - a new component is mounted everytime A is linked to.

With location.pathname key:

1. true
2. false - the exiting component will reverse its animation to return to the enter position.
3. true

You can test this in the demo by commenting/uncommenting the key: item => item.pathname line.

---

So what is the best way to replicate the old behaviour? I'm still pretty new to react spring - is there something obvious I'm missing here which makes unique unnecessary? I've considered tracking the location updates with usePrevious and useEffect to test equality manually in place of a key, but I'd rather avoid the overhead if possible and it was so simple before with the unique prop.

[aleclarson]

Routing back to A while the transition is in motion will make a new A component transition

You can use location.key to prevent that.

Routing to A while A is already mounted will not transition in a new A component

This is more of a react-router issue: remix-run/react-router#5362

That thread has a workaround for blocking navigation to the current location, which I improved upon and added to your example. It works perfectly :)

https://codesandbox.io/s/react-spring-1027-tzx05

PS: You can help support my work on react-spring! Become my patron.

[lawrence-witt]

Ok, that's great, and does basically solve my use case, although it does still leave me wondering why unique: false is gone since it took care of all this automatically.

In the example you provided it still works if you provide no key at all, since from what I gather the location object generates a new random key each time. It seems like this basically does what I said at the end of my post about tracking value with usePrevious and useEffect, although your implementation is react-router specific and a lot more elegant than anything I'd come up with :')

Here's the same code without routing just to try and explain myself properly: https://codesandbox.io/s/v9-regular-transition-ioh2o?file=/src/App.js

So applying the same logic, is the only way to replicate the v8 behaviour to make sure the id or key more generally is random each time, and also that the state will not be updated if the current letter is already stored? Again, I'm only asking because it seems like a lot of extra steps for something that was previously baked in.

[aleclarson]

I think unique: true is the more common use case, so it makes sense for that to be the default behavior. Stripping out unique: false support also simplified the implementation quite a bit.

The workaround isn't so bad anyway: (sandbox)

const [letter, set] = useState({ id: 0, val: "A" }); const setLetter = val => set(prev => (prev.val === val ? prev : { id: nextId++, val })); const v9Transition = useTransition(letter, { key: letter.id, ...props, }); // Later on: setLetter("B");

There may be an argument for having keys: null mean “Generate keys internally“.

[lawrence-witt]

Thanks for clarifying, and yes, I did end up doing something like this and it wasn't that bad in the end - the old prop was just nicer to read :)

[aleclarson]

Check out what I whipped up in ~10 minutes: #1029 😎