12.0 Release 🎁

[alexreardon]

Want to play with the beta? See #1317 (comment)

I am using this issue as a linking point for things going out in 12.0

Virutal list project

• Discussion: Virtual list api #1225
• Draggables inside of portals are broken with touch #1310
• Flush drop animation if there is a scroll event #1104

[alexreardon]

Also need to bump to flow 0.99+

[alexreardon]

[email protected] is out.

Some wins of using the alpha:

• portals now work on mobile
• considerably reduced memory usage (~50%)

Do not use if:

• using dynamic additions and removals (it is currently broken)
• using data-* attributes (they have changed)
• monkey patching event handlers on a drag handle (they are gone now)

I am really interested to find an example of dragging an item in an iframe. Right now I think our code will not work with it - so I am keen to get an example

[tjramage]

@alexreardon — Updated to this on our dev branch yesterday, all working great 👌

[tjramage]

@alexreardon — we've just seen the latest tweet showing off all your hard work — just incredible! So great to see.

However, I just wanted to clarify the exact conditions under which we'll be able to make use of virtualisation. You'll have to forgive me, as I'm only just getting up to speed with the concept of windowing, etc, but it appears that each individual list must have its own scrollable container in order for it to determine which children it can virtualise. Is that correct?

Our situation is actually quite different. We have (potentially) anywhere up to 1000 lists, each with a varying amount of items inside them. Each list's height is determined by its contents, and nothing is scrollable apart from the whole document window itself.

Having seen the demo in action, I've only just twigged now that this may not be able to solve our performance issues unless we set the lists to a fixed height and allow each one to be individually scrollable. My problem is that this wouldn't work for us, as our lists scale out both horizontally and vertically (think Trello, but with multiple slices of lists).

Another thing I'd like to ask is whether virtualisation could be applied to the lists themselves, rather than their contents? If this was possible, we could at least benefit from only rendering ~50 lists at a time...

Sorry for the mammoth! Keep up the great work ✌️

[dcporter44]

@alexreardon Is virtualization available in [email protected]? If so, is there any documentation on how to use it?

[alexreardon]

12.0.0-alpha.2 is now out which contains the first cut of virtual list support. There are no docs yet - you will need to take a look a stories/virtual if you want to see how to set it up

[alexreardon]

@tjramage

Each list's height is determined by its contents, and nothing is scrollable apart from the whole document window itself.

What we are building is support with existing virtual list solutions. If you can set it up with react-window then we should be able to support it

[tjramage]

Thanks for clarifying @alexreardon. Is it just react-window that is supported? I've done some digging and it looks like there could be a working solution but it makes use of react-virtualized along with WindowScroller and Grid.

[alexreardon]

We plan to also support react-virtualized. It uses the same technique as react-window: #1225 (comment)

We will be adding guides and examples for react-window and react-virtualized at this stage. The other virtual list libraries out there should work, but we won't be testing them initially

[tjramage]

Fantastic! Thanks @alexreardon – I'll give the latest v12 alpha release a go later on 👍

[tjramage]

@alexreardon — I gave v12.0.0-alpha.3 a spin today. Managed to get it working successfully with react-virtualized and WindowScroller. Great work! However, it seems like only draggables can be virtualised, which means we will still have potentially anywhere up to 1000 droppables on the page... Do you have any plans to support virtualising droppables, also?

[alexreardon]

For 12.0 we won't be supporting adding droppables. However, we could look at adding support in a future release!

[martaver]

Trying 12.0.0-alpha.6 since I need the mobile portal support, but I get ReferenceError: process is not defined trying to load react-beautiful-dnd. Offending line is:

var isProduction = process.env.NODE_ENV === 'production';

Is this just in there for debugging in alpha vers or something?

[alexreardon]

Strange. This should be taken care of my our / your bundler.

How are you consuming rbd?

[alexreardon]

Big milestone: the build went green!

There is still a fair bit to go and lots of documentation to write. But it is a nice win to celebrate!

Given that the build has gone green, I will now start publishing beta releases for 12.0

[alexreardon]

12.0.0-beta.1 is out

[alexreardon]

12.0.0-beta.2. It fixes a few issues.

[alexreardon]

12.0.0-beta.5

This is just a copy paste of a local file I am working on. But it will be helpful people who are playing with the beta

For most people: you can safely upgrade to 12.0! 🎉 If you are doing any of the following then you will need to change some things. More details are provided below. This is just a super quick guide for you to use.

