@jelbourn
Up until recent release, the SCSS files were shipped with the npm bundle.
We have are requirement for some heavy CSS restyling of the components to fit the company guideline. With some components it was not possible via class override, on those it was possible it looked terrible and unmaintainable, lots of css hacks.
We built a webpack loader that uses AST to visit all decorator styles properties and replace them with a recompiled SCSS. The SCSS got compiled after we changed some $variables and our SCSS file @import
ed the original material SCSS file of the component restyled.
It worked fine, but now we don't have access to the SCSS files through the npm package, we have to get the whole git as a submodule which is something I would rather not do.
Will you guys consider adding the SCSS files to the bundle?
+1
Same request here. We use the material2 components for all basic interaction elements. But there are some specifically styled elements in the app that make no sense to inherit from some material2 component.
But we want to achieve consistency in the design and all material of the app, so we use as much of the mixins like mat-elevation() in our own SCSS files.
Is there a way to extract mixins in the build process and ship a _mixins.scss with the npm bundle? To prevent deeplinking?
+1 overriding everything is not best practice
I chatted with Igor about this and ultimately we decided that the npm package exists to publish the build artifacts and that the scss files are considered source code. As such, GitHub would be the most appropriate place to get those source files for that level of customization in downstream apps.
@jelbourn @IgorMinar I understand the build is to publish artifacts. However, like bootstrap, overriding everything is not good design practice. When someone gives me a psd and says, "build this like the mockup," I will then have to override override override everywhere. My root level scss file is a global override directive. Furthermore, like Foundation (which I love), there may be portions of the css I have no interest and want to ex that out of the code base.
I would beg for you guys to perhaps think about this again and at least give the option because in a design sense it is difficult to surmise this as being best practice.
@jelbourn What about 3rd-party projects that just want to reuse the SCSS mixins? We're not customizing anything, but rather create our own components that we want to be inline with Angular Material. Reimplementing them would not be very DRY.
The argument about "source code" is a little weird for a project that uses TypeScript. It's like you published only JS files in the bundle because TS is source code and not an artifact.
@hansregeer mat-elevation()
is exposed in @angular/material/theming
as are ~85% of the other mixins
@willshowell mixins are ok/great but still provide bloat over settings and params
Very pity you don't ship scss variables within the npm bundle. I'm trying to create my own custom components that would look and feel like angular material, but in order to do that I have to redeclare a whole lot of scss variables.
Seems weird since you do export the Typescript declaration files.
It's a pity that this hasn't been revised.
For example, now I need to use the theme-defined colors in my app (I need to apply the warning color to a custom component).
Is this totally impossible (without redeclaring the variable in my scss files), or am I missing something?
... we decided that the npm package exists to publish the build artifacts and that the scss files are considered source code.
Except that the scss files are _not_ (or should not be) just source code. They contain information that is useful for integrating the components into an app, and for styling custom components to match, using the same mixins. They should be build
As such, GitHub would be the most appropriate place to get those source files for that level of customization in downstream apps.
If you don't want to include it into the main material2 npm, then why not bundle the scss into a separate npm so that it is relatively straightforward to integrate into an angular-cli build?
Taken from theme documentation page:
`@import '~@angular/material/theming';
// Plus imports for other components in your app.
// Include the common styles for Angular Material. We include this here so that you only
// have to load a single css file for Angular Material in your app.
// Be sure that you only ever include this mixin once!
@include mat-core();
// Define the palettes for your theme using the Material Design palettes available in palette.scss
// (imported above). For each palette, you can optionally specify a default, lighter, and darker
// hue. Available color palettes: https://material.io/design/color/
$candy-app-primary: mat-palette($mat-blue);
$candy-app-accent: mat-palette($mat-pink, A200, A100, A400);
// The warn palette is optional (defaults to red).
$candy-app-warn: mat-palette($mat-red);
// Create the theme object (a Sass map containing all of the palettes).
$candy-app-theme: mat-light-theme($candy-app-primary, $candy-app-accent, $candy-app-warn);
// Include theme styles for core and each component used in your app.
// Alternatively, you can import and @include the theme mixins for each component
// that you are using.
@include angular-material-theme($candy-app-theme);
`
At this point you have your custom theme with all colors set. From here you can define your app colors taken from the current palette by using map-get() scss function:
`$primary-color: map-get($candy-app-primary, A700);
$accent-color: map-get($candy-app-accent, 500);`
Default palettes have this structure:
$mat-blue: (
50: #e3f2fd,
100: #bbdefb,
200: #90caf9,
300: #64b5f6,
400: #42a5f5,
500: #2196f3,
600: #1e88e5,
700: #1976d2,
800: #1565c0,
900: #0d47a1,
A100: #82b1ff,
A200: #448aff,
A400: #2979ff,
A700: #2962ff
);
so, you can choose your colors from the theme colors. (I hope it is understandable)
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._
Most helpful comment
@jelbourn What about 3rd-party projects that just want to reuse the SCSS mixins? We're not customizing anything, but rather create our own components that we want to be inline with Angular Material. Reimplementing them would not be very DRY.
The argument about "source code" is a little weird for a project that uses TypeScript. It's like you published only JS files in the bundle because TS is source code and not an artifact.