Using CSS Custom Properties To Theme Components In Angular 6.1.3

// Import the LESS CSS variables for our host-context declarations.
@import "./variables.less" ;

:host {
	display: block ;
	font-size: 18px ;
	min-height: 100vh ;
	padding: 1px 20px 1px 20px ;
}

:host-context( .light-theme ) {
	background-color: @light-background-color ;
	color: @light-color ;
}

:host-context( .dark-theme ) {
	background-color: @dark-background-color ;
	color: @dark-color ;
}

:host {
	background-color: var( --background-color ) ;
	color: var( --color ) ;
	display: block ;
	font-size: 18px ;
	min-height: 100vh ;
	padding: 1px 20px 1px 20px ;
}

// CAUTION: CSS Custom Properties (aka CSS variables) are not supported in IE. As such,
// we're going to be using PostCSS to inject fallback values for our dynamic properties
// during the "build step". In order to do this without duplicating the list of values
// in two different files, we're going to define an "IE FALLBACK" block below which will
// be parsed and used to define the "variables" collection.
// --
// NOTE: The "postcss-loader" can technically use the :root block to perform this
// variables look-up; however, that would require us to have a :root block. And, it would
// require that said :root block to be in all of the components that have CSS files. In
// this application, that makes no sense. Parsing an explicit block in the code makes
// way more sense.

// ----------------------------------------------------------------------------------- //
// ----------------------------------------------------------------------------------- //

// Define all the CSS custom properties for the Light Theme.
// --
// NOTE: These will be available in all descendant components.
:host( .light-theme ) {
	// === BEGIN IE FALLBACK ===
	--background-color: #ffffff ;
	--color: #333333 ;

	--canvas-background-color: #fafafa ;
	--canvas-color: #333333 ;
	--canvas-border-color: #cccccc ;
	--canvas-gutter-background-color: #e0e0e0 ;
	--canvas-gutter-color: #999999 ;

	--panel-background-color: #f0f0f0 ;
	--panel-color: #161616 ;
	--panel-input-background-color: #ffffff ;
	--panel-input-color: #333333 ;
	--panel-button-background-color: #e0e0e0 ;
	--panel-button-color: #121212 ;
	--panel-button-border-color: #666666 ;
	// === END IE FALLBACK ===
}

// Define all the CSS custom properties for the Dark Theme.
// --
// NOTE: These will be available in all descendant components.
:host( .dark-theme ) {
	--background-color: #121212 ;
	--color: #f0f0f0 ;

	--canvas-background-color: #282923 ;
	--canvas-color: #f8f8f2 ;
	--canvas-border-color: #42433f ;
	--canvas-gutter-background-color: #20211C ;
	--canvas-gutter-color: #999999 ;

	--panel-background-color: #20211C ;
	--panel-color: #999999 ;
	--panel-input-background-color: #2e2f28 ;
	--panel-input-color: #dadada ;
	--panel-button-background-color: #121212 ;
	--panel-button-color: #dadada ;
	--panel-button-border-color: #333333 ;
}

// ----------------------------------------------------------------------------------- //
// ----------------------------------------------------------------------------------- //

:host {
	background-color: var( --background-color ) ;
	color: var( --color ) ;
	display: block ;
	font-size: 18px ;
	min-height: 100vh ;
	padding: 1px 20px 1px 20px ;
}

.layout {
	margin: 0px auto 0px auto ;
	width: 650px ;

	&__header {}

	&__canvas {
		margin: 20px 0px 20px 0px ;
	}

	&__tools {
		display: flex ;
		margin-bottom: 20px ;
	}

	&__left-panel {
		flex: 1 1 50% ;
		margin-right: 30px ;
	}

	&__right-panel {
		flex: 1 1 50% ;
	}

	&__footer {
		// By default, we're going to HIDE the option to SWITCH THEMES. We'll only show
		// it once we know that we are in a browser that actually supports CSS custom
		// properties.
		display: none ;
		margin-bottom: 20px ;

		// If the CSS parser supports the assignment of a CSS custom property (the key
		// and value in this case doesn't matter), then it is safe to show the SWITCH
		// THEMES tooling to the user.
		@supports ( --foo: "bar" ) {
			display: block ;
		}
	}
}

