How to create complex interactions with dnd-kit. A how-to that I hope is going to help some folks.

[growthwp]

This is an extremely long, exhaustive read about how we created a completely full-fledged drag & drop page builder with what I believe is a very elegant solution, using dnd-kit. The concepts apply to practically any complex interaction you'd want, not just a page builder. At first, I'll be talking about how the drag & drop of items inside a page happens, moving a section on top of another and so on, and then, briefly explain how you'd want two seemingly unconnected DnDContexts to interact with one another.

Introduction, long, skip if you don't care: About 1-2 years ago, we've kickstarted our efforts to create a page builder that trumps them all. Currently, WordPress' main mammoths don't hold a candle to big companies' page builders and are basically just toys. Their core code is also a total, complete disaster. Can't name them! Legal reasons and all that. As such, we needed something new. Picking dnd-kit was a no-brainer. It had lots of cool functionality that we could see used for a form builder, the sortable had lots of features and so on. Unfortunately, where it lacked (or so I thought) was creating very complex interactions, such as a page builder would need. Drag items on top of one another, before, after, to the right/left, add items, remove them and so on. Well, we did it and I believe it's a really clean approach.

In just ~12 months, a team of two developers (but, really, one, in his spare time) have managed to actually build the features of all the other builders and then some more, of course, the DnD being just a smaller part. All API-ified, tested and the code is as good as one can hope to get - it's been re-written 3-4 times, after all. The project, overall, spans a crazy LoC of ~130k TS, it's mostly logic for how things interact and lots of mumbo-jumbo to create nice interactions. At this point in time, I can't offer a visual preview, as we're prepping for a huge release of a fleet of themes that will be using it and something tells me that the features we'll be offering will make a few folks mad, so, keeping that secret, but I can tell you that we've made lots of considerations, re-written the DnD pieces over and over and had 5/6 user-testing sessions for the DnD interactions alone.

Anyways, @clauderic has been extremely helpful to everyone and I thought that, if someone is wondering if you can create really complex interactions through dnd-kit, you can - and easily so.

Communicating with the outside world.

For the OG's, back when dnd-kit was a child, we didn't have the data argument that you could pass to useDraggable. Unfortunately, that meant you were constrained to "one dimension" of drag & drop. Couldn't really tell much of what was going on. Once it got introduced, it actually made everything practically possible. You could now tell all kinds of information about a drag event.

Here's how we defined our "draggable handle" (more on why this is later):

/**
 * A draggable icon that is meant to be the drag handle for an editable.
 */
export const DraggableIcon = ({ id, type, className = '', ...props }: Props): JSX.Element => {
  const { attributes, listeners, setNodeRef } = useDraggable({
    id: `${type}_${id}`,
    data: {
      id,
      type,
    },
  });

  return (
    <div className={`${styles.icon} ${className}`} {...attributes} {...listeners} ref={setNodeRef} {...props}>
      {props.children}
    </div>
  );
};

In our system, an editable is a section | row | column | component. Editables can be dragged around. A section after another section, a component inside a column, a row after another row and so on. We have a total of ~100-something interactions like this, even combining rows. The idea is as follows - when you define your DndContext, you have the onDragEnd prop to decide what you want to happen when a drag event has finished. Ours looks like this:

    dispatch(toggledDragging({ isDragging: false }));

    const { active, over } = event;

    if (!active || !over) {
    return;
    }

    /**
     * Dragged item data.
     */
    const { id: draggedId, type: draggedType } = active.data.current;

    /**
     * Dragged on data.
     */
    const { id: draggedOnId, type: draggedOnType, position } = over.data.current;

    dispatch(
    editableMoved({
        draggedId,
        draggedType,

        draggedOnId,
        draggedOnType,

        position,
    })
    );

A few things to note - we're using Redux (RTK). The very first to fire is that "we're no longer dragging", when the user has let go of the click, whatever the outcome, we are done dragging. We keep track of this isTracking global variable so that we can prevent some actions from happening, enable some classes and so on, you get the point. Then, we check that there is both an active and an over, if there aren't, it either means that:

• The user has dragged an editable on another editable which doesn't want to interact with it (more on this later)
• The drag event is somehow bugged. Who knows? Something got in the way, weird z-index plays and so on.

If all's well, we proceed. Notice how we're destructuring both of them to get both the dragged (the item that's being dragged)'s id and type, as well as the draggedOn (what we dropped this draggable on). There's also the position argument, which I believe is where we could've done much better - as far as I was concerned, there was no easy way to tell which edge of the "dropped on" editable the user has dropped a draggable on, as such, our implementation of the "droppable area" is, really, an "edge":

export const Edge = ({ containerId, containerType, position, className = '', ...props }: Props): JSX.Element => {
  const { setNodeRef } = useDroppable({
    id: `${containerId}_edge_${position}`,
    data: {
      id: containerId,
      type: containerType,
      position,
    },
  });

  const [visible, setIsVisible] = useState(false);

  const { over } = useDndContext();

  const color = editablesInformation[containerType]?.color;

  useEffect(() => {
    if (over?.id === `${containerId}_edge_${position}`) {
      setIsVisible(true);
    }

    return () => {
      setIsVisible(false);
    };
  });

  return (
    <div
      ref={setNodeRef}
      className={`${styles.edge} ${styles?.[position]} ${visible ? styles.visible : ''}`}
      style={{ backgroundColor: color }}
    ></div>
  );
};

The containerId is our editable's unique id, the position is where this edge is (left, right, top, bottom...maybe more?) and the type is the editable's type. Remember, an edge only functions within an editable and is a position: absolute item inside that editable, which acts simply as a container. Here's a small preview of how an edge looks: https://i.imgur.com/7cLlwiZ.png - as I was explaining, the CSS looks something like this:

.edge {
  display: flex;

  visibility: hidden;
  opacity: 0;

  position: absolute;

  z-index: 2;
}

And if we turn our attention to that over variable, which we're getting by using useDndContext, you can see that we do a little check. (over?.id === `${containerId}_edge_${position}`), this basically ensure that we only run the code that comes next if our edge currently has a draggable overlay over it. If we don't do this check, they all fire up and show. Obviously, the next thing is to set the edge as visible. In our case, rows can only have two droppable areas, the top and the bottom, so, inside our Row component, we just render two Edge components, using an utility-component DroppableArea:

export type Edges = {
  top?: boolean;
  bottom?: boolean;

  left?: boolean;
  right?: boolean;
};

type Props = ComponentPropsWithoutRef<'div'> & {
  id: `${EditablesKeys}_${number}`;
  type: EditablesKeys;
  className?: string;
  /**
   * By default, the droppable area is hidden. When a drag event happens, we enable it.
   *
   * @todo Could this create issues if we want to do something else during the drag event?
   */
  displaying: boolean;

  /**
   * Edges represent the outer side of each droppable area. These are used in order to determine at which
   * side of a droppable has a draggable been dragged on.
   */
  edges?: Edges;
} & UseDroppableArguments;

/**
 * A component that inherits its parent height/width and acts as a "shadow div" inside of it so that
 * draggables can be dragged inside of it.
 *
 * The reason for creating this component is that combining the refs of both `useDraggable` and `useDroppable`
 * leads to a lot of bugs. Well, duh.
 */
export const DroppableArea = ({
  id,
  type,
  data,
  disabled,
  displaying = false,
  edges,
  className = '',
  ...props
}: Props): JSX.Element => {
  return (
    <div className={`${styles.area} ${displaying ? '' : styles.disabled} ${className}`} {...props}>
      {edges ? (
        Object.keys(edges).map((edgeId) => (
          <Edge key={`${type}_${edgeId}`} containerId={id} containerType={type} position={edgeId as keyof Edges} />
        ))
      ) : (
        <></>
      )}
    </div>
  );
};

In our case, we'd just simply do: <DroppableArea edges={top: true, bottom: true} ... />. To mention that, if you don't wrap your droppables like this, it tends to lead to very questionable behavior due to refs - don't ask me, I just figured why it happened and fixed it.

Right, so, assuming the user is dragging something over our row, and it's on top of either the top/bottom edges, once the user lets go of the mouse button, the system sees a drag event has finished. Back to our onDragEnd - inside our over variable, we have over.data.current which contains - you guessed it - the data from the edge. We know that we're dropping on row_0, an editable of type row and we're dropping on top of it. What we drop is given, again, by active.data.current. Ultimately, the data we pass to - and this is where the brains begins - our handler is as follows:

draggedId,
draggedType,

draggedOnId,
draggedOnType,

position,

But the problem is now that we can't really do much with this. Well, we dispatch an action - editableMoved - to the Redux store, but before any data ends up there, it hits a reducer. Reducers are simply callbacks that respond to action being fired (in reality, they do something else, let's keep it simple) and then change the state somewhere. If we have row_0 before row_1 and we want row_0 to be AFTER row_1, then, assuming we had an ordered list, obviously, we'd want it to look like row_1, row_0 and then we just render it.

