Add DnD feature to TreeView

[matuzalemsteles]

The TreeView specification puts the DnD implementation as optional, we just have to study if this is feasible to be added to a TreeView and the implications that this can bring in terms of performance.

• DnD Spec

[julien]

Hey @matuzalemsteles, the DnD Spec doesn't really specify anything: it's just a screenshot with the sentence "Dropping a node on a valid target". I understand that we want to be able to drag one node onto another, but do you think we need to speak with lexicon to make sure we're on the same track?

One the technical side of things:

I noticed we already have react-dnd in the project (can't link to the yarn.lock file because GitHub won't show a preview but you'll find it there), even though it's only used for examples and wanted to know if you thought it would be a good idea to keep on using it.
I'm asking because we use a rather old version (10.0.2), and upgrading to the latest isn't an option right now because it requires node 12.x (even thought the package.json in their repo says it's ok with 10.x).

Concerning the implementation itself, since we'll need to reorder the TreeView's items when the drag operation ends, I was thinking of using the id of the dragged item as well as the id of the item it was dropped on in order to achieve this. The only problem I'm facing is that the TreeViewItem is aware of it's id (via useItem) but the parent TreeView has no idea about this, which is kind of strange (shouldn't the item's ids be generated straight away).

[matuzalemsteles]

We talked a few things about this via call on Slack, I'll just add a few things.

the DnD Spec doesn't really specify anything: it's just a screenshot with the sentence "Dropping a node on a valid target". I understand that we want to be able to drag one node onto another, but do you think we need to speak with lexicon to make sure we're on the same track?

We agree that we are going to talk to Lexicon to understand the requirements, Julien raised some interesting points as it may exist in some cases that have a tree based on files where we have documents and images, sometimes these cases do not make sense to move a document to become a sibling of the folder, this would be a case-by-case drop rule. But the important thing is whether we should also allow only reordering nodes on the same level or would it be allowed to move up and down.

cc @drakonux @hold-shift

As this would also be optional and not required, we can also ignore this for now until we understand the requirements more. If for this case.

I noticed we already have react-dnd in the project (can't link to the yarn.lock file because GitHub won't show a preview but you'll find it there), even though it's only used for examples and wanted to know if you thought it would be a good idea to keep on using it.

Oh yeah, I think we added it to the demos just to demonstrate how some Clay components using React DnD, the biggest motivation is that DnD could be implemented in different ways by the team, usually, each one had its own visual and interaction strategy.

Anyway, we agree to try using another library, like react-beautiful-dnd.

Concerning the implementation itself, since we'll need to reorder the TreeView's items when the drag operation ends, I was thinking of using the id of the dragged item as well as the id of the item it was dropped on in order to achieve this. The only problem I'm facing is that the TreeViewItem is aware of it's id (via useItem) but the parent TreeView has no idea about this, which is kind of strange (shouldn't the item's ids be generated straight away).

I think we've talked about it but anyway the current implementation is that it works for the different cases, the static and dynamic content, so the TreeView component will use the items for dynamic content and will create an Array to from the children when it is static content. The point I want to make is that we use the ItemContextProvider nested, so it's declared so that rendering structure level components have visibility of the item being rendered at that moment, it would be the same thing to think about it with rendering in tree, so the TreeView component has no visibility because it starts rendering the items, so it will only have visibility of the items.

But I think I understand your point the difference is that we didn't use a flat tree structure to render the elements because I didn't want to build this structure before starting rendering and it would be difficult to keep it up to date, for example, any change that occurs in this structure would have to be reflected in the items structure, if we move an element we would have to do the same in the items structure, one thing we can investigate is to allow rendering using flatten structure so we can rely on that structure to handle this without creating it in runtime but would still have to investigate how to do this with a user-friendly design. Apparently, some APIs already support requesting the flat structure, my concern is that this is not true for everything.

[julien]

@matuzalemsteles thanks for adding this information here.

I wanted to add one more thing about the spec, I briefly talked with @drakonux on Slack and we agreed that the main use case is to be able to drag nodes around, ideally expanding them if they have nested nodes (like directories) when they are "hovered". Concerning replacing nodes, I think this can be done in the future and we might want to leave this as something to be implemented by the developer, maybe a callback, although that part is still not clear for me in terms of implementation - so that's one more thing we can analyze.

I'm also going to use react-beautiful-dnd (interestingly it also uses render props to allow rendering "anything"), it's a bit more straightforward to use than react-dnd but we'll still need to be able to manage the items based on ids of some sort, so I'll grab the latest changes you made to #4222 and have a thought on this (since now we're using keys and not ids).

[julien]

@matuzalemsteles just putting this here in case in rings a bell while I try to find a solution.

I fetched #4222 to start working on dnd support. Trying to add any package from the clay-core module with yarn add DEPENDENCY_NAME fails with the following message.

error An unexpected error occurred: "expected workspace package to exist for \"eslint\"".

Which seems very strange, since it's the first time I'm seeing this happening. I haven't changed my node, npm or yarn version.

[julien]

@matuzalemsteles follow up on my previous comment, the only way I managed to fix was with this solution, probably not something we want to do, but at least I'm not stuck anymore.This reminds me how broken frontend tooling is.

[EDIT 1]: Actually didn't fix everything because yarn updated the react-dnd version so now our drag and drop demos are broken ... I have the feeling I'm going to be stuck in this loop for a while.
I'll undo my changes, and see what happens.

[EDIT 2]: Finally out of the loop. What I did was checkout all my temporary changes, uninstall yarn and re-install specifically version 1.19.0, re ran yarn install DEPENDENCY_NAME and no complaints this time ... so I'll stick with that version for now. I'm surprised this even happened.

[julien]

@matuzalemsteles just an update, using react-beautiful-dnd with the current implementation of the TreeView as it is right now in #4222 works but it's very tricky, maybe because of the fact it's both using dynamic and static content or because of the render props usage, or the way the components are structured. I think we should take time to think about this a bit before thinking of adding more features, because if adding drag and drop is costing so much, it might be a sign that this is too complex. (Just a thought) but that's also related to what you were asking concerning #4218

[matuzalemsteles]

Trying to add any package from the clay-core module with yarn add DEPENDENCY_NAME fails with the following message.

It pops up to me sometimes too, but I don't remember now how I fix it. Apparently, it's related to the yarn version and they fix it in v2 😅.

just an update, using react-beautiful-dnd with the current implementation of the TreeView as it is right now in #4222 works but it's very tricky, maybe because of the fact it's both using dynamic and static content or because of the render props usage, or the way the components are structured. I think we should take time to think about this a bit before thinking of adding more features, because if adding drag and drop is costing so much, it might be a sign that this is too complex. (Just a thought) but that's also related to what you were asking concerning #4218

Hmm I see, I'm thinking of a way to use rendering with a flat structure but for that I only see the option to support flat structure data to not do this at runtime but I can't see a way to support static content. I only see the option to change the tree structure and traverse to make the drop changes.

If we are going to make a flat tree structure at runtime, we will have trouble keeping it up to date, because we will also have to update the tree anyway.

[julien]

It pops up to me sometimes too, but I don't remember now how I fix it. Apparently, it's related to the yarn version and they fix it in v2 sweat_smile.

Switching back to 1.19.0 made it work for me, seems like it's fixed for now.

Hmm I see, I'm thinking of a way to use rendering with a flat structure but for that I only see the option to support flat structure data to not do this at runtime but I can't see a way to support static content. I only see the option to change the tree structure and traverse to make the drop changes.

If we are going to make a flat tree structure at runtime, we will have trouble keeping it up to date, because we will also have to update the tree anyway.

I agree, it's not easy. I also think we could generate an "id" for each child when the component is created, for example, when we receive the items prop, we could generate a "uuid" for each child and that way we'd have a way to know which item has been moved after a drag and drop and reorder our "items" array. Does that make sense?

[matuzalemsteles]

I agree, it's not easy. I also think we could generate an "id" for each child when the component is created, for example, when we receive the items prop, we could generate a "uuid" for each child and that way we'd have a way to know which item has been moved after a drag and drop and reorder our "items" array. Does that make sense?

Yes it might make sense, now as I commented before in the expandable PR, I think we can ignore the reordering and drop for static content because even though we build a flat structure in parallel we wouldn't be able to use it to change and have effect on rendering of the elements. Because we would need to build the flat structure before rendering and lock the rendering until it's done (the lock isn't necessarily explicit) so we could use the structure for rendering and any effect it has will affect it visually.

The problem with this is that it is not very cheap, mainly because we are concerned with performance and we would also have to create a synchronization for everything that is modified in the flat structure must also be reflected in the tree structure, for example:

const flatItems = {
  main: {
     children: ['1']
  },
  '1': {
     children: ['2', '3'],
     parent: 'main'
   },
  '2': {
     children: ['4', '5', '7'],
     parent: '1'
   },
};

const treeItems = [
  {
    children: [
      {
        children: [
          {children: [...], id: '2', name: 'Child 2'}
        ],
        id: '1',
        name: 'Child 1',
      }
    ],
    id: 'main',
    name: 'Main'
  }
];

// For example, mover the Node 2 to be Node 1 sibling:

moveToSibling('2', 'main');

// Result
const flatItems = {
  main: {
     children: ['1', '2']
  },
  '1': {
     children: ['3'],
     parent: 'main'
   },
  '2': {
     children: ['4', '5', '7'],
     parent: 'main'
   },
};

const treeItems = [
  {
    children: [
      {
        children: [...],
        id: '1',
        name: 'Child 1',
      },
      {children: [...], id: '2', name: 'Child 2'}
    ],
    id: 'main'
    name: 'Main'
  }
];

Because once we receive the items in the tree structure whether static or dynamic and we create an internal flat structure we need to reflect on the tree structure to return the changes so it can be saved, so I keep thinking that in this case instead of using the structure flat to move the nodes, we could use the tree directly, unless we find a way to simplify a modification to the tree using the flat structure that doesn't cost much, I have no idea how we could do that but we can explore.

Another thought about this is just accepting flat structures but I don't know how that would work in a composition environment that uses a tree structure, that way we wouldn't worry about modifying the tree since we'll have the flat structure but the problem with that is that we can have a lot of cons, maybe it doesn't work for static content or composition normally.

A second thought is perhaps to see a way that the flat structure helps us to reflect changes in the tree structure, perhaps during rendering of the <Collection/> component we can pass coordinates to the item, for example, the item level in the structure or something that helps us quickly access the item in the tree and move to another level, probably there should be some algorithm that helps us with this, I'll research more about it.

Regarding generating a uuid for each item, maybe it would not be necessary because for dynamic content it usually has id and as we need key to be declared explicitly or implicitly we have key as uuid inside the tree but if a tree is modified and the key has been generated that doesn't help much, but I think for dynamic content we can trust it to have id, at least looking at the structures we have in DXP it looks ok because we would have to know a way to preserve the uuid and know when to revalidate and that would be more problematic.