Yeah, this is a bug. In general, I think the id creation logic across all individual components will probably suffer from the same defect. A safer idea is to prefix with the root id itself.

A PR would be welcome!

Yeah, I'd love to contribute to your awesome lib :>

@Nogias9x this is not a bug. If you check in your sandbox, you're assigning custom id to nodes in your data json. Since all instances are using the same demo data, they all get the same id.

I removed id nodes from your data and as you can see, you get unique ids across instances

The same goes for tags.

Yes you are right @mrchief . But I think the .id should be reserved by the list items. For example, if the select is list of job positions, the .id should be position.id which is fetching from database.

When you say it should be “xyz”, you’re unconsciously transitioning into business domain. To avoid being sandboxed into such decisions, the component lets you decide and shape that piece of information. E.g , you could assign the id to be that “xyz” that you need and the component will reflect that.

Another person could then use “abc” to be the id and the same component can serve both.

My PR is again a generic solution as we support the use case of having multiple instances and it makes sense semantically to have unique ids in the dom.

If you’re using id field to store some data, then you don’t need to do so as you can very well pass any arbitrary prop to node and it’ll bubble it back on change events.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.