b0dg4n

Draggable with create-react-app

Recommended Posts

I am trying to get a div to rotate on drag using the Draggable api in a fresh create-react-appinstallation.

I cannot seem to get it to rotate. Here is my App.js file:

import React, { Component } from 'react';
import { Draggable } from 'gsap/all'

class App extends Component {
  componentDidMount() {
    Draggable.create('.draggable', {
      type: 'rotation',
      onPress: function() {
    	console.log('clicked');
      },
    });
  }

  render() {
    return (
      <div>
        <h2>React & GSAP Draggable</h2>
        <div className='draggable'>Drag and rotate me</div>
      </div>
    );
  }
}

export default App;

When I press the div, I can see the clicked log to console, but the div stays put when dragging.

TweenMax works fine:

TweenMax.to(target, 3, {
  color: 'red',
})

Share this post


Link to post
Share on other sites
53 minutes ago, OSUblake said:

Works fine here.

https://codesandbox.io/s/8z3z82rvo8

 

 

I can see that - however, doing this locally, it simply does not work.

 

All I did was:

 - `npx create-react-app gsap-test`

 - `npm i --save gsap`

 - copy over the exact same code from sandbox and replaced whatever was in the `index.js` and `index.css` files

 - `npm start`

 

The div does not rotate, but I can see the log.

 

I made a screen recording of this exact process here - can you please check it out and tell me what am I missing?

Share this post


Link to post
Share on other sites

Mhh... seems like a bug in the version of react

 

Blake's sandbox uses version 16.4.2 and yours is using perhaps 16.5.1?

 

This sandbox is using 16.5.1 and nothing, nada:

 

https://codesandbox.io/s/jrkbkxeqy

 

Same in stackblitz:

 

https://react-wxzf4q.stackblitz.io/

 

This might require digging up and creating an issue on React's repo, because the pointer events are triggering but the onDragStart event is not being triggered, so basically this is not sending the amount of pixels the pointer has moved.

 

Also it doesn't work with Draggable type: "x, y" neither.

 

What's odd is that this sample (which is an extreme simplification of how Draggable works) works fine:

 

https://codesandbox.io/s/xdjy28xov

 

We'll summon our master @GreenSock in order to find what's going on here, so stay tuned.

 

In the mean time my recommendation is to drop the React and React DOM dependencies to 16.4.2

Share this post


Link to post
Share on other sites

The only other thing I can think of is maybe your local build process is applying tree shaking and dumping CSSPlugin or something (a requirement). Maybe try referencing it (and TweenLite, just to be safe) directly in a variable to prevent tree shaking from dumping it, kinda like:

import { CSSPlugin, TweenLite, Draggable } from "gsap/all";

const dependencies = [CSSPlugin, TweenLite]; 

 

Does that help at all? 

Share this post


Link to post
Share on other sites
11 minutes ago, GreenSock said:

The only other thing I can think of is maybe your local build process is applying tree shaking and dumping CSSPlugin or something (a requirement). Maybe try referencing it (and TweenLite, just to be safe) directly in a variable to prevent tree shaking from dumping it, kinda like:


import { CSSPlugin, TweenLite, Draggable } from "gsap/all";

const dependencies = [CSSPlugin, TweenLite]; 

 

Does that help at all? 

OK, so added these 2 lines, but it doesn't really change anything

Share this post


Link to post
Share on other sites

@GreenSock,

 

Jack, indeed the issue is not bundling-related, here's a codepen using the React files directly without create react app and still the same:

 

 

In the mean time I can create an issue on React's repo so they can track this as well.

 

Best,

Rodrigo.

  • Like 3

Share this post


Link to post
Share on other sites

Aha! Figured out the issue - apparently the new version of React has an "onclick" handler on the root element, thus Draggable tries to politely stay out of the way by opting out unless you set dragClickables:true on your Draggable. Or you can set your own clickableTest function, but that's more advanced. So this isn't a bug in Draggable - it's how it's supposed to handle elements that are "clickable" (outside of Draggable), and it's easy to override if you need to. 

 

In short, just add dragClickables:true and you should be golden. I'm not sure why React is adding that onclick now to the root. Anybody know? 

  • Like 2

Share this post


Link to post
Share on other sites

Mhh... Honestly I don't know, I'll ask about that specific function. In the inspector comes as a no-op function in the root element.

 

I opened an issue in React's repo. I'll post any updates in that matter.

 

Happy Tweening!!!

 

---

 

EDIT

 

To keep everyone in the loop, this is the issue in React's repo:

 

https://github.com/facebook/react/issues/13654

 

We got a very fast answer from Dan Abramov. Dan explains that this was done to solve an issue on iOS and that is not going away, even further the trend may continue with other events, but that is not pertinent to this discussion.

 

Dan labeled the issue as discussion, which means they are listening to the community, so if anyone is interested in participating, please do.

  • Like 1

Share this post


Link to post
Share on other sites

Perhaps the best solution would be to make Draggable’s dragClickables true BY DEFAULT. The down side, of course, is that it could break legacy code. But looking forward, it seems like it’s probably what more people desire. Anyone disagree? 

Share this post


Link to post
Share on other sites

But Jack, that would mean that by default all the elements that, since the drag clickable bool was introduced, weren't elegible for being draggable will be now by default, right?, like buttons, inputs, textareas, etc?. Sure thing there isn't a lot of samples of buttons and inputs being used as Draggable targets, but still it changes the way things were done up to now.


My two cents is that adding that workaround for React users, is not a big deal, you could add an indication in the Draggable docs. Although I don't know the ratio between users creating Draggable instances out of buttons vs Draggable usage in React. Personally I've used it just once in quite a few React projects, but that's me.

 

If you think this is the best way to go for GSAP, I agree with it.

 

Happy Tweening!!

Share this post


Link to post
Share on other sites
5 minutes ago, Rodrigo said:

that would mean that by default all the elements that, since the drag clickable bool was introduced, weren't elegible for being draggable will be now by default, right?, like buttons, inputs, textareas, etc?

 

Yes, exactly. I'm always VERY cautious about making changes that'd affect legacy code but in this case I wonder if it's best to just bite the bullet and make the change now because:

  1. If someone specifically applied a Draggable to an element that's "clickable", they probably expect it to be draggable anyway without having to set dragClickables:true. In other words, this is probably the most intuitive behavior anyway, thus changing the current default behavior is favorable in most cases. 
  2. React is relatively popular and I'm concerned that too many people will run into this unintuitive behavior and blame Draggable as being glitchy. 
  3. If this change does affect legacy code, it's relatively easy to fix by setting dragClickables:false. 

Then again, I may be missing an angle here that should be considered. Thoughts? 

 

  • Like 3

Share this post


Link to post
Share on other sites

I upgraded to latest react build and after adding `dragClickables: true` it all works beautifully.

If adding this in by default might affect other codebases, then maybe just mention about this for React users - I would be fine either way.

 

BTW, I've been using GSAP for the past couple of days only and I must say - this has been the most reactive support I've ever encountered! Good job!

  • Like 2

Share this post


Link to post
Share on other sites
3 hours ago, b0dg4n said:

BTW, I've been using GSAP for the past couple of days only and I must say - this has been the most reactive support I've ever encountered! Good job!


We love hearing that! It's one of the things we're most proud of around here. 

 

Happy tweening (er...dragging)!

  • Like 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.