React-beautiful-dnd: Move from react-motion to react-spring?

[alexreardon]

It would be worth taking a look at react-spring to see if we can get any performance wins while maintaining our feeling of physicality

[TrySound]

Also react-motion is unmaintained and react-spring already has esm bundle, however it's minified which can introduce debugging problems.

[souporserious]

I'd love to hear your thoughts on Popmotion. They have a spring implementation that can be imported directly which I think could reduce the bundle from where it is now. I'd be willing to start a PR if you are interested.

[TrySound]

Popmotion doesn't have esm bundle and esm path imports. I could work on it if they are opened for changes.

[souporserious]

I think Matt would be open to that. cc: @InventingWithMonster

[alexreardon]

Worth investigating for sure!!!
On Sat, 14 Apr 2018 at 3:10 am, Travis Arnold [e-mail]
wrote:

I think Matt would be open to that! cc: @InventingWithMonster
https://github.com/InventingWithMonster

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/atlassian/react-beautiful-dnd/issues/437#issuecomment-381201399,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACFN7ZLZkDyqzVvJsnI8MZRz-xCdDwExks5toNv-gaJpZM4TRMxq
.

[alexreardon]

Before we go down the esm path I think it worth seeing how using the
libraries feel as a replacement for react-motion for the dragging item
On Sat, 14 Apr 2018 at 6:51 am, Alex Reardon [e-mail] wrote:

Worth investigating for sure!!!
On Sat, 14 Apr 2018 at 3:10 am, Travis Arnold [e-mail]
wrote:

I think Matt would be open to that! cc: @InventingWithMonster
https://github.com/InventingWithMonster

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/atlassian/react-beautiful-dnd/issues/437#issuecomment-381201399,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACFN7ZLZkDyqzVvJsnI8MZRz-xCdDwExks5toNv-gaJpZM4TRMxq
.

[alexreardon]

Criteria:

• We want to maintain the same physics characteristics as the current react-motion usage for the dragging item. It feels amazing when dropping
• Ideally we want to use something as light as possible: light on the CPU and smaller KB

[TrySound]

KB is not absolute criteria. Find something and I will investigate how small it can be.

[mattgperry]

Is there good reading on what ESM bundles are, how they're made and why I should implement them? I'm definitely open to anything that makes it easier for people to use Popmotion, it's just at the moment every animation is importable individually and I assumed that was enough for people to consume the library in a lightweight manner.

You might find some joy with Pose which handles all the FLIP stuff too and works with the DOM directly. This would be easier to bundle but if you want to tweak the spring (and you probably do) you need to import it from Popmotion hence why I think bundling may be problematic.

[TrySound]

@InventingWithMonster If everything in your code is a function or a class without static properties then everything is treeshakable. On the other side transpiled to esm files (with modules: false babel option) can also significantly decrease the size of the final bundle because this code won't be wrapped with commonjs runtime.

[mattgperry]

@TrySound Thanks for the insight! It looks easy enough to add transpilation out into into an es (or a standardised name?) directory with TypeScript module="none". I'll have time over the weekend.

Is there an easy way in package.json to flag the existence of this directory or is it something users have to manually point to?

[TrySound]

@InventingWithMonster

https://github.com/atlassian/react-beautiful-dnd/blob/master/package.json#L20-L21

[drcmda]

Author of react-spring here,

i've published a version where esm/cjs go without minification.

As for the crtiteria

We want to maintain the same physics characteristics as the current react-motion usage for the dragging item. It feels amazing when dropping
Ideally we want to use something as light as possible: light on the CPU and smaller KB

It's using the same math, the spring is the same (stiffness -> tension, damping -> friction), and the api is more are less the same as well, though a bit easier in some parts. Converting would be a matter of minutes, for instance:

https://codesandbox.io/embed/l9zqz0m18z

https://codesandbox.io/embed/2pk8l7n7kn

https://codesandbox.io/embed/jzn14k0ppy

Since you'd probably just be taking the spring alone, the size in the end will be more or less comparable to react-motion.

The gain in performance has to do with animating in a raf-loop instead of letting react re-make the component tree frame by frame. Depending on how heavy the animated item is it can mean not so much or make a large difference.

[alexreardon]

Thanks for reaching out @drcmda! I am keen to see if we can get onto react-spring and whether it is a good move. Given that the shift is fairly light I have listed this as a 'good first issue' for somebody to have a crack at. We exclusively use react-motion in moveable.jsx. We hide it behind our own api so any swap would be fairly simple (famous last words)

I would take this myself but i am busy trying to get the website for this project up 😊

[drcmda]

@alexreardon I took a look already and it's all pretty straight forward, except that there seems to be a react-motion specific workaround in there. I don't understand this part:

// bug with react-motion: https://github.com/chenglou/react-motion/issues/437
// even if both defaultStyle and style are {x: 0, y: 0 } if there was
// a previous animation it uses the last value rather than the final value
const isNotMoving: boolean = isAtOrigin(final);

