I was checking bundle sizes in a production build generated by a ng-cli based project. There are a couple of third-party NPM packages defining some angular 2 components and in their CSS styles they embed some data-URI encoded text. Just for completeness, in one case it's part of a custom #font-face{src:url(data:application/octet-stream;..., in another is part of a background-image:url(data:image/png;....
It occurred to me to notice that those large bits of styles, and actually entire chunks of CSS, are repeated twice in their bundles.
Q1: Is there a way to avoid repeating such CSS parts twice? Is that due to the way the library is being bundled by angular? Or due to the way the library is authored/built/...?
Q2: What are the guidelines for angular 2 component library authors on how to ship fonts and image assets? This is in case there's a better way and I can work with authors to change things.
TA
Related
Disclaimer: There are a few questions on SO regarding CSS and debates over a single or multiple CSS files but I think this is a bit different
I have a pretty big Angular 7 app using Angular Material 2 and I want to introduce themes. Each theme will be retrieved on user login (the theme is saved on the server and cannot be changed by the user).
The question is mainly regarding whether it would be best to export a single CSS file using top-level classes (body or app container) for each theme, replacing only classes that change for each theme or lazy load a new css file on top of the main css file with only the classes that are getting overwritten.
My biggest concern with the first option is getting a huge single CSS file. The current file is already around 300kb (unminified CSS is about 11k lines of code) and with themes ranging from 200-500 lines each and there could be 10+ themes, the file can easily get double or even triple that amount.
On the other hand, lazy loaded CSS might cause the user to download 2 smaller files but the implications might be worse. For example a lazy loaded CSS file needs to be exported with separate configs in Angular CLI and the name needs to be specific so it can be loaded from Angular on login which means caching might be an issue if something changes and also no versioning (eg. theme-blah-2.17.css) is also not possible in the name of the file. Possibly other implications that I cannot think of at the moment too.
Look at how material handles themes.
Also, take a look at how teradata Covalent handles themes.
I'm using CSS Modules (Sass) with rollup on a component library project, which is working well. Each component ends up with a dist folder containing a single JS bundle file, and a corresponding CSS file with the scoped CSS classes so consumers of the component don't have to worry about CSS class name conflicts. All they do is include the JS bundle and the CSS file and everything is great. Yay CSS Modules.
The problem I'm now facing is that some components really need separate "themes" - ideally, separate CSS files, one per theme. So consumers can continue as they've been doing: including the JS bundle, but now choosing which CSS file to include to pick a theme.
I'm not sure how to get this going with CSS modules & rollup, and whether this is even the sort of approach others are taking. From what I can see, rollup always handles bundling things together, whereas I want separate CSS files, all of which get their classes renamed identically during the build phase. That way, if within my JS I refer to styles.myclass, if myclass had gotten renamed to scoped-myclass by CSS modules for the original CSS file, for a second CSS file it would also get the same name.
This would keep consumption of the component extremely simple - just a matter of including a different CSS file.
Any suggestions?
Awfully late, but let me answer this 3 years on. So what I ended up doing was totally detaching the CSS generation step from rollup and relying on the Sass CLI to handle that portion of the build process. It felt a bit klutzy, but I remember it wasn't awfully hard to do and solved the problem I outlined above. I don't believe there was a plain rollup solution at the time, nor do I think there's one today.
However... in my case the whole approach was kinda mistaken. This certainly won't be everyone's scenario, but let me spell it all out because hey it may be useful and it definitely wasn't obvious to me at the time.
This was for an in-house shared component library, where each component and its corresponding CSS was a separate npm package stored in our Artifactory. When it grew, plenty of internal references popped up, e.g. multiple components would reference the Button component, and over time they'd reference different versions of the Buttons component - each of which needed its own properly scoped CSS, unique to that package-version.
So what I found was that by doing it this way - having the CSS generated as part of the npm package dist files - I had to write an additional layer for the consumer applications that would parse their node_modules/ folder for our own internal components and combine all the different CSS files, such as the multiple versions of buttons. e.g. the main application would directly import buttons v1.0.0 in its package.json file, but the Dialog component (also included in the package.json) could include buttons 2.0.0 as its own dependency. For every version of the package, there was a uniquely scoped version of the CSS - so the consuming application HAD to include every version otherwise the styling would be borked.
So all in all, it ended up being way more complex that I wanted. I thought I could make it easier & better with the separate generated themed CSS files as part of the package dist, but it didn't end up that way. If I could revisit that project today, I'd re-examine a solution used by Material UI and others which I kinda poo-poo'd at the time: automatic injection of the CSS into the page by the component JS, rather than generating standalone CSS files which required extra work by the consumer applications to gather up and add to the final webpage. Frankly, now I regard it as the "least crap". There are definite downsides to the injection approach (extra work done on every page render for everyone! Yikes!), but there's no doubt in my mind it hugely simplifies the job of the consumer applications. It's a balancing act, but in 20-20 hindsight I'd lean towards the injection approach. With that, scoping & theming is a different and much simpler problem.
If I got you right, consider looking at SCSS plugin: rollup-plugin-scss. It captures all spare .css files imported in the components, and then processes them through underlying node-sass. The catch is, it seems like you can write a custom callback function that'd handle your CSSs differently based on conditions you throw in.
Based on the example from the plugin's page:
import scss from 'rollup-plugin-scss'
...
export default {
input: 'src/index.tsx',
output: [...],
plugins: [
...
output: function (styles, styleNodes) {
// replace this with conditioned outputs as needed:
writeFileSync('bundle1.css', styles)
writeFileSync('bundle2.css', styles)
},
]
}
I'm starting a new angular project and it has been decided not to use a framework like bootstrap/bulma/materialize/... but write our own sassy component library.
I have done some research but to be honnest I don't realy know where to start (besides a css reset). I'm still a junior, have already worked on some features in a previous existing project. Now I have to start of the front end for new project and would like to build everything as structured and reusable as possible but I'm a little lost where to start.
What's your plan of action when you start writing your?
How do you structure your angular components library?
Have you ever seen a good tutorial about this that I should definitely check out as well?
From my point of view, it is not a simple task. But you can start from using SCSS which will give you a wide access to term reusability. And also you may need to work on flexbox/grid-layout (Not the case if you need to support old browsers like IE 11 and below) to implement a handful of styled components. By the combination of scss and 'flexbox`, I think most of the components can be created simply and reused in the way you want it to be.
I strongly recommend avoiding the usage of libraries and write our own code instead. Because the power we will have at the time is infinite. You will be amazed to have it.
But at the same time, if the project is a long-running project and your requirements are on the way, then I would suggest you to rethink about eliminating libraries like 'bootstrap, materialize. Otherwise, if the requirements change in time and you may need to use a number of libraries to achieve the functionalities you may need. (Experience is the best teacher)
On most of my projects to date I have not used a framework and written my own CSS library and would recommended it. I don't have any experience with Angular, only React. All I can share with you is my current setup.
I use gulp to compile SASS files into a main.css file and BEM methodology (You could also look at SMACSS). Each 'block' (defined by BEM) has a separate file in either Layout or Modules.
I separate my SASS files into the following folder:
Base - Used for - resets /Grids / helpers/ typography/ base (general base styles eg wrap)
Layout - Used for containers - header/footer/sidebar ect
Lib - used for mixins
Modules - used for components - form / button / alert / icon / accordion ect
Settings - color / font / responsive - used to set sass varibles to be used in all other files.
I hope that helps.
As I become more familiar with Angular, and the vast number of modules out there for making an application really shine, I am also becoming overwhelmed at understanding the basic logic of CSS overloading, and how to manage the imports to get the desired behavior.
For instance, I have pulled the following libraries into my Angular application; Boostrap, Bootcards, boostrap-select, font-awesome, and some custom bootstrap-wizard libraries for a modal tab-based wizard.
All of these libraries require being defined in the index.html page of my Angular app (both the CSS files the JS files). How do you manage the desired behaviors so that one components styles don't override another components styles? What are the best practices around bringing in multiple components and using them in an Angular app, without negatively affecting the applications previous behaviors?
You have 3 choices:
Place more important CSS files AFTER less important ones so the more important override when both have same attribute names.
Manually go in stylesheet and change attribute names.
Instead of including the stylesheet in index, include it in your html file
I am making a static website with Flask and using the flask-bootstrap extension to simplify the front-end development. I concurrently have been learning Rails and so I understand that there are a few of these languages that compile down to CSS (LESS/SASS/SCSS). As I understand it, Bootstrap by default uses LESS, and in my Rails app I had to convert LESS variables (with an # symbol at the beginning) into SCSS variables (with a $). This wasn't too difficult, no problem.
I noticed that in Miguel Grinberg's tutorial (Flask Web Development, O'Reilly) Bootstrap is used (Flask-Bootstrap extension), and there is the brief mention of {% block styles %} used to include stylesheets that way, I am confused about how I can go about modifying the existing LESS variables that come by default with Bootstrap so that I can modify the grid structure and not mess things up with my own custom stylesheets. I want to be able to do, for example, is modify the #body-bg LESS variable, or any of the ones here: http://getbootstrap.com/customize
It is very interesting question. I also was interesting in creating styles dynamically. You need follow another ways. It is not possible by the way you have described above.
You mentioned you used Flask-Bootstrap. This extension adopts the Flask project to use the Twitter Bootstrap styles. I have not fond any SASS/LESS functionality.
http://pythonhosted.org/Flask-Bootstrap/#
https://github.com/mbr/flask-bootstrap
If you look at the static folder of the extension you will not find any tracks of SASS/LESS.
As I know Twitter Bootstrap is generated by LESS. There is also a SASS fork. You regenerate styles and replace them in the static folder of the Flask-Bootstrap project.
If you want to do it dynamically you need create your own solution. I do not know a ready extension. It is the very challenging task.