So, we have these 5 variables from above. We need a central system that dictates what interactions are possible - you can't really drop a section inside a component, can you? :P

The very first thing that this action sees is our "find the callback for this specific interaction and then run it" reducer:

 const { draggedId, draggedType, draggedOnId, draggedOnType, position } = action.payload;

    /**
     * First of all, if the item we dragged on's type isn't inside the dragged's "accepted" values
     * for DnD interactions, bail out early.
     */
    if (!(draggedOnType in interactions)) {
      if (!interactions[draggedOnType].accepts.includes(draggedType)) {
        if (process.env.NODE_ENV === 'development') {
          console.error(
            `The draggable with id "${draggedId}", of type "${draggedType}" cannot be dragged over droppable with id "${draggedOnId}" (of type "${draggedOnType}, the only droppables it can be dragged inside are of the following type:`
          );
        }
      }
      return;
    }

    /**
     * We can't drop the draggable inside itself :)
     */
    if (draggedId === draggedOnId) {
      if (process.env.NODE_ENV === 'development') {
        console.error(
          `The draggable with id "${draggedId}", of type "${draggedType}" cannot be dragged over droppable with id "${draggedOnId}" because they're of the same type. Please let us know if you find good use-cases for this functionality :)`
        );
      }
      return;
    }

    const dndActionCallback = getActionCallback(draggedType, draggedOnType, position);

    if (dndActionCallback) {
      dndActionCallback({ state, draggedId, draggedType, draggedOnId, draggedOnType, position });
    }

Notice that we do a few checks. First is, !(draggedOnType in interactions), we don't want any unsupported draggable types to do anything, right? Ok, but what's interactions, then? It's the brains of it all: the object that decides which editable can interact with which. Let's take a look:

/**
 * The supported draggable types are keys of editables that can be dragged around (and therefore dropped).
 */
export type SupportedDraggableType = 'section' | 'column' | 'row' | 'component';

/**
 * The supported drop types are matching editable keys that can receive other editables
 * during drag & drop interactions.
 *
 * @todo Extend this from the outside. What do we do when a new editable enters the system?
 */
export type SupportedDropType = 'section' | 'column' | 'row' | 'component';

export type SupportedDropPositions =
  | /* on */ 'top' /* of */
  | /*at the */ 'bottom' /* of */
  | /*to the */ 'left' /*of */
  | /*to the */ 'right' /* of */;

/**
 * An object which contains possible drag & drop interactions for draggables/droppables.
 *
 * The `accepts` key in each interaction node contains an array of editable keys. For example, if
 * our node's key was `section` and its `accepts` key contained "['component']", we could say that `section`
 * ONLY accepts editables with the key `component`.
 */
export const interactions: Record<SupportedDraggableType, { accepts: SupportedDropType[] }> = {
  component: {
    accepts: ['component'],
  },
  column: {
    accepts: ['component', 'column', 'row'],
  },
  row: {
    accepts: ['component', 'column', 'row'],
  },
  section: {
    accepts: ['section', 'column', 'row', 'component'],
  },
};

