Can't set an id to a widget through setupDragIn
Subject of the issue
I rely deeply on grid stack IDs (gs-id), I need a way to track the widgets
Your environment
- gridstack version: v7.2.3
Steps to reproduce
Here is my helper function:
GridStack.setupDragIn('.gridstack-add-widget', {
appendTo: '.gridstack-widget-dragged',
helper: function (event: Partial<DragEvent>) {
const id = nanoid();
// ...
// some code to store metadata of a widget based on its id
// ...
const target = event.target as GridItemHTMLElement;
const clone = Utils.cloneNode(target.parentElement!);
clone.setAttribute('gs-id', id);
return clone;
},
});
Expected behavior
I expect to set an id with GridStack.setupDragIn function
actually I spent an hour yesterday on this... and got it working in few minutes this morning after a good night sleep
GridStack.setupDragIn('.gridstack-add-widget', {
appendTo: '.gridstack-widget-dragged',
helper: function (event: Partial<DragEvent>) {
const id = nanoid();
const target = event.target as GridItemHTMLElement;
const correctTarget = target.parentElement!.classList.contains('grid-stack-item-content') ? target.parentElement!.parentElement! : target.parentElement!;
correctTarget.setAttribute('gs-id', id);
const clone = Utils.cloneNode(correctTarget);
return clone;
},
});
would you know why the code above works but this one does not
GridStack.setupDragIn('.gridstack-add-widget', {
appendTo: '.gridstack-widget-dragged',
helper: function (event: Partial<DragEvent>) {
const id = nanoid();
const target = event.target as GridItemHTMLElement;
const correctTarget = target.parentElement!.classList.contains('grid-stack-item-content') ? target.parentElement!.parentElement! : target.parentElement!;
const clone = Utils.cloneNode(correctTarget);
clone.setAttribute('gs-id', id); // set attribute on cloned element
return clone;
},
});
when I set the attribute gs-id after creating the clone (which seems cleaner isn't it? The id does not get added
actually if you care about id (as you should) set the initial gs-id (or id optoin when creating from json) and NOT when the drag happen. the node gs-is is ONLY the dom used for layout. the internal node.id is what is used during actual code collision...
and next time please post a slack question - this isn't a lib bug per say, so others can search/respond.
I didn't understand :/ Let me give more details on the use case:
- I have a grid that has been created via JSON, each tiles has IDs
- I drag a tile that is outside of the grid into the grid
- the tile gets added with an ID I chose. Choosing the ID beforehand is handy because I manage in parallel a datastructure where I associate Ids with tile types and other metadata
my current implementation:
- I use setupDragIn helper. the helper :
- sets a gs-id to the dom element that is outside gridstack
- sets the gs-id into an external datastructure with some metadata
- returns a cloned element
- I receive an event .on('added')
- I use the id to get my metadata
- I do my magic to render my component as I want to
Setting the id and removing the className from the cloned element does not work for me, that's why I clone the element after. It works
Two issues I have to calm my inner asperger alterego with:
- the class used to make the external widget draggable by gridstack is copied over to the item added into the grid
- a gs-id is set on my external widget, but it's changed everytime I drag/drop it again
@adumesny I tried to connect to slack. But I couldn't, I'm getting the same issue as https://github.com/gridstack/gridstack.js/issues/2230
Update: I was able to join the slack channel. I opened https://github.com/gridstack/gridstack.js/pull/2233
don't have time to read this now... re-opening so I can check later.
Update: demo/two.html now shows issue.
ok, I've taken the time to take a look... the clone should be used for creating the constrain (agree it's cleaner to set on clone rather than original master item) and it should also insert that content as is (with some check for required .grid-stack-item + .grid-stack-item-content)
won't be small change and might break some user who were working around the issue... related to #1840