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

fix(runtime-html): local dependencies for local element #1375

Merged
merged 11 commits into from
Apr 6, 2022

Conversation

Sayan751
Copy link
Member

@Sayan751 Sayan751 commented Mar 29, 2022

Pull Request

πŸ“– Description

It adds a flag for local element and for local elements falls back to parent container if the current container cannot find the resource.

🎫 Issues

Closes #1373

πŸ‘©β€πŸ’» Reviewer Notes

πŸ“‘ Test Plan

⏭ Next Steps

It adds a flag for local element and for local elements falls back to parent container if the current container cannot find the resource.

#1373
@Sayan751 Sayan751 requested a review from bigopon March 29, 2022 20:28
@codecov
Copy link

codecov bot commented Mar 29, 2022

Codecov Report

Merging #1375 (8ccfc64) into master (cf2909a) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master    #1375   +/-   ##
=======================================
  Coverage   87.89%   87.89%           
=======================================
  Files         171      171           
  Lines       14917    14925    +8     
  Branches     3207     3210    +3     
=======================================
+ Hits        13111    13119    +8     
  Misses       1806     1806           
Impacted Files Coverage Ξ”
packages/runtime-html/src/template-compiler.ts 98.35% <100.00%> (+0.02%) ⬆️

πŸ“£ Codecov can now indicate which changes are the most critical in Pull Requests. Learn more

@bigopon bigopon added this to the v2.0-beta milestone Mar 31, 2022
@bigopon
Copy link
Member

bigopon commented Apr 5, 2022

I think the fix looks appropriate, though it's a bit uncomfortable just to poke the parent container "randomly" like this. And the PR is lacking tests for spreading to local element, I just realized. I'll be having a look at this for a bit.

@bigopon
Copy link
Member

bigopon commented Apr 5, 2022

I think there's another interesting case: local element using owning element:

// my-element
<template as-custom-element="my-local-element">
  <my-element>
</template>

This is not covered at the moment. Do we support this?

@Sayan751
Copy link
Member Author

Sayan751 commented Apr 5, 2022

I think there's another interesting case: local element using owning element:

// my-element
<template as-custom-element="my-local-element">
  <my-element>
</template>

This is not covered at the moment. Do we support this?

Great catch! Need to avoid that. Thanks @bigopon.

@Sayan751
Copy link
Member Author

Sayan751 commented Apr 5, 2022

I think there's another interesting case: local element using owning element:

// my-element
<template as-custom-element="my-local-element">
  <my-element>
</template>

This is not covered at the moment. Do we support this?

@bigopon pushed a fix for this issue.

bit uncomfortable just to poke the parent container "randomly" like this

It is not "random" though. Either you register your custom elements globally (in which case the first attempt at finding the custom element will work) or you register the custom elements locally as dependencies of individual custom elements (I am referring to CustomElementDefinition#dependencies). So when dealing with local elements, it makes sense to fall back on the parent container to resolve/find the custom elements, because in that the parent container would that one from the parent custom element.

And the PR is lacking tests for spreading to local element

Can you please elaborate this part?

@bigopon
Copy link
Member

bigopon commented Apr 5, 2022

The "random" word might have been off. I wanted to express a concern related to relying on container hierarchy where it's not supposed to. Resources has a different semantic in the context of a container hierarchy. So walking to the parent, while being correct in this case, could set a trap that we may walk into later.

And the PR is lacking tests for spreading to local element

Can you please elaborate this part?

I was thinking that if it can recognizes custom element, then it should be able to compile a spread instruction against that custom element usages. Though the API is quite isolated and doesn't walk, so it's probably fine either way.

With regards to the issue, I think there could be another way to fix that may not require us to deal with uncertainty (as in in applications, there may be a custom template controller that adds a container into its hierarchy).

@bigopon
Copy link
Member

bigopon commented Apr 6, 2022

@Sayan751 I've pushed a commit, in which we build proper dependencies for local elements during the construction of their definitions/classes instead of delaying dependency retrieval until future. This is quite safe because the local element is in complete control of the template compiler, and not exposed anywhere.

A nice side effect of this is we can enable the use of owning element in the local element, without much hiccup.

let i = 0;
const ii = localElTypes.length;
for (; ii > i; ++i) {
(CustomElement.getDefinition(localElTypes[i]).dependencies as Key[]).push(
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! I have not though about that. Great solution. I thought that Container will complain about the duplicate registrations.

It makes sense to put/compute the deps array outside the loop as it is not dependent on the iterations of the loop.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

when we have more than 1 local element, it's ideal that all local elements can "see" each other. In order to have that, the local elements should have their dependencies built after the owning element has collected all the local elements. Though great poke, I didn't have a test for this case.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was referring to this part:

 ...context.def.dependencies ?? emptyArray,
 ...context.deps ?? emptyArray,

This can be extracted right before this loop (L1523), right?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ahh yes thanks, I thought there was only one loop, while I actually wrote this 2nd loop lol

`.trim();
@customElement({ name: 'my-app', template })
class App {
public prop = false;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think when you set this to true we will have a stack overflow. From that sense, it makes more sense for me to put the previous restriction in place.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there's an if to prevent that in the <my-le/>. I think it's an inherent "rule" that if there is a recursive call, it should be constrained.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exactly! That's why IMO we should never support this case and throw a compilation error, because my-le my-app will always fail.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It'll be quite unnatural if normal custom element can do that, and local element cannot. I think we can add a warning though, in dev mode.

@bigopon bigopon merged commit 0d48dbf into master Apr 6, 2022
@bigopon bigopon deleted the topic/local-template-dependency-issue branch April 6, 2022 07:45
@bigopon
Copy link
Member

bigopon commented Apr 6, 2022

Thanks @Sayan751 , the fix is in.

@Sayan751
Copy link
Member Author

Sayan751 commented Apr 6, 2022

Thanks @Sayan751 , the fix is in.

Thank you @bigopon for jumping in!!

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.

Custom elements do not appear in local templates.
2 participants