Right, so, we can see that column, accepts component, column, row. Going back to our code, the next check - (!interactions[draggedOnType].accepts.includes(draggedType)) does exactly what you think it does - it takes the item we're dragging on and looks inside its accepts keys and checks the type of the item we dragged is inside there. If it is, it means that the interaction can happen. In our case, we're dragging a row on top of a row, so, row.accepts does, indeed, include row. Great, so, it means we can proceed. Let's try and get a "DnD action callback" - const dndActionCallback = getActionCallback(draggedType, draggedOnType, position);, but, hold on a second, we're now also asking for a position to be checked?

Yep! So, you implement this at your discretion, and I can't share exactly why we chose to do things this way, because it's actually very, very smart if you're thinking about some things, but we have another "check if interactions are possible system". Let's take a look:

export const getActionCallback = (
  draggedType: SupportedDraggableType,
  draggedOnType: SupportedDropType,
  position: SupportedDropPositions
): ActionCallback | false => {
  return actions?.[draggedType]?.[draggedOnType]?.[position] ? actions[draggedType][draggedOnType][position] : false;
};

So, we're looking at a draggedType and then at a draggedOnType and then at a position to see if it exists and return it if it does. Our actions has the following typings:

/**
 * The collection of actions.
 */
const actions: {
  [draggedType: string]: {
    [draggedOnType: string]: {
      [position: string]: ActionCallback;
    };
  };
} = {};

(which should be typed differently, string doesn't really tell you much, but let's keep going) - so, we see that our position key contains an Action package (which, in turn, contains the ActionCallback):

type Action = {
  /**
   * The type of the editable that's been dragged onto something.
   */
  draggedType: string;

  /**
   * The type of an editable that had an editable dropped on it.
   */
  draggedOnType: string;

  /**
   * The callback which will be executed when a drag & drop movement has finished.
   *
   * The `draggedType` will be used to determine the source of the drag and `draggedOn` will
   * be used to identify the destination. Together, they will form a path such as `column->row`
   */
  callback: ActionCallback;

  /**
   * The position indicates where the item has landed after a drag. The four positions can be "top", "bottom",
   * "left" and "right."
   */
  positions: SupportedDropPositions[];
};

and the actual callback itself:

type ActionCallback = (params: {
  //Specific to Redux, can ignore.
  state: BuilderState;
  draggedId: WrappedEditableId;
  draggedType: EditablesKeys;
  draggedOnId: WrappedEditableId;
  draggedOnType: SupportedDropType;
  position: SupportedDropPositions;
}) => void;

...which is, again, just a function! Great, so, of course, we also have an addAction function somewhere, which simply adds one of these an populates our actions object. We use it as such:

  addAction({
    draggedType: 'section',
    draggedOnType: 'section',
    callback: ({ state, draggedId, draggedType, draggedOnId, draggedOnType, position }) => {
      switch (position) {
        case 'top':
          //Do whatever when a section has been dragged on top of another.
          break;
        case 'bottom':
          //Do whatever when a section has been dragged before another.
          break;
      }
    },
    positions: ['top', 'bottom'],
  });