• Patching onKeyDown, onMouseDown or onTouchStart in DragHandleProps. These event handlers have been removed to support our new sensor approach, and ultimately for good cloning and virtual list support.
• We have renamed our data-* attributes. So if you were using them (perhaps in a test), then things will break for you
• We are no longer using aria-roledescription for lift instructions. Please now use <DragDropContext /> | liftInstruction
• Using @atlaskit/tree 🌲 or something similiar? You will need to stay on 11.x for now. More information below!

Changes

<Draggable /> | DraggableProvided | DraggableProps

This is a major change 💥. For most consumers this will be safe as these data attributes should generally not be leaned on

type DraggableProps = {|
  // inline style
  style: ?DraggableStyle,

-  'data-react-beautiful-dnd-draggable': string,

+  // used for shared global styles
+  'data-rbd-draggable-context-id': string,
+  // used for lookups
+  'data-rbd-draggable-id': string,
  // used to know when a transition ends
  onTransitionEnd: ?(event: TransitionEvent) => void,
|};

<Draggable /> | children

This is a minor change

Adding a third argument to children function: DraggableDescriptor

The children function now has a type! DraggableChildrenFn

type DraggableChildrenFn = (
  DraggableProvided,
  DraggableStateSnapshot,
+  DraggableDescriptor) =>
Node

+ type DraggableDescriptor = {|
+   id: DraggableId,
+   index: number,
+   // Inherited from Droppable
+   droppableId: DroppableId,
+   // This is technically redundant but it avoids
+   // needing to look up a parent droppable just to get its type
+   type: TypeId,
+ |};

But what is it for? It allows you to retrieve all the information about the <Draggable /> from within your children function. Sometimes it can be nice to have all the information at your fingertips, such as what <Droppable /> the <Draggable /> is currently in. The new DraggableDescriptor is especially useful when using the new <Droppable /> | renderClone api. See our new reparenting guide

<Draggable /> | DragHandleProps

This is a major change 💥. The most likely this to break people is the removal of the on element event listeners. These are no longer required with our new sensor approach. So you no longer need to patch event listeners to add your own. We will still call event.preventDefault() on events that we use so you know whether they are being used for a drag. See how we use dom events

type DragHandleProps = {|
+  // focus management is now handled without needing these handlers
-  onFocus: () => void,
-  onBlur: () => void,

+  // new sensor api does not require on element event handlers
-  onMouseDown: (event: MouseEvent) => void,
-  onKeyDown: (event: KeyboardEvent) => void,
-  onTouchStart: (event: TouchEvent) => void,

+  // Moving to new data-* format
-  'data-react-beautiful-dnd-drag-handle': string,
+  // what draggable the handle belongs to
+  'data-rbd-drag-handle-draggable-id': DraggableId,
+  // What DragDropContext the drag handle is in
+  'data-rbd-drag-handle-context-id': ContextId,

+  // New way of doing lift announcements
-  'aria-roledescription': string,
+  // id of drag handle aria description for screen readers
+  'aria-labelledby': ElementId,

  tabIndex: number,
  draggable: boolean,
  onDragStart: (event: DragEvent) => void,
|};

<Droppable />

This is a minor change. It enables using a clone as well as virtual lists

type Props = {|
  // required
  droppableId: DroppableId,
  // optional
  type?: TypeId,
+  mode?: DroppableMode,
  isDropDisabled?: boolean,
  isCombineEnabled?: boolean,
  direction?: Direction,
  ignoreContainerClipping?: boolean,
+  renderClone?: DraggableChildrenFn,
+  getContainerForClone?: () => HTMLElement,
  children: (DroppableProvided, DroppableStateSnapshot) => Node,
+  type DroppableMode = 'standard' | 'virtual';
|};

<Droppable /> | DroppableProps

This is a major change 💥. For most consumers this will be safe as these data attributes should generally not be leaned on

type DroppableProps = {|
  // used for shared global styles
-  'data-react-beautiful-dnd-droppable': string,
+  'data-rbd-droppable-context-id': ContextId,
+  // Used to lookup
+  'data-rbd-droppable-id': DroppableId,
|};

<Droppable /> | DroppableStateSnapshot

This is a minor change. It adds some more information that is useful when building virtual lists

