Releases: react-dnd/react-dnd
Add TouchBackend UMD Build
Libraries
react-dnd-umd-builds
Minor
Add ReactDnDTouchBackend umd build.
Toolchain Changes
Libraries
All Libraries Affected
Minor
The react-dnd toolchain has been changed up from using TypeScript to using Babel. This allows us to use a ‘browserlist’ query instead of a coarse tsc target when defining what JS features to ship with. The public API has not changed at all, but there could be underlying changes if your code is implementation dependent.
v9.0.2 - TouchBackend Fixes
Libraries
- react-dnd-touch-backend
- react-dnd-touch-backend-cjs
Patch Changes
- Correct an issue where the TouchBackend was not using the OptionsReader class in the constructor, which caused default options to not be used.
v9.0.1
v9.0.0
Major
- Remove
DragDropContext
decorator. (#1439) - Update BackendFactory function in
dnd-core
to accept a configuration object. (#1439) - Construct the Backend outside of the
DragDropManagerImpl
class (#1439)
Minor
- Add
react-dnd-touch-backend
library - Update
DndProvider
to accept an 'options' prop with backend configuration - Correct state staleness issues when using hooks-based API (#1429, #1437)
Patch
- Prevent starting a react-dnd drag operation if a dragstart event has it's default-prevented (#1426)
DndProvider Bugfixes
Bugfixes
- The DndProvider component had been throwing errors if it was rendered multiple times because of the implicit singleton invariant of the HTML5Backend. To correct this, if a backend factory is passed to the DndProvider using
<DndProvider backend={HTML5Backend}/>
, it will only create a singleton instance of theDndContext
per global context. This means that to create a second backend for an iframe, one needs to use:
<DndProvider backend={HTML5Backend} context={iframeWindow} />
.
Revert 'module' field in package.json files
The package.json
files for the react-dnd libraries contained a "module" field which was used to identify where the ES Module roots began. These fields were added with the intent of supporting CommonJS module loading (the de-facto NodeJS module system) simultaneously with the ES Module loading system (the emerging standard for JavaScript modules).
Unfortunately this change resulted in a lot of build headaches for users then their module bundlers started defaulting to using the ES Module roots.
This release reverts that change and leaves the v7 branch of React-Dnd as primarily using CommonJS. ES Module builds are still available under the esm/
folders, but it is up to users to use them at their own discretion.
In v8, ES Modules are used as the default module system. CommonJS-based packages are still available however in react-dnd-cjs
, and react-dnd-html5-backend-cjs
CommonJS Fixes
Patch
The CommonJS libraries had runtime issues due to some @ts-ignore
statements on non-typed module imports. Those have been removed from the core libraries.
CommonJS Builds
In v8.0.0 we changed the default module format to ES-Modules. This should enable better tree-shaking performance, and aligns the library with modern web standards supported by greenfield browsers and Node v12. We think it's time to make them the default option.
That being said, we realize that users who expect CommonJS functionality will have some pain with this approach. If you use react-dnd and want CommonJS modules, look for the
dnd-core-cjs
,
react-dnd-cjs
,
react-dnd-html5-backend-cjs
,
react-dnd-test-backend-cjs
, and
react-dnd-test-utils-cjs
packages.
React-DnD V8
Major
- ES Modules. The target output of TypeScript has been changed to esnext with esnext modules. This speeds up and simplifies our build process, and targets the future with modern web standards. The UMD builds have been moved to a new 'react-dnd-umd-builds' package. CommonJS builds have been removed.
- Polyfills: Legacy polyfills have been removed. At this point, that's just String.endsWith
- DragDropContextProvider:
=>DragDragDropContextProvider
DndProvider
=>DragDropContext, DragDropContextConsumer, and DragDropContextProvider
DndContext
.