As well as this one:

{(current: { [string]: number }): any =>
      this.props.children(
        getStyle(isNotMoving, current.x, current.y)
)}

My questions would be:

1. How does he get from x/y to "current", and why does it call children as a function in there instead of simply channeling through children so that react-motion calls it? If i understand the motive behind that maybe i could attempt it.

2. do children receive isNotMoving and do something with it?

3. Why are transforms done in moveable.jsx and not applied the child itself?

   const style: Style = {
   transform: translate(${point.x}px, ${point.y}px),
   };

[alexreardon]

I would not worry too much about the react-motion work around. It is a really strange bug where it was doing the wrong thing

• getStyle simply returns the transform string
• the isNotMoving is not needed by children - it was just a workaround which is provided to getStyle. Because current.x and current.y would be incorrect, using isNotMoving allowed us to ignore those incorrect values
• we pass the transform string along as we merge it with other style properties. We do not apply it to do element directly. We let consumers do that by applying the DraggableProvided > DraggableProps > style prop to the element. This also lets them monkey patch it if they need to

[drcmda]

Is the element that consumes it fully under the users control, like is it just any random div/span, etc? Or do you get to decide the elements type? I am asking because in order to really make a difference moveable would switch to native:

<Spring native from={{ x: 0, y: 0 }} to={{ x: 10, y: 20 }}>
    {({ x, y }) => (
        <animated.div
            style={{
                transform: interpolate([x, y], (x, y) => `translate(${x}px, ${y}px)`),
            }}>
        </animated.div>
    )}
</Spring>

The receiving component would thereby only render once, even if its animating. The x/y values would be opaque objects that only animated.[element-type] can understand (in this case animated.div).

It can render like react-motion as well of course, but the performance would stay even.

[alexreardon]

Consumers control the element that the styles are applied to. This library creates no dom nodes. So we wont be able to use animated.div

[alexreardon]

Can we not pursue this strategy?

(Pasted from docs)

<Spring from={{ opacity: 0 }} to={{ opacity: 1 }}>
    {styles => <div style={styles}>i will fade in</div>}
</Spring>

[drcmda]

Sure, that's no problem. I am only looking for ways to boost it a little. The example you posted is how all react animation libs do it. React renders the inner component 60 x per second. It's totally fine, depending on how deeply nested the inner component is. If i find time, i'll give this a shot and then perhaps we can think about how to enable faster rendering afterwards.

[alexreardon]

We could opt out of react for the inline transition and simply apply it directly to the element without needing to tell react. However, for now that does not seem to be our performance bottleneck. I super appreciate you wanting to follow this up.

For now we have the nice api of providing everything in the style prop. However, we could revisit this for improved perf reasons

[alexreardon]

Something to keep in mind: when the user is dragging we treat the Spring as a pass through and do not want to perform any physics calculations. We simply move the component to the new location. The only thing we use Spring for is the drop animation to give it more weight.

Movements of items out of the way of dragging items is done just with css transitions

[drcmda]

React-motion does it by omitting the spring(...) wrap, in react-spring it's a flag

<Spring immediate ... />

Or if it has to be for specific values, while something else animates:

<Spring immediate={['x', 'y']} ... />

I'm fairly positive that 100% of the api is easily transferable.

Example: https://codesandbox.io/embed/l9zqz0m18z

The lifting up/down animation runs, but positioning is channel-through.

[alexreardon]

Correct! We just need to be able to swap between using immediate and not using it on the same spring

[alexreardon]

which is looks like you are doing in your example:

immediate={active && ['y']}

[drcmda]

One last question, are website/examples alright? i do cd website / y develop but no example seems to actually run. I get:

index.js:2177 Warning: React.createElement: type is invalid -- expected a string (for built-in components) or a class/function (for composite components) but got: undefined. You likely forgot to export your component from the file it's defined in. Check your code at draggable.jsx:340.
in DragHandle (at draggable.jsx:381)

[alexreardon]

Oh! The /website is super broken on master. We are still using the storybook for dev and production

# In the root
yarn storybook

[alexreardon]

I have fixed the website up a bit on my local branch but it is not on master yet. It is a work in progress on master

[drcmda]

@alexreardon Alright, PR is in, would be glad if you can test all use-cases. I removed lots of code in there, all r-m specific work around and some of the layers that i'm not sure if they're really needed.

[souporserious]

@alexreardon I was working on a PR using popmotion to see how the size would compare with react-spring and then I realized there's also wobble, maybe that would be the best fit for this library? Seems like the lightest weight solution is best since it is only responsible for a small portion of this library.

[souporserious]

I did a quick PR to see if it's worth it to use wobble or not.

[maxbureac]

@alexreardon I have the same problem as @drcmda with the latest version of the library.

"react": "^16.4.0",
"react-beautiful-dnd": "^7.1.3"

I just wanted to try so just picked this example and it is funny that in sandbox it works but not on my local machine.

I am adding the comment here because I found the same issue as mine.