Arbitrary composition of pre-allocated components #3694
-
|
Hi! I have a use case for a tree editor and want to know if there are known patterns in Lit that allows for what I'll be describing. I have a database with a lot of data fragments (simple key-value pairs + some metadata). Each fragment holds a flat list of references to other fragments, which are semantically nested, and since all fragments have the same model, this forms a recursive structure. As the aggregate document that will be formed by fetching some N levels of data is highly dynamic, it is obviously impossible to determine its structure beforehand. The way I'm thinking about rendering such trees is to pre-allocate a flat collection of cotainers (custom elements) and then, upon resolving the inbound data, iteratively populate these containers and compose them in a nested layout. Each container should offer a This would be straightfoward if I was only rendering a flat list layout, but since it's a tree layout, I'm uncertain about how to reference a container element (which would be sitting at the root of the app node) in some arbitrary container in some arbitrary nesting level, arbitraly many times. It's important to note that each data fragment already has a unique ID in the database, so this identifier is integral to the mechanics. The main question is, is this feasible with pure custom elements? If so, how can this be done with Lit? I really wish to avoid coding my own framework 😅 |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
|
Well, it is just a tree component. The data seems to be organized more like a Graph. But you can try reflecting it in a tree. So it is all about the logic of your component and data you feed to it. Seem like a generic You might be overthinking reusing containers. What is the purpose of that? Just create a duplicate so potential circular endless nesting would happen. But such examples already exist. Take Chrome Dev Tools and console there. But you would need to manually create a circle nested tree. And observe how Dev Tools handles that.
Lit itself is a general library so it won't have ready to use solutions for that. Just look for tree web components and see which one would work for you https://learn.microsoft.com/en-us/fluent-ui/web-components/components/tree-view?pivots=typescript |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I was overthinking the reuse of components since I was biased by the backing data structure, which is flattened and make heavy use of references. While exploring Lit and Web Components, I realized that slot members show in the console as a sort of referenced node, apparently not living within the shadow dom, so this gave me the impression that the browser itself could handle multiple instantiations of the same container transparently, but I ended up figuring that this is not the case and I must deal with multiple instantiations at the application level state. Nevertheless, how frigging amazing it would be for that to be the case! Just creating a single container, giving it an ID and referencing it anywhere in other components letting the browser handle reactivity in a much more performant way than doing it via scripts. A man can dream... |
Beta Was this translation helpful? Give feedback.
Well, it is just a tree component. The data seems to be organized more like a Graph. But you can try reflecting it in a tree. So it is all about the logic of your component and data you feed to it. Seem like a generic
<tree-node>component you can feed a chunk of data.You might be overthinking reusing containers. What is the purpose of that? Just create a duplicate so potential circular endless nesting would happen. But such examples already exist. Take Chrome Dev Tools and console there. But you would need to manually create a circle nested tree. And observe how Dev Tools handles that.
Lit itself is a general library so it won't have ready to use solutions for that. Just look for tree …