Allows nodes to use the body as origin instead of the parent. This is useful, when the parent's position is changing. When used, resolves #170

This issue was introduced by a398097ebcc2cbb4df5582a8a3f42f51d21745a0

please :eyes:

Hi, I'm working with TypeScript and installed react-draggable. As it is said in the doc touse the <Draggable /> component I need to import as default:

The default export is <Draggable>. At the .DraggableCore property is <DraggableCore>. Here's how to use it:

// ES6
import Draggable from 'react-draggable'; // The default

But when I try to import it:

// myComponent.tsx
import Draggable from 'react-draggable';

I get the Module "react-draggable" has no default export. error. Doing:

import * as Draggable from 'react-draggable';

brings me the <Draggable /> component but in TypeScript syntaxis * as also brings all definitions and typings so I can't use it as a component (error: JSX element type 'Draggable' does not have any construct or call signatures.)

I only can use it is:

const Draggable: any = require('react-draggable');

but it's weird since this package already gives typings.

I'm using typescript 2.3.2 and awesome-typescript-loader 3.1.3. Anyone has encountered this issue? PD: Big thanks to give typings. This is an awesome package!

I have a use-case in which the draggable element can either be dragged around or clicked to begin editing. Is there a way to detect a single click versus a drag motion?

Nifty library! Thanks for creating it. :)

I noticed that className can be used to specify a custom class (eg for CSS modules) but there is no way to specify a custom is-dragging or is-dragged class. This PR adds that functionality (and tests).

