Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tag hierarchy #32

Merged
merged 18 commits into from
Apr 12, 2019
Merged

Tag hierarchy #32

merged 18 commits into from
Apr 12, 2019

Conversation

RvanderLaan
Copy link
Collaborator

@RvanderLaan RvanderLaan commented Mar 23, 2019

Closes #3 (sort of)
Replaces the list of tags with a tree of collections of tags.
The basic functionality works (adding/renaming/removing tags and collections).
Still todo:

  • Reordering using drag and drop ( Manually order tags #24 )
  • UI improvements (it doesn't fit after 3 or 4 nested collections)
  • Setting the initial name of tags and collections; currently they are initialized to 'New tag/collection'

@hummingly hummingly modified the milestone: Alpha v. 1.0 Mar 30, 2019
@RvanderLaan RvanderLaan changed the title WIP: Tag hierarchy Tag hierarchy Mar 31, 2019
@RvanderLaan
Copy link
Collaborator Author

This feature is finished (for the most part), so it can be merged.
The TagCollection has been added as a new entity, which contains sub-collections and tags.
The only things that I'm not entirely happy about is:

  1. The hierarchy of collections and tags passed into Blueprints Tree component is generated on the fly from the collections stored in the TagCollectionStore. Usually this hierarchy is stored in a state somewhere instead, but I had some doubts whether that would make sense in our case (more comments here).
  2. Collections can be dragged onto other collections to move them into that collection, but they cannot be dragged around to change their order as is possible with tags. I'm not sure how other applications achieve this while remaining intuitive to use

Remi van der Laan added 2 commits April 5, 2019 23:35
…t contains.

Checking whether a collection is selected is achieved with a @computed value, which might have some performance downsides, but works rather well
@RvanderLaan RvanderLaan mentioned this pull request Apr 11, 2019
@hummingly
Copy link
Collaborator

@RvanderLaan For some reason a lot of collections are permanently selected and the search has two search fields for tags.

@RvanderLaan
Copy link
Collaborator Author

Thanks for merging! I was just about to do that.
Yeah, I'll fix that. It marks collections as selected when all of its tags are selected, but apparently also when it has no tags. But I'm not really happy with the behavior of selecting items in the tree in general.
I can't find any examples where you can select multiple items in a tree, for both leaves and inner items.

The two search fields were supposed to be for including and excluding, I'll add proper labels to those

@hummingly
Copy link
Collaborator

Can we merge?

@RvanderLaan
Copy link
Collaborator Author

Yes! The honor is yours

@hummingly hummingly merged commit 989037c into master Apr 12, 2019
@hummingly hummingly deleted the tag-hierarchy branch April 12, 2019 21:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Implement proof of concept of tag relationships
2 participants