type DroppableStateSnapshot = {|
  // Is the Droppable being dragged over?
  isDraggingOver: boolean,
  // What is the id of the draggable that is dragging over the Droppable?
  draggingOverWith: ?DraggableId,
  // What is the id of the draggable that is dragging from this list?
  // Useful for styling the home list when not being dragged over
  draggingFromThisWith: ?DraggableId,
+  // Whether or not the placeholder is actively being used.
+  // This is useful information when working with virtual lists
+  isUsingPlaceholder: boolean,
|};

<DragDropContext />

type Props = {|
  onBeforeDragStart?: OnBeforeDragStartResponder,
  onDragStart?: OnDragStartResponder,
  onDragUpdate?: OnDragUpdateResponder,
  onDragEnd: OnDragEndResponder,
  children: Node | null,

+  errorMode?: ErrorMode,
+  sensors?: Sensor[],
+  enableDefaultSensors?: ?boolean,
+  liftInstruction?: string,
|};

TODO

Ids

Might break people, but we are simply enforcing pre-exiting types

It has always required that draggableId and a droppableId be a string. Technically you could maybe, possibly, sometimes, get away with using a number when nobody was looking and mum was in the other room. However, due to internal changes that is no longer possible. So we will now explicitly throw an error if a string is not provided.

[alexreardon]

Try here: https://deploy-preview-1487--react-beautiful-dnd.netlify.com/?path=/story/virtual-react-window--board

[nathanpower]

Just checked the storybook preview for v12, looks like the issue that #1394 attempts to address is still present.

To repro, open the storybook with IE11 and open fixed list with fixed sidebar. Try to drag an item such that scrolling is triggered

[alexreardon]

Thanks @nathanpower. I haven't tackled that one. We won't ship 12.0 with open bugs, and it sounds like this is one, so i'll look at it soon

[saaage]

It seems the change to <Draggable /> | DragHandleProps no longer allows an svg to be used as a drag handle. eg:

<div {...provided.dragHandleProps}>
  <DragHandle />  {/* DragHandle icon from @material-ui/core/icons, root element is an svg */}
</div>

was working, but after updating to 12.0.0-alpha.7 I'm unable to drag and receive this warning:

event.target must be a HTMLElement

[alexreardon]

Thanks! Can you try beta.5?

[saaage]

Same warning with beta.5

[alexreardon]

Thanks for checking. I’ll resolve this early next week

[alexreardon]

@sage911 this should be fixed in 12.0.0-beta.7. Let me know how you go. Thanks for raising the issue. I have added a test to cover the use case and the fix to the code

[saaage]

Yup all fixed, thank you! And thank you for all of your work on this excellent library.

[richard-buckingham]

@alexreardon - Firstly, I'd like to express my appeciation for your work on react-beautiful-dnd, it is awesome :-)

Also, apologies if this is not the appropriate place to ask this question.

I'd like to ask a question about version 12 of react-beautiful-dnd.

Will react-beautiful-dnd support dynamic row heights with react-virtualized? E.g, a virtualised version of https://deploy-preview-1487--react-beautiful-dnd.netlify.com/?path=/story/nested-interative-elements--stress-test ?

I've had a look at https://deploy-preview-1487--react-beautiful-dnd.netlify.com/?path=/story/virtual-react-virtualized--window-list, but the items are of fixed height.

I'm using react-virtualized 9.21.1 to render a list of interactive elements using AutoSizer, List, CellMeasurer and WindowScroller, similar to https://github.com/bvaughn/tweets/blob/37d0139736346db16b9681d5b859a4e127964518/src/components/TweetList.js#L126-L132
A list of 12 items displays ok, but when I try to drag item 1 below item 2, both items disappear.

I've checked out https://github.com/atlassian/react-beautiful-dnd/blob/dev/docs/patterns/virtual-lists.md, and the samples at https://github.com/atlassian/react-beautiful-dnd/tree/dev/stories/src/virtual/react-virtualized, but no luck as yet.

Btw, I updated to [email protected] this morning.

[alexreardon]

Yum: https://codesandbox.io/s/simple-virtual-list-feeyu

[nathanpower]

Just checked the storybook preview for v12, looks like the issue that #1394 attempts to address is still present.

Seems to be fixed now, thanks! 👍

[alexreardon]

Boya! @nathanpower

[alexreardon]

The plan is to ship tomorrow 🤫

[alexreardon]

Shipped! Thanks so much everyone for your input and support https://github.com/atlassian/react-beautiful-dnd/releases/tag/v12.0.0

[paulhan221]

@richard-buckingham were you able to find an answer/fix to your CellMeasurer issue? Having a similar problem