a {
	cursor: pointer ;
	text-decoration: underline ;
	user-select: none ;
}

:host {
	display: block ;
}

.canvas {
	border: 3px solid var( --canvas-border-color ) ;
	border-radius: 4px 4px 4px 4px ;
	display: flex ;

	&__input {
		flex: 1 1 auto ;
	}

	&__syllables {
		flex: 0 1 70px ;
	}
}

.input {
	background-color: var( --canvas-background-color ) ;
	border: none ;
	color: var( --canvas-color ) ;
	font-size: 18px ;
	line-height: 25px ;
	padding: 10px 15px 10px 15px ;

	&:focus,
	&:active {
		outline: none ;
	}
}

.syllables {
	background-color: var( --canvas-gutter-background-color ) ;
	color: var( --canvas-gutter-color ) ;
	font-size: 18px ;
	font-weight: bold ;
	line-height: 25px ;
	list-style-type: none ;
	margin: 0px 0px 0px 0px ;
	min-height: 200px ;
	padding: 10px 0px 10px 0px ;
	text-align: center ;

	&__item {
		margin: 0px 0px 0px 0px ;
	}
}

color: var( --canvas-color ) ;

color: #333333 ;
color: var( --canvas-color ) ;

// Load the core node modules.
var fs = require( "fs" );
var HtmlWebpackPlugin = require( "html-webpack-plugin" );
var path = require( "path" );
var postcssPresetEnv = require( "postcss-preset-env" );
var webpack = require( "webpack" );

// ----------------------------------------------------------------------------------- //
// ----------------------------------------------------------------------------------- //

// IE11 (and earlier) doesn't support "CSS Custom Properties". As such, we're going to
// be using PostCSS to inject fallback values for our dynamic CSS properties. In order
// to not duplicate (and have to maintain) all of our CSS values, we're going to parse
// them right out of the root app component.
var ieFallbackVariables = (function() {

	// In this application, all of the CSS Custom Properties are defined in the root
	// component. Let's read that file into memory.
	var fileContent = fs.readFileSync(
		path.join( __dirname, "app", "app.component.less" ),
		"utf8"
	);

	// Now, let's break out the parts that are between the "IE FALLBACK" delimiters.
	var fallbackBlock = fileContent.match( /=== BEGIN IE FALLBACK ===[\s\S]+?=== END IE FALLBACK ===/ );
	var properties = Object.create( null );

	// If no fallback block was found, just return an empty object.
	if ( ! fallbackBlock ) {

		return( properties );

	}

	// We did fine a fallback block, so now we're going to iterate over it, looking for
	// strings in the form of, "--PROP_NAME : PROP_VALUE ;". These strings will be picked
	// apart and appended to the properties object.
	fallbackBlock.pop().replace(
		/--([^:\s]+)\s*:\s*([^;]+)/g,
		function ( $0, key, value ) {

			properties[ key ] = value.trim();

		}
	);

	return( properties );

})();

// ----------------------------------------------------------------------------------- //
// ----------------------------------------------------------------------------------- //

