honeymoose
/
angular-cn
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
angular-cn/packages/platform-server/src/styles_host.ts

35 lines
1.1 KiB
TypeScript
Raw Normal View History

fix(platform-server): render styles in app component instead of <head> This ensures when the tree is serialized to the client and the app is later bootstrapped, the <style> tags created during server-side rendering are destroyed.
2017-02-14 14:34:05 -05:00
/**
* @license
* Copyright Google Inc. All Rights Reserved.
*
* Use of this source code is governed by an MIT-style license that can be
* found in the LICENSE file at https://angular.io/license
*/
refactor(core): tree-shake application_module providers (#23477) PR Close #23477
2018-04-23 13:47:27 -04:00
import {Inject, Injectable, Optional} from '@angular/core';
feat(platform-server): provide a DOM implementation on the server Fixes #14638 Uses Domino - https://github.com/fgnass/domino and removes dependency on Parse5. The DOCUMENT and nativeElement were never typed earlier and were different on the browser(DOM nodes) and the server(Parse5 nodes). With this change, platform-server also exposes a DOCUMENT and nativeElement that is closer to the client. If you were relying on nativeElement on the server, you would have to change your code to use the DOM API now instead of Parse5 AST API. Removes the need to add services for each and every Document manipulation like Title/Meta etc. This does *not* provide a global variable 'document' or 'window' on the server. You still have to inject DOCUMENT to get the document backing the current platform server instance.
2017-08-08 05:17:40 -04:00
import {DOCUMENT, ɵDomAdapter as DomAdapter, ɵSharedStylesHost as SharedStylesHost, ɵTRANSITION_ID, ɵgetDOM as getDOM} from '@angular/platform-browser';
fix(platform-server): render styles in app component instead of <head> This ensures when the tree is serialized to the client and the app is later bootstrapped, the <style> tags created during server-side rendering are destroyed.
2017-02-14 14:34:05 -05:00
@Injectable()
export class ServerStylesHost extends SharedStylesHost {
fix: app ids for better <style> management for ssr (#14632) Currently styles are rendered to the root component element, which ensures they're cleaned up automatically when the client application is bootstrapped. This is less than ideal as progressive rendering can cause HTML to be rendered before the CSS is loaded, causing flicker. This change returns to rendering <style> elements in the <head>, and introduces a mechanism for removing them on client bootstrap. This relies on associating the server and client bootstrap. Another way to think of this is that the client, when bootstrapping an app, needs to know whether to expect a server rendered application exists on the page, and to identify the <style> elements that are part of that app in order to remove them. This is accomplished by providing a string TRANSITION_ID on both server and client. For most applications, this will be achieved by writing a client app module that imports BrowserModule.withServerTransition({appId: <id>}). The server app module will import this client app module and therefore inherit the provider for TRANSITION_ID. renderModule[Factory] on the server will validate that a TRANSITION_ID has been provided.
2017-02-22 19:06:21 -05:00
private head: any = null;
fix(platform-server): render styles in app component instead of <head> This ensures when the tree is serialized to the client and the app is later bootstrapped, the <style> tags created during server-side rendering are destroyed.
2017-02-14 14:34:05 -05:00
fix: app ids for better <style> management for ssr (#14632) Currently styles are rendered to the root component element, which ensures they're cleaned up automatically when the client application is bootstrapped. This is less than ideal as progressive rendering can cause HTML to be rendered before the CSS is loaded, causing flicker. This change returns to rendering <style> elements in the <head>, and introduces a mechanism for removing them on client bootstrap. This relies on associating the server and client bootstrap. Another way to think of this is that the client, when bootstrapping an app, needs to know whether to expect a server rendered application exists on the page, and to identify the <style> elements that are part of that app in order to remove them. This is accomplished by providing a string TRANSITION_ID on both server and client. For most applications, this will be achieved by writing a client app module that imports BrowserModule.withServerTransition({appId: <id>}). The server app module will import this client app module and therefore inherit the provider for TRANSITION_ID. renderModule[Factory] on the server will validate that a TRANSITION_ID has been provided.
2017-02-22 19:06:21 -05:00
constructor(
@Inject(DOCUMENT) private doc: any,
@Optional() @Inject(ɵTRANSITION_ID) private transitionId: string) {
super();
this.head = getDOM().getElementsByTagName(doc, 'head')[0];
}
fix(platform-server): render styles in app component instead of <head> This ensures when the tree is serialized to the client and the app is later bootstrapped, the <style> tags created during server-side rendering are destroyed.
2017-02-14 14:34:05 -05:00
private _addStyle(style: string): void {
feat(platform-server): provide a DOM implementation on the server Fixes #14638 Uses Domino - https://github.com/fgnass/domino and removes dependency on Parse5. The DOCUMENT and nativeElement were never typed earlier and were different on the browser(DOM nodes) and the server(Parse5 nodes). With this change, platform-server also exposes a DOCUMENT and nativeElement that is closer to the client. If you were relying on nativeElement on the server, you would have to change your code to use the DOM API now instead of Parse5 AST API. Removes the need to add services for each and every Document manipulation like Title/Meta etc. This does *not* provide a global variable 'document' or 'window' on the server. You still have to inject DOCUMENT to get the document backing the current platform server instance.
2017-08-08 05:17:40 -04:00
let adapter = getDOM();
fix(platform-server): render styles in app component instead of <head> This ensures when the tree is serialized to the client and the app is later bootstrapped, the <style> tags created during server-side rendering are destroyed.
2017-02-14 14:34:05 -05:00
const el = adapter.createElement('style');
adapter.setText(el, style);
fix: app ids for better <style> management for ssr (#14632) Currently styles are rendered to the root component element, which ensures they're cleaned up automatically when the client application is bootstrapped. This is less than ideal as progressive rendering can cause HTML to be rendered before the CSS is loaded, causing flicker. This change returns to rendering <style> elements in the <head>, and introduces a mechanism for removing them on client bootstrap. This relies on associating the server and client bootstrap. Another way to think of this is that the client, when bootstrapping an app, needs to know whether to expect a server rendered application exists on the page, and to identify the <style> elements that are part of that app in order to remove them. This is accomplished by providing a string TRANSITION_ID on both server and client. For most applications, this will be achieved by writing a client app module that imports BrowserModule.withServerTransition({appId: <id>}). The server app module will import this client app module and therefore inherit the provider for TRANSITION_ID. renderModule[Factory] on the server will validate that a TRANSITION_ID has been provided.
2017-02-22 19:06:21 -05:00
if (!!this.transitionId) {
adapter.setAttribute(el, 'ng-transition', this.transitionId);
fix(platform-server): render styles in app component instead of <head> This ensures when the tree is serialized to the client and the app is later bootstrapped, the <style> tags created during server-side rendering are destroyed.
2017-02-14 14:34:05 -05:00
}
fix: app ids for better <style> management for ssr (#14632) Currently styles are rendered to the root component element, which ensures they're cleaned up automatically when the client application is bootstrapped. This is less than ideal as progressive rendering can cause HTML to be rendered before the CSS is loaded, causing flicker. This change returns to rendering <style> elements in the <head>, and introduces a mechanism for removing them on client bootstrap. This relies on associating the server and client bootstrap. Another way to think of this is that the client, when bootstrapping an app, needs to know whether to expect a server rendered application exists on the page, and to identify the <style> elements that are part of that app in order to remove them. This is accomplished by providing a string TRANSITION_ID on both server and client. For most applications, this will be achieved by writing a client app module that imports BrowserModule.withServerTransition({appId: <id>}). The server app module will import this client app module and therefore inherit the provider for TRANSITION_ID. renderModule[Factory] on the server will validate that a TRANSITION_ID has been provided.
2017-02-22 19:06:21 -05:00
adapter.appendChild(this.head, el);
fix(platform-server): render styles in app component instead of <head> This ensures when the tree is serialized to the client and the app is later bootstrapped, the <style> tags created during server-side rendering are destroyed.
2017-02-14 14:34:05 -05:00
}
fix: app ids for better <style> management for ssr (#14632) Currently styles are rendered to the root component element, which ensures they're cleaned up automatically when the client application is bootstrapped. This is less than ideal as progressive rendering can cause HTML to be rendered before the CSS is loaded, causing flicker. This change returns to rendering <style> elements in the <head>, and introduces a mechanism for removing them on client bootstrap. This relies on associating the server and client bootstrap. Another way to think of this is that the client, when bootstrapping an app, needs to know whether to expect a server rendered application exists on the page, and to identify the <style> elements that are part of that app in order to remove them. This is accomplished by providing a string TRANSITION_ID on both server and client. For most applications, this will be achieved by writing a client app module that imports BrowserModule.withServerTransition({appId: <id>}). The server app module will import this client app module and therefore inherit the provider for TRANSITION_ID. renderModule[Factory] on the server will validate that a TRANSITION_ID has been provided.
2017-02-22 19:06:21 -05:00
onStylesAdded(additions: Set<string>) { additions.forEach(style => this._addStyle(style)); }
fix(platform-server): render styles in app component instead of <head> This ensures when the tree is serialized to the client and the app is later bootstrapped, the <style> tags created during server-side rendering are destroyed.
2017-02-14 14:34:05 -05:00
}