Template-in-template: reimplement the feature
Closed this issue · 3 comments
Currently the feature is implemented asynchronously. It uses two unrelated features-maps and JS call.
We have issues with using two maps : the node becomes attached, detached and attached which is not expected.
We have very serious issues with implementing the feature via JS (call order on the server side and async nature of the code).
So we should not use JS at all for any tree node related features.
The proposition is too use only one dedicated NodeFeature for this feature which makes the node immediately available and handled on the same way as any other node on the client side.
Except that on the client side such nodes requires a special handling.
For all such virtual children features we should use one NodeFeature but introduce a subnamespaces into it.
See details in #2826.
It's very similar to #3057. But it has it's own logic of addressing the element on the client-side.
Earlier to today, you were talking about wrapping the nodes in VirtualChildrenList with something that contains metadata about how each specific child should be handled (e.g. for component renderer, template-in-template or @Id). One alternative that might be slightly less complex compared to a wrapper could be to introduce an additional field in the ElementData namespace that can contain a marker for what kind of type it is and any additional metadata that it needs?
It would be good to reuse ElementData or any other existing NodeFeature but I don't think it's less complex.
The ElementData is a subclass of NodeValue which carries only one value, not a number of values. So it's not based on the HashMap and it has been done intentionally.
To be able to reuse it we should modify it to support multiple values and either it should be turned to NodeMap (so it will increase memory consumption : the main reason why it's NodeValue at the moment) or some another way for this specific case of limited additional payload values is needed. In the result I think it won't be less complex unfortunately.
Actually after some attempts to reduce a number of features I've realized that I need one NodeFeature instead of three which will be able to behave like ElementData but carry 3 values instead of one.
And since we already have and use the ElementData I'm going to modify it and reuse.
It will allow to reduce a number of features and a need of interim StateNode.