Note that npm test is broken in master (and won't pass until PR #176 is merged).

Note that npm run lint also fails in master:

# FIXME this is usually global
flow check
.flowconfig:16 Unsupported option: "esproposal.class_instance_fields"
make: *** [lint] Error 4

At the moment I don't have a jsfiddle setup, but it appears that the dragging of SVG elements has no effect in any version of Internet Explorer. I can't think of any obvious reason why this would be because translate works just fine in IE on SVG. It seems to have something to do with the onDrag event listeners.

Hi, is IE11 supported with react-draggable? I couldn't get the demo page to work when using IE11 on a windows 7 vm so I'm not sure if the demo page is just pointing to old code or if this is a general issue with react-draggable.

When dragging I saw "SCRIPT5007: Unable to get property '0' of undefined or null reference File: react-draggable.min.js, Line: 1, Column: 1805"

This PR uses the DOM element’s ownerDocument rather than the global document or window to make react-draggable work across iframes. In our use case, we have an app being rendered into an iframe with React Frame Component, so the DOM elements are in a separate document from the document where the React elements are being executed.

I chose to replace the instanceOf Node check with a simple duck-typing check (https://github.com/mzabriskie/react-draggable/compare/master...Brandcast:iframe?expand=1#diff-9f4a38358e68eff5cf48eda850801a7aL190), which could be adapted to whatever type of conditional. It would even do the same check, but to work across iframes, it would need to first find the window object relative to e.target. Let me know if you want me to change or update that.

I'm using this on a mobile app, translate is very slow as it don't make use of the GPU, you can just make a 3d option available, I'm forking it just for this. This is a great plugin, it will fit my needs with this option.

I'm using react-draggable in my application to scroll an item in a viewport (i.e. dragging the background scrolls the view), and also for custom scrollbars around the viewport. Needless to say, I needed to use the moveOnStartChange attribute to keep these two manners of scrolling the same viewport consistent. I found, however, that there was some really buggy behavior in react-draggable, and it stemmed from the fact that componentWillReceiveProps triggers too often.

If you declare your component like this:

<Draggable start={{x: 0, y: 0}}>...</Draggable>

then every time the render() method is called, the componentWillReceiveProps method is called because, technically, a new object is being passed as the 'start' property.

The solution I have come up with is to change lines 471-473 in the componentWillReceiveProps method to:

if (newProps.moveOnStartChange && newProps.start &&
    (newProps.start.x !== this.props.start.x || newProps.start.y !== this.props.start.y))
{
    this.setState(this.getInitialState(newProps));
}

Thoughts?

Hey @STRML, here is my first pass at allowing initial position to be a string percent. It is essentially using the same code as before but does not modify the defaultPosition prop in any way and instead adds a new initialPosition prop.

I think this is working as is. We should probably add a few more tests to be sure that the drag callbacks that broke last time aren't breaking this time.

connects https://github.com/mzabriskie/react-draggable/issues/391

Draggable component seems to trigger an error after it is unmounted as the result of an onStop handler.

Specifically:

Warning: Can't perform a React state update on an unmounted component. This is a no-op, but it indicates a memory leak in your application. To fix, cancel all subscriptions and asynchronous tasks in the componentWillUnmount method.
  in Draggable (created by App)

It seems similar to #130.

I've made a simple repro of the issue with the latest version that you can find here.

It only seems to happen once, and any following unmounts, even on other instances of the component, do not trigger the error.

I noticed that the x and y coordinates that React-Draggable gives out is completely different from what getBoundingClientRect gives out. Here's a snippet of my code:

const [position, setPosition] = useState({ x: 0, y: 0 });
const trackPos = (data) => {
     setPosition({ x: data.x, y: data.y });
};

<Draggable onDrag={(e, data) => trackPos(data)}>
     <div ref = {ref}>...</div>
</Draggable>

When I print out the values of both ref.getBoundingClientRect() from the component and that of data are completely different. Is there any way to convert these values?

Problem

Getting this warning when using the deprecated function findDOMNode in StrictMode. findDOMNode is deprecated in StrictMode. findDOMNode was passed an instance of DraggableCore which is inside StrictMode. Instead, add a ref directly to the element you want to reference. Learn more about using refs safely here

Suggested Solution

To resolve this warning, I suggest replacing findDOMNode with an innerRef. If the user passes a ref as a prop, we'll use it as the draggable ref. Otherwise, we'll create an internal ref and use it as the draggable ref. We can then easily access the draggable DOM element : ref.current

Here is the implementation :

class DraggableCore extends React.Component<DraggableCoreProps, DraggableCoreState> {
	lastHtml: string = this.props.html;
	element: any =
		typeof this.props.innerRef === 'function'
			? { current: null }
			: React.createRef<HTMLElement>();

	// Now w'll use `getElement` instead of `findDOMNode`
	getElement = () =>
		(this.props.innerRef && typeof this.props.innerRef !== 'function'
			? this.props.innerRef
			: this.element
		).current;

	// Now if we need draggable DOM element :
	// const element = this.getElement();

	render() {
		const { innerRef, children, ...props } = this.props;

		return React.cloneElement(React.Children.only(children), {
			ref: typeof innerRef === 'function'
				? (current: HTMLElement) => {
					innerRef(current);
					this.element.current = current;
				}
				: innerRef || this.element,
			...props,
		});
	}
}

And here is a simple usage :

const myExternalRef = useRef(null)

// `innerRef` is optional, if it's not passed we'll create an internal ref
<DraggableCore innerRef={myExternalRef}>
	<span>Test</span>
</DraggableCore>

Declaring a global module with declare module 'react-draggable' is unnecessary, and can cause type pollution if multiple versions of react-draggable end up in a package.

This is exemplified in this repro: https://github.com/pgoldberg/react-draggable-typings-bug

The global module declaration is not necessary. Typescript will appropriately associate the typings with the react-draggable module, since the typings are declared in the package.json here: https://github.com/react-grid-layout/react-draggable/blob/44a8c6ed103ec6c0a4dda5faf7f8ebca16f9b325/package.json#L24

Is there any way currently, to drag outside the browser window...?

This feature is particularly needed for desktop / Tauri apps where users are used to being able to drag things freely outside window bounds.

Bumps engine.io from 6.2.0 to 6.2.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.