Which basically says that you want an action to happen every time a section is dropped on type of a section and then that this specific callback should only run only if the position(s) is either top or bottom. So, where do these come from? Alright, we're going back to our reducer. Remember how we did all these checks to see if an editable supports an interaction with another editable, then we did this second round of tests to check if there's something to do for a valid interaction AND a valid position-interaction? Yea, the next line in our reducer was dndActionCallback({ state, draggedId, draggedType, draggedOnId, draggedOnType, position }); - we're calling the exact callback that we added above. We're passing the current state (which is just Redux' store - we have to hold all this data somewhere, right?) and all the other items from before.

And, well, if onDragEnd, the system finds that an editable of a certain type can interact with another editable of some type, then, if it also finds that there is a callback registered for that interaction AND also the position representing where the user dropped that draggable, then it simply calls that callback. In my case, that callback figures out all that it needs in order to re-compute state such that it reflects what the user sees on the screen - moves entities around, removes/adds data and so on.

The initial fear I had with dnd-kit was that it didn't give you many building blocks for data-rich interactions and I still think that very-very-very complex interactions are a bit hard, but this system makes sense and it's elegant.

In short, play with the data argument and you'll figure it out from there on.

But, then, most page builders have a sidebar and an item that you can drag on top of items that already exist on the page, how do you go about that? Again, the data argument for your draggable/droppable(s). All the same concepts above apply. While I believe this is a lie I made myself believe, if two items, no matter how far in the tree, have a DnD interaction, then they should be under the same DndContext. In reality, I think that shouldn't be the case, but, so far, I haven't seen issues.

Just wanted to walk you through our decision-making and the struggles we had when trying to build a page builder - and we succeeded.

In short:

1. Create an object where you store actionCallbacks, ask for a function that will fire when a drop event happens.
2. Create components that, when dropped, will (inside onDragEnd) give the required data to our system: the componentId (unique ID to identify the actual component an user sees), the componentType - in our case section | row | column | component for both the dragged and the dropped-on components at a minimum.
3. Once the drop event is finished, do some checks to see if, for example section can interact with row (as in, a user has just dropped a section on a row - can the system do something with that?). If all's good, proceed.
4. If all's good, then simply look inside that actionCallbacks object for a callback: look by the draggedType's first, so actionCallbacks['section'], then, by the draggedOnType, so actionCallbacks['section']['row'] and, finally, by position, so actionCallback['section']['row']['top']. Inside your addActionCallback function, you should support the addition of items like this. We found this is the best way to define interactions in a page builder. So, your addActionCallback function should look something like this:

addActionCallback = (draggedType, draggedOnType, position, callback) => {
  //Of course, JS can't create object just like this, but you get the point :P
  actionCallbacks[draggedType][draggedOnType][position] = callback;
}

5. If the callback is found, execute it. In our case, the sections, rows, columns, etc. that the user sees on the page are simply just a visual representation of the (part of) Redux store, so, in our callbacks, we modify the Redux store somehow (for example, if a person dragged row_1 inside section_2, we'll assume that row_1 will be the last one in the section and add its id after other rows' ids if they exist, so, if section_2 had rows with ids row_3, row_4, it would now be row_3, row_4, row_1). Ultimately, these callbacks are the most important thing in your system - they decide how data is shuffled. Everything, so far, has been to support reaching this callback.

---

Things I wish dnd-kit had and limitations you should be aware of (possibly, not entirely sure if we just simply don't know enough about dnd-kit):

• Some way to detect edges of a droppable. The creation of the Edge component was only done in response to not being able to tell which side of the droppable a draggable was dropped on, and, then, not sure if onDragOver allows you to see an edge-like position/information thingie.
• From day one, I was a big sponsor of re-writing the library's core to basically let both drag/drop events bubble as deep as they need to, until one handler decides to handle them, kinda like...how we wrote our page builder? As it stands, it takes some maneuvering to achieve anything complex and there's no down-side (that I can think of, from the outside, but that's easy to say, it's always easy to "just fix it") to doing things that way.
• Perhaps I'm wrong, but you can't swap DndContext's sensors or any of the collision detection algorithms on the fly, based on the item being dragged and so on. This is a limitation that I dislike. I wish there was some way. Some items in a page might prefer a certain collision technique than others.

[JalalMitali]

is this one ( or part ) open source if so can you share the repo please thanks!

[growthwp]

Hey, when the entire ecosystem will be released, this will be open-source. Not sure on an ETA, as the page builder is just a small part of our entire product offering. If you have any questions, feel free to ask, however, the guide is, in my opinion, the way to build a page builder. The approach takes care of how you'd wanna define limitations (on how, say, a section interacts with a row), it doesn't tie you into any logic and, overall, after nearly a year of usage, where we kept adding features to the entire system, we haven't had any issues or felt as if we were limited by this.

In fact, we recently refactored DroppableArea to also be of any height/width, not just a collection of Edges, the need was that, at times, you wanna drop a component inside of another (not just on edges) and we had no issues with that: add another position, add another callback and it just worked.

It's a very good system and, given Redux' actions, you can do anything in response to drag events being fired. It is unfortunate that dnd-kit doesn't support this type of interaction from the get-go (well, at least nothing that I could come up with, using just the library itself), but there it is. Realistically, if you need to build something like this, you are using a state management library, so, just replace Redux with whatever you want.

[JalalMitali]

I am already building it here with Redux however I am facing some issues but I'll just keep going hopefully it ends up well! I have been working on it for over a week now and thanks for the reply!

[paulwongx]

@growthwp Thanks for sharing all this - it's helpful to know how to think through building a no-code editor. I can understand not sharing the source code to protect your ip. Would you be open to sharing the final product to see how it looks, esp since it's been a while since the original post?

[growthwp]

To note, Redux has RTK, which helps with precisely this type of structure. It also has lots of helper functions to help you organize, select and update each entity. It's not an ORM, but you can use an ORM on top of it.

[paulwongx]

Thanks! Had to reread that a few times but I think it makes sense.

1. I realized your first implementation is using a draggable over a droppable so it makes sense to bail out onDragOver because that container is always detecting things over it. In my implementation, it's similar to the multi-container example where a sortable is over a sortableContext (as in, the items are sortable as opposed to drag and drop) so the detection of which elements the item is allowed to be "over" is determined a bit earlier. But overall, we're on the same page - the collisionDetection primarily determines the collisionDetection algorithm - whether one uses rectIntersection, closestCorners, closestCenter, etc. - and can also be used to avoid being over certain containers.

2. If I understood correctly, this to me sounds like your v2 is using mostly sortables (SortableContext and useSortable) which I also think will give users a much free-feeling experience, which is great!

3. Thanks for this. It was helpful to understand the deletion process for your project. For mine, it's not as well structured or documented, but my implementation also just iteratively deletes items based on the hierarchy. But I'm not certain I fully understood the structure of the main state. You noted that "Yes, flatten everything". So on a high-level, would it be correct to assume you also ended up with something more akin to a hashmap of editables, rather than a tree?

From your answer, I think you ended up with something like this right?

const allEditables = {
  section1: {type: "section", children: ["row1", "row2"] },
  row1: { type: "row", children: ["col1"] },
  row2: { type: "row", children: [] },
  col1: { type: "col", children: ["content1"] },
  content1: { type: "content", children: [] },
};

What I ended up with was something like this... where the items object has the parentId. As I write this, I realize it's similar except that you put children in each object as opposed to separating it out like in my implementation. My approach is unneccessarily complicated but it avoids having to filter for all items that are "rows" every time you want all the "rows", but I think your structure is easier to navigate and understand.

const state = {
  // Essentially an items lookup hashmap
  items: {
    section1: { type: "section", parentId: "root" },
    row1: { type: "row", parentId: "section1" },
    row2: { type: "row", parentId: "section1" },
    col1: { type: "col", parentId: "row1" },
    content1: { type: "content", name: "text" },
  },
  // The array of childrenIds for each id. Essentially your `children` above, but broken out
  section: {
    section1: ["row1", "row2"],
  },
  row: {
    row1: ["col1"],
    row2: [],
  },
  col: {
    col1: ["content1"],
  },
  content: {},
};

And to confirm, we're both saying we aren't doing this to maintain our main state..

const tree = {
  root: {
    type: "section",
    children: [
      {
        row1: {
          type: "row",
          children: [
            {
              col1: {
                type: "col",
                children: [
                  {
                    content1: {
                      type: "content",
                      name: "text",
                    },
                  },
                ],
              },
            },
          ],
        },
        row2: {
          type: "row",
          children: [],
        },
      },
    ],
  },
};

Again, thanks for your thoughts. This has been helpful to get another perspective on!

[paulwongx]

In the dnd-kit examples, their sortable tree example state is... well.. a tree... so suffice to say, this way can work too... and then they have a flattenedItems memoized structure...

Edit: Okay, so I realized the way I wrote my tree example above should be moreso like the example below. So the below implementation is the cleaner tree if using a tree structure.

const initialItems: TreeItems = [
  {
    id: 'Home',
    children: [],
  },
  {
    id: 'Collections',
    children: [
      {id: 'Spring', children: []},
      {id: 'Summer', children: []},
      {id: 'Fall', children: []},
      {id: 'Winter', children: []},
    ],
  },
  {
    id: 'About Us',
    children: [],
  },
  {
    id: 'My Account',
    children: [
      {id: 'Addresses', children: []},
      {id: 'Order History', children: []},
    ],
  },
];

const flattenedItems = useMemo(() => {
  const flattenedTree = flattenTree(items);
  // ....
}, [activeId, items]);

Hm... I think this works for this tree example because everything is under ONE sortableContext, so the single memoized flattenedTree can be provided into the SortableContext, but if we have true nested elements (section -> row -> col -> content) with each being a sortable container, we'd have to flatten at every node. So for this reason, maybe the flat structure is still more appropriate for a no-code block builder since the array of children ids are cleanly available... open to other thoughts though...

[growthwp]

2. Not really, we just literally allow you to drag an item around freely. If you ever used Illustrator or Photoshop, it's the same thing. We just handle all of the math ourselves (to determine which section, group, etc. a dragged item is in, since hierarchy is still maintained). This entire design approach with sections/rows/columns is dated, problematic and just a bad experience all around. I don't really look at other builders, but I know for a fact they all work like this.

As for the shape: First of all, I can tell you're trying to fix in a SortableContext inside a page-builder-like interface, so all the DndContexts work. This is not something we ever had to do, so, the following will probably be useless to you, however, if your question(s) is about the shape of things, without needing to account for SortableContext, well: yes, while not precisely that, your approach would work. We just insert the rows key inside [a] section and the system knows to look inside sections['section1'].rows to grab a list of rows, but children also works. No downsides to either, except that, if you don't have all this auto-generation of trees, going with rows means...well, that you have to build it, whereas with children as a key, you can just assume that an item has any children if it's not empty.

As for "hashmap" structure, at least to me, it is confusing, yes. Again, in our case, the hierarchy is dictated by the object, and we just look inside of it to see what type is the parent of a given editable. The reasoning behind this - might not apply to you - is that, we didn't know how much/if we'd need an ORM, however, I wanted to prepare the structure for any change. Even in your case, it'd work with an ORM, but the structure, in the context of an ORM, just seems to hold a lot of unnecessary info, so, I just relied on that object I can change any time and how I want to determine the relationships. Again, your thing is fine, you'll just have to do more deleting/refactoring if you wanna use an ORM.

So, we're not doing the same, no. In your case, you'd have to write all kinds of complicated CRUD functions, oooooooooooooooooor, you could use RTK! Our state is just this:

sections: {
  ids: ComputedEditableId<'section'>[];
  entities: { [id: ComputedEditableId<'section'>]: { rows: ComputedEditableId<'row'>[], data: SectionData } };
}

rows: [
 //Same as above.
]

That's just it. We use the relationships object from before to determine who's whose parent, child and so on.

Anyways, again, we never had to implement SortableContext, because it kinda just naturally happens if you can order everything however you want it (with some checks) anyways.

[paulwongx]

@growthwp I finished creating a draft of my Sortable approach and while there are a few bugs (the page keeps refreshing lol) it gets laggy after a while since there are so many sortable contexts. I was contemplating your old approach with many draggables and droppables (no sortable contexts) - did you find your approach caused any lag after having a lot of elements or did it perform fine? Appreciate your insight!

I'm also contemplating rewriting it without a library and wondering if that might be less laggy rofl... but it'll probably be a behemoth of a task..

[ahmadmubarak98]

@growthwp Where can we follow the updates for this? I can't wait to see it in action!!

[taziksh]

^

[ZhangHanwen96]

would you please share the repo, thanks a lot😃!