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
Ivy resource loader #24637
Ivy resource loader #24637
Conversation
Any reason not to use Angular's own HTTP implementation by default? |
@alfaproject That would mean that Core would depend on Common already depends on Core, this would be a cyclic dependancy. |
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.
Otherwise LGTM
* URL. Browser's `fetch` method is a good default implementation. | ||
*/ | ||
export function resolveComponentResources( | ||
resourceResolver: (url: string) => Promise<string|Response>): Promise<null> { |
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.
Angular does not currently have a dependency on fetch
, even via typings. It's not supported, for example, in IE < Edge.
What about removing Response
from our public API typings and instead using the signature: (url: string) => Promise<string | { text(): Promise<string> }>
. This fits fetch()
without introducing a dependency on DOM typings.
Also, Promise<void>
is the typical way of expressing that a function returns a Promise
that has no meaning other than its resolution.
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.
Good idea, done.
styleUrls && styleUrls.forEach((styleUrl) => { | ||
cachedResourceResolve(styleUrl).then((style) => { | ||
if (!component.styles) component.styles = []; | ||
component.styles.push(style); |
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.
This would reorder the styles according to response finish time rather than preserve the declared order, 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.
Good catch, fixed and added a test.
@@ -93,6 +93,27 @@ Did you run and wait for 'resolveComponentResources()'?`.trim()); | |||
expect(resourceFetchCount).toBe(1); | |||
})); | |||
|
|||
fit('should keep order even if the resolution is out of order', await(async() => { |
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.
fit
P.S.: Do you need await? Thought jasmine supports promises now
You can preview b48afdd at https://pr24637-b48afdd.ngbuilds.io/. |
You can preview 17c48ca at https://pr24637-17c48ca.ngbuilds.io/. |
Example: ``` it('...', await(async() => { doSomething(); await asyncFn(); doSomethingAfter(); })); ```
Used to resolve resource URLs on `@Component` when used with JIT compilation. ``` @component({ selector: 'my-comp', templateUrl: 'my-comp.html', // This requires asynchronous resolution }) class MyComponnent{ } // Calling `renderComponent` will fail because `MyComponent`'s `@Compenent.templateUrl` // needs to be resolved because `renderComponent` is synchronous process. // renderComponent(MyComponent); // Calling `resolveComponentResources` will resolve `@Compenent.templateUrl` into // `@Compenent.template`, which would allow `renderComponent` to proceed in synchronous manner. // Use browser's `fetch` function as the default resource resolution strategy. resolveComponentResources(fetch).then(() => { // After resolution all URLs have been converted into strings. renderComponent(MyComponent); }); ```
17c48ca
to
7ec241b
Compare
You can preview 7ec241b at https://pr24637-7ec241b.ngbuilds.io/. |
Used to resolve resource URLs on `@Component` when used with JIT compilation. ``` @component({ selector: 'my-comp', templateUrl: 'my-comp.html', // This requires asynchronous resolution }) class MyComponnent{ } // Calling `renderComponent` will fail because `MyComponent`'s `@Compenent.templateUrl` // needs to be resolved because `renderComponent` is synchronous process. // renderComponent(MyComponent); // Calling `resolveComponentResources` will resolve `@Compenent.templateUrl` into // `@Compenent.template`, which would allow `renderComponent` to proceed in synchronous manner. // Use browser's `fetch` function as the default resource resolution strategy. resolveComponentResources(fetch).then(() => { // After resolution all URLs have been converted into strings. renderComponent(MyComponent); }); ``` PR Close #24637
* ``` | ||
* | ||
*/ | ||
export function jasmineAwait(fn: () => Promise<any>): |
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.
FYI Jasmine 2.8 supports this natively
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 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.
Is the async/await support in jasmine(exposed in this PR) only for the Ivy compiler? Or does this support also apply to the current AOT/JIT compilers? Wasn't sure why this was under the Ivy context.
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 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.
Oh, the readme for 6.1 shows otherwise. Is the readme in error?
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.
@dman777 Oh man I was worried this ended up in 6.1 for a second. It has been reverted just before 6.1 was cut, so it has NOT been released. The changelog is generated automatically based on the conventional commits format, where apparently the revert commit hasn't cancelled the creation commit. So yes, the changelog is in error.
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.
Ok, thanks for the heads up. I hope this goes back in soon. Now that Jasmine is testing the DOM there can be race conditions that are hard to test for.
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
feat(ivy): Support resource resolution in JIT mode.
Used to resolve resource URLs on
@Component
when used with JIT compilation.