Github
All Releases

11.0.0

The one with hooks 🎣 (almost 🙈)

This release is mostly internal changes and our public API remains relatively untouched

The original plan was to move to a totally hooks based api #871. However, we hit a snag: right now it is not possible for a hook to set up context. A Droppable component sets up context for a Draggable to consume. So for now we are sticking with our render prop API. Internally we have moved almost everything over to function components and hooks. (Our error boundary still needs to be a class because function components cannot currently be an error boundary)

Our internal refactor has also resulted in react-beautiful-dnd now being <StrictMode> compliant

Sharing the learnings 🎁

I have given a talk at React Sydney about my journey converting react-beautiful-dnd from class components over to function components and hooks.

🎬 Deep sea fishing with React hooks

Breaking changes 💥 #1194

1. React peer dependency ^16.3.1 → ^16.8.5

In case you wanted to know why we picked ^16.8.5 🕵️‍♀️

  • Internally we have moved most things to function components and hooks which need ^16.8.0 #871
  • We were still using old school React context. We could have moved to the new context api in our previous ^16.3.1 dependency, but consuming context through useContext in 16.8 has made it a lot easier to shift over.
  • Need to move to ^16.8.4 to use react-redux@7. We proposed to get this lowed to ^16.8.0 but the project was not keen. We could still claim our React peer dependency is ^16.8.0, but that could lead to issues with bundlers if using a version >= 16.8.0 and < 16.8.4. It would at least be a warning, and might even be worse.
  • Rather than moving to a peer dependency of ^16.8.4 (for react-redux@7) we went to ^16.8.5 as it contained fixes for shallow rendering which could impact some peoples react-beautiful-dnd tests

2. <Draggable /> → shouldRespectForceTouch

2.1 Name change

shouldRespectForceTouch => shouldRespectForcePress

- shouldRespectForceTouch
+ shouldRespectForcePress

Moving to shouldRespectForcePress is a clearer name given that force press actions can be fired from mouse inputs too.

We will be calling event.preventDefault() on the following events from a drag handle if shouldRespectForcePress is set to true (the new default)

  • webkitmouseforcechanged (mouse)
  • touchforcechange (touch)

For the next little while we log a development warning if you are using the old shouldRespectForceTouch prop

2.2 Flipping the default

See #1160. Opting for a better dragging experience out of the box

- shouldRespectForcePress: true,
+ shouldRespectForcePress: false,

New package: useMemoOne

One byproduct of our move to use hooks was the creation of a new package!

useMemoOne: useMemo and useCallback with a stable cache (semantic guarantee)

useMemo and useCallback cache the most recent result. However, this cache can be destroyed by React when it wants to:

You may rely on useMemo as a performance optimization, not as a semantic guarantee. In the future, React may choose to “forget” some previously memoized values and recalculate them on next render, e.g. to free memory for offscreen components. Write your code so that it still works without useMemo — and then add it to optimize performance. - React docs

useMemoOne and useCallbackOne are concurrent mode safe alternatives to useMemo and useCallback that do provide semantic guarantee. What this means is that you will always get the same reference for a memoized value so long as there is no input change.

Other

  • Moving to the new GitHub issue templates to streamline issue creation
  • Fixed broken external link #1235. Thanks @erik-beus!
  • Upgrading to flow 0.96 🤘
  • Fixed issue caused by missing SVGElement in some testing environment #1249. Thanks @hawkeng for raising this

Open discussions 🗣

We would love your input on our future direction!

  • Virtual list api #1225
  • Data flow (making good headway on this!) #498
  • Drop decisions #1239

Thanks ❤️