module.exports = {
	// I am going to generate 3 separate JavaScript files (that the HtmlWebpackPlugin
	// will automatically inject into my HTML template). Creating three files helps me
	// isolate the parts of the code that change often (my code) from the parts of the
	// code that change infrequently (the vendor code).
	entry: {
		polyfill: "./app/main.polyfill.ts",
		vendor: "./app/main.vendor.ts",
		main: "./app/main.ts"
	},
	// In normal development, I might use "[name].[chunkhash].js"; however, since this
	// is just getting committed to GitHub, I don't want to create a new hash-based file
	// for every file-save event. Instead, I can use the "hash" option in the
	// HtmlWebpackPlugin to help with cache-busting per build.
	output: {
		filename: "[name].js",
		path: path.join( __dirname, "build" )
	},
	resolve: {
		extensions: [ ".ts", ".js" ]
	},
	module: {
		rules: [
			{
				test: /\.ts$/,
				loaders: [
					// I compile the TypeScript content into ES5 JavaScript. In addition
					// to transpiling the code, it is also running type-checks based on
					// the tsconfig.json file.
					"ts-loader",
					// Given the transpiled code, I convert Template and Style URL
					// references into require() statements that will subsequently get
					// consumed by the raw-loader.
					// --
					// NOTE: Do not include the "keepUrl=true" that is in some examples;
					// that inlines the content, but does not replace the property name
					// used in the component meta-data.
					"angular2-template-loader"
				]
			},
			// When the "angualr2-template-loader" runs, it will replace the @Component()
			// "templateUrl" and "styleUrls" with inline "require()" calls. As such, we
			// need the raw-loader so that require() will know how to load .htm and .css
			// file as plain-text.
			{
				test: /\.(htm|css)$/,
				loader: "raw-loader"
			},
			// If our components link to .less files instead of .css files, then the
			// less-loader will parse the LESS CSS file on-the-fly during the require()
			// call that is generated by the "angular2-template-loader".
			{
				test: /\.less$/,
				loaders: [
					"raw-loader",
					// In between the raw file-read and the less-loader, we're going to
					// use PostCSS to clean-up the styling. Specifically, we're going to
					// have it inject fallback values for our "CSS Custom Properties" so
					// that browsers like IE11, which don't support custom properties,
					// won't completely break.
					// --
					// NOTE: PostCSS "preset" will also do other things by default, such
					// as apply the auto-prefixer plug-in.
					{
						loader: "postcss-loader",
						options: {
							ident: "postcss",
							plugins: [
								postcssPresetEnv({
									features: {
										"custom-properties": {
											variables: ieFallbackVariables
}
									}
								})
							]
						}
					},
					"less-loader"
				]
			}
		]
	},
	plugins: [
		// I move common references in the Entry files down into the lowest-common entry
		// file in this list.
		// --
		// CAUTION: The order of these chunk names has to be in the REVERSE order of the
		// order in which you intend to include them in the Browser. I believe, but am not
		// sure, that this is because common dependencies are moved to the next file down
		// in this list. So, if "main" and "vendor" have things in common, they will be
		// moved down to "vendor". Were the order reversed, with "vendor" above "main",
		// then common dependencies would be moved down to "main" (which is what we are
		// trying to avoid).
		new webpack.optimize.CommonsChunkPlugin({
			names: [
				"main",
				"vendor",
				"polyfill",
				// Extract the Webpack bootstrap logic into its own file by providing a
				// name that wasn't listed in the "entry" file list.
				// --
				// NOTE: I don't really need this for my kind of GitHub based development;
				// but, this seems to be a common pattern as it moves frequently changing
				// code out of the "vendor" file.
				"manifest"
			]
		}),
		// I generate the main "index" file and inject Script tags for the files emitted
		// by the compilation process.
		new HtmlWebpackPlugin({
			// Notice that we are saving the index UP ONE DIRECTORY, so that it is output
			// in the root of the demo.
			filename: "../index.htm",
			template: "./app/main.htm",

			// This will append a unique query-string hash (for cache busting) to the
			// injected files after each build. All files get the same hash, which makes
			// this DIFFERENT from using the "chunkhash" in the "output" config.
			hash: true
		}),
		// I compact the JavaScript content.
		new webpack.optimize.UglifyJsPlugin({
			mangle: {
				keep_fnames: true,
				keep_classnames: true
			}
		})
	]
};

.layout {
	// ....
	&__footer {
		// By default, we're going to HIDE the option to SWITCH THEMES. We'll only show
		// it once we know that we are in a browser that actually supports CSS custom
		// properties.
		display: none ;
		margin-bottom: 20px ;

		// If the CSS parser supports the assignment of a CSS custom property (the key
		// and value in this case doesn't matter), then it is safe to show the SWITCH
		// THEMES tooling to the user.
		@supports ( --foo: "bar" ) {
			display: block ;
		}
	}
}