Expose Component Render Tree Iterator for Component Manager #1155
Conversation
| * Pro: Allows for more reactive as well as lazy consume/provide patterns | ||
| * Pro: Allows for context use in Helpers and Modifiers without API change | ||
| * Con: Requires a much larger change to internals | ||
| * Con: Does not give public API for things like dev tools that wish to inspect component tree |
There was a problem hiding this comment.
There isn't enough information over there to make this claim.
Was this written with ai?
There was a problem hiding this comment.
No this was my understanding. The scope RFC as you have written does not give an injection point for dev tools or other tooling to inspect or assert on the tree.
I need to make a better example of what I have in mind for dev tools and make this to be less absolute
There was a problem hiding this comment.
Updated and removed this one sentence.
This is roughly the equivalent of the SelectOptionManager assertion/warnings using scope:
class ComponentTreePath {
node: ComponentLike<any>;
parentPath: ComponentTreePath | null;
constructor(node, parentPath) {
this.node = node;
this.parentPath = parentPath;
}
find(predicate: (node: ComponentLike<any>) => boolean): ComponentTreePath | null {
let current: ComponentTreePath | null = this;
while (current) {
if (predicate(current.node)) {
return current.node;
}
current = current.parentPath;
}
return null;
}
}
getComponentTreeFromScope() {
const scope = getScope();
return scope.entries.find(x => x instanceof ComponentTreePath);
}
setComponentTree(c: ComponentLike<any>) {
const scope = getScope();
const parentPath = this.getComponentTreeFromScope();
const newPath = new ComponentTreePath(c, parentPath);
addToScope(newPath);
}
class DebugComponentManager extends EmberGlimmerComponentManager {
createComponent(ComponentClass, args) {
const newComponent = super.createComponent(...arguments);
setComponentTree(newComponent);
return newComponent;
}
}
setComponentManager(DebugComponentManager, GlimmerComponent);
// How to Implement my SelectOptionManager
class SelectOptionManager extends BaseComponentManager {
createComponent(ComponentClass, args, stack) {
const stack = getComponentTreeFromScope()
if (stack.find(a => a instanceof Select)) {
return super.createComponent(...arguments);
}
assert('SelectOption must be used within a Select component', false);
}
}
setComponentManager(
(owner) => new SelectOptionManager(owner),
SelectOption
);I would note that in this implementation... Scope gets very large and dirtied in a way that impacts main app performance
There was a problem hiding this comment.
but scope is attached to the tree, you don't need to manage that
| * Pro: Allows for more than context lookup in MANY use cases | ||
| * Pro: Allows for more reactive as well as lazy consume/provide patterns | ||
| * Pro: Allows for context use in Helpers and Modifiers without API change | ||
| * Con: Requires a much larger change to internals |
| // ... | ||
| } | ||
|
|
||
| if (isDeveloping()) { |
There was a problem hiding this comment.
DOM-context solves this case, yea?
There was a problem hiding this comment.
If parent nodes do not have elements it does not and would mean that debug tooling such as this would rely on context landing.
This is saying that the component tree in managers is valuable separate from the context discussion and is a different usecase for this sort of information
2 participants
Propose - Expose Component Render Tree Iterator for Component Manager
Rendered
Summary
This pull request is proposing a new RFC.
To succeed, it will need to pass into the Exploring Stage, followed by the Accepted Stage.
A Proposed or Exploring RFC may also move to the Closed Stage if it is withdrawn by the author or if it is rejected by the Ember team. This requires an "FCP to Close" period.
An FCP is required before merging this PR to advance to Accepted.
Upon merging this PR, automation will open a draft PR for this RFC to move to the Ready for Released Stage.
Exploring Stage Description
This stage is entered when the Ember team believes the concept described in the RFC should be pursued, but the RFC may still need some more work, discussion, answers to open questions, and/or a champion before it can move to the next stage.
An RFC is moved into Exploring with consensus of the relevant teams. The relevant team expects to spend time helping to refine the proposal. The RFC remains a PR and will have an
Exploringlabel applied.An Exploring RFC that is successfully completed can move to Accepted with an FCP is required as in the existing process. It may also be moved to Closed with an FCP.
Accepted Stage Description
To move into the "accepted stage" the RFC must have complete prose and have successfully passed through an "FCP to Accept" period in which the community has weighed in and consensus has been achieved on the direction. The relevant teams believe that the proposal is well-specified and ready for implementation. The RFC has a champion within one of the relevant teams.
If there are unanswered questions, we have outlined them and expect that they will be answered before Ready for Release.
When the RFC is accepted, the PR will be merged, and automation will open a new PR to move the RFC to the Ready for Release stage. That PR should be used to track implementation progress and gain consensus to move to the next stage.
Checklist to move to Exploring
S-Proposedis removed from the PR and the labelS-Exploringis added.Checklist to move to Accepted
Final Comment Periodlabel has been added to start the FCP