Q-tree within Q-menu
Yes it works on my phone. I agree it should be simpler!
metalsadman last edited by metalsadman
It would help if you show some working code. Obviously not all use case are covered since it varies for each. the use case isn’t simple either.
If you think there’s something missing on the component or its api that would help you, then it would help to make a feature request about it so that it can be improved if said feature is deemed logical to be added.
Anyway, what I needed was a Select component that would show a tree-view in the drop-down, and support autofill with items from any level of the tree.
I don’t know if this is a general enough need to warrant building it into Quasar, but I intend to use it in many places in my app. I have it working well now, though needed to use a few kludgy techniques to get there.
If you’re interested, I can provide the complete code here.
qyloxe last edited by
@metalsadman yeah, you’re obviously right: it needs specification. It is not a problem I need to solve just now, but it is an interesting case, and I always assumed that at some point of its way, Quasar will need an abstraction of “compound components”.
We have something similar already - as in q-page or q-card, which are examples of compound components. Now, in this use case, OP encountered a need for overlayed, sibling information exchange, shared state component. His implementation in the context of framework provided abstractions, ended up complicated and not obvious.
Maybe it’s about time to create a new abstraction in Quasar ie q-compound or q-overlayed which allows to build something like that?
I think it is an excellent example, where app extensions are too heavy. If you wanted to build such light user-space and app-specific components as an AE, then this AE would be hard to maintain, debug, big and error prone.
The needed q-compound should:
- take care of events propagated and emitted
- work in overlays / popups
- support “decorator” interfaces (animations, transitions for example)
- … and more?
The actual code which OP used, is not elegant. I consider, that when framework forces you to write “not elegant” code, it is a strong sign of lacking abstractions in said framework. And Quasar is highly elegant. This is just a new use case which needs new abstraction.
Honestly just a bunch of thoughts, hoping this would start a fruitful discussion.
@qyloxe Interesting discussion. Probably out of my depth on this. I’m just hacking up something that meets my UX needs. The original title of this post re: ‘tree within a menu’ doesn’t really reflect my starting point… Maybe I should have titled it ‘Challenges making a Select component that supports tree-structured options list’. If there was a native Quasar Select component that did that, I wouldn’t need to add a menu and a button and a bunch of styles and methods to make the whole mess look and behave like a regular Select box.
I personally feel this component should be part of the framework.
It is very hard to avoid tree structures. Everybody wants categories and folders I find. So we will all start building our own tree select eventually and not very elegantly (or at least most of us).
I just posted a feature request for this…
Just added my code and description of how it works to the feature request post above
dobbel last edited by dobbel
@turigeza you could see this as a tree select: its’a tree and you can select.
Combine it with the filter example and you have the functionality of a q-select with a tree.
CWoodman last edited by CWoodman
@dobbel Yes, that’s what I did.
See my code at https://forum.quasar-framework.org/topic/6639/requested-feature-select-with-tree-structured-options