Skip to content

Conversation

@vicb
Copy link
Contributor

@vicb vicb commented Jun 10, 2015

@mhevery When styles: [] are specified on the @View, they will be handled by the shadow DOM strategy (@import are inlined, selector are re-written).

Ultimately when styles will be populated during the build phase, there will be no need to transform the styles (already transformed).

  • Is this ok to transform them for now or should we already switch to the end strategy ?
  • Do we really need styles: List or style: string is ok ? (concatenation could also happen at build time) ?

TODO:

Copy link
Contributor

Choose a reason for hiding this comment

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

let i and facade isString

@tbosch
Copy link
Contributor

tbosch commented Jun 11, 2015

I think there are 2 independent things here:

  1. load and inline styles: they can come either from styles/stylesUrl annotation or be embedded in the template
  2. adjust the styles for shadow dom emulation
  1. needs to be done independently of the shadow dom emulation: We don't inline for native shadow DOM right now, but we should, as otherwise view instantiation gets asynchronous (we would need to wait for the <style href="..."> elements have been loaded (see Wait for included css to be fully loaded before instantiating a component / finishing the compilation #1694). This needs to happen before any compile step. I would vote for letting the TemplateLoader do this already, so a build step that inlines the template would automatically also inline the styles.

  2. is depending on the shadow dom emulation emulation and can assume that styles are already inline in the template as a <style> element. I.e. this can be a regular compile step.

A side effect of this would be that the CompileStepFactory no longer needs subTaskPromises, as they were only used by the compile step that inlines styles. Also, ShadowDomStrategy.processStyleElement would always be synchronous as it would not do any loading.

@vicb Could you change the code accordingly?

@vicb
Copy link
Contributor Author

vicb commented Jun 11, 2015

This needs to happen before any compile step

Why ?
I think we can parallelize compilation & css loading / inlining, what would be wrong with that ?

TemplateLoader

Should we rename it to ViewLoader now and have loadTemplate and loadStyles methods ?

  1. Not sure to get why we need to delay the compilation ? Could this be updated in a second step.

May be we should chat today to clarify this ?

@tbosch
Copy link
Contributor

tbosch commented Jun 11, 2015

talked to @mhevery: Please inline first and then start the compile process. This is ok for production as in that case we would inline the html and styles in a build step so there would be no xhrs.

@vicb
Copy link
Contributor Author

vicb commented Jun 11, 2015

Thanks for the feedback, I'll update tomorrow.

@tbosch tbosch mentioned this pull request Jun 11, 2015
@vicb vicb changed the title [WIP] feat(View): add support for styleUrls feat(View): add support for styleUrls Jun 12, 2015
@vicb
Copy link
Contributor Author

vicb commented Jun 12, 2015

@tbosch could you please review this PR ?

Currently I have implemented what we've discussed yesterday: move the styles from the annotation inside the template before the compilation.

In order to keep the PR reviewable, I'll address the remaining stuff (see TODO in the description above) as separate PRs.

@vicb vicb added action: review The PR is still awaiting reviews from at least one requested reviewer and removed state: WIP labels Jun 12, 2015
@vicb vicb force-pushed the 0609-cssUrls branch 4 times, most recently from d2137ed to 5632d92 Compare June 12, 2015 17:10
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe 'TODO: remove PromiseWrapper.reject and throw directly'?

Copy link
Contributor

Choose a reason for hiding this comment

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

Never mind...

@tbosch
Copy link
Contributor

tbosch commented Jun 15, 2015

Looks good. Please add link to the PR that will make ShadowDom strategy sync.
And please add fixes #1694 to the last commit as well.

@tbosch tbosch added pr_state: LGTM action: cleanup The PR is in need of cleanup, either due to needing a rebase or in response to comments from reviews labels Jun 15, 2015
@tbosch
Copy link
Contributor

tbosch commented Jun 15, 2015

Needs rebase though...

@vicb
Copy link
Contributor Author

vicb commented Jun 15, 2015

@tbosch #1694 will be fixed as part of the next PR (strategies are still async in this one)

@vicb
Copy link
Contributor Author

vicb commented Jun 15, 2015

landed as ac3e624 + previous commits

@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 6, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

action: cleanup The PR is in need of cleanup, either due to needing a rebase or in response to comments from reviews action: review The PR is still awaiting reviews from at least one requested reviewer cla: yes feature Issue that requests a new feature

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants