-
-
Notifications
You must be signed in to change notification settings - Fork 150
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
Conversation
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
Codecov Report
@@ 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
π£ Codecov can now indicate which changes are the most critical in Pull Requests. Learn more |
β¦al dependencies
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. |
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. |
@bigopon pushed a fix for this issue.
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
Can you please elaborate this part? |
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.
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). |
β¦c/local-template-dependency-issue
@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( |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added another test to assert the behavior/expectation here https://github.com/aurelia/aurelia/pull/1375/files#diff-24a8cd6d83b4df0282eacd3f1df4c95ee8e4a93d84c42d527604802a7b6f0e20R2252
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
β¦c/local-template-dependency-issue
Thanks @Sayan751 , the fix is in. |
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