I've just inherited a large React project. I do not have much experience with React but I'm trying to make some improvements where I know how.
One issue we have is that our main CSS file is huge and one of the main reasons for this is that a bunch of images used in background-image properties have been embedded as Data-URIs despite them being set to relative URLs in the original SASS files.
These images are used multiple times throughout the app and so we end up with a final CSS file that has the same images embedded multiple times!
The application is built using react-scripts build which I believe is the culprit. As stated here:
To reduce the number of requests to the server, importing images that
are less than 10,000 bytes returns a data URI instead of a path.
I don't want this. Is there a way I can disable this? The project isn't using Webpack or any other build tool/bundler. All I have is the scripts in package.json to play with.
I'm not sure if you can do this with a simple toggle, since create-react-app isn't very customizable by design.
In order to change any configuration you'd like, you have a couple of options:
Forking the configuration (https://auth0.com/blog/how-to-configure-create-react-app/), which allows you to modify the configuration but still stay within create-react-app's boundaries.
Ejecting (https://facebook.github.io/create-react-app/docs/available-scripts#npm-run-eject) which will irreversably give you full power over the build configuration (which means you also have to maintain it going forward).
Related
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)
},
]
}
Hope you all doing great.
I am using SCSS and Bootstrap in my Angular Application and as we know once Angular app runs, it converts these SCSS files to CSS version of it.
How can I check CSS file size generated as a whole for application as I need to show some reports for optimization tasks.
Any idea. I tried googling and here on Stack Overflow but couldn't find required solution. I can't even see any CSS file in Network tabs of Browsers.
Any Suggestion?
Assuming you are using Angular CLI for your project, which uses webpack internally...
Once you build a project. A dist directory is generated in the project root. Take a look into it and you'll find all the .js and .css bundles it might have generated.
Note - The size will vary based on what kind of build you do. For a production build, the sizes are going to be minimal, for other kinds of builds, if any, the sizes may differ.
You should go first in the Networks tab then reload the page. Once you reload it, click on CSS filter then you would see all the list of CSS included in your app, with the file size.
I didnt find any css generated in Network like above answer but I did a trick.
I went to webpack folder and there I found one generated CSS. ( Searched through a random CSS Selecto ).
I right clicked and saved it on desktop. If you check the properties of this CSS file, it shows the size in KB.
I have a website which uses 1 css file, it is called body.css and it consists of 841 lines. Should it be sorted in different files (header.css, footer.css page1.css, etc...), is it better in just 1 file or does it not matter?
The only thing I know for sure is sorting it in more files is a lot more readable.
Also if someone answers this I'd be most grateful for a little explanation.
My opinion would be one of two things.
1) If you know that your CSS will NEVER change once you've built it, I'd build multiple CSS files in the development stage (for readability), and then manually combine them before going live (to reduce http requests)
2) If you know that you're going to change your CSS once in a while, and need to keep it readable, I would build separate files and use code (providing you're using some sort of programming language) to combine them at runtime build time (runtime minification/combination is a resource pig).
With either option I would highly recommend caching on the client side in order to further reduce http requests.
So, there are good reasons in both cases...
A solution that would allow you to get the best of both ideas would be :
To develop using several small CSS files
i.e. easier to develop
To have a build process for your application, that "combines" those files into one
That build process could also minify that big file, btw
It obviously means that your application must have some
configuration stuff that allows it to swith from "multi-files mode" to "mono-file mode".
And to use, in production, only the big file i.e. Single CSS
Result : faster loading pages
maybe this will help you..
For optimal performance it is better to have only one css file.
But for readability it would be better to have different files for different parts.
Take a look at tools like SASS, which help do that without sacrifice performance. Additionally it has features to make your files even more readable by introducing variables, function and much more.
Using more files means more requests. It will take more time to load and make unnecessary requests to the server. I'd stay with one file.
The only good reason to have other css files would be if you have third-party components, to keep them separated and be able to update them easily.
The order matters: Rules loaded later will override rules with the same name loaded before (this is valid even for rules in the same file).
What do you mean that your website uses one CSS file? Normally you'd write your style definitions in multiple files, and they are concatenated (or not) into one file. My point is, what you are working on in your development environment should stay modular, readable, it shouldn't be influenced by what you have in production.
As for the order of the CSS files, yes, it matters, as you can overwrite your previous definitions.
For optimal caching I'd recommend you to build all the vendor CSS in one file, and your CSS in another file, versioned, so that if you change something in your code, only that file has to be updated by the browser.
But these things depend on the infrastructure. As the browsers are able now to send multiple requests simultaneously, having multiple files can lead to faster page load than only one. But I'm not sure about this.
you might want to take a look at gulp to automatically optimize, and minify your CSS code.
All css in one file is OK.
But it's free : you can make as many css file as you want.
However usually this is how it is:
1 global css file for the entire page. You put the common css in here that is useful for every page on your site. You can call it app.css or style.css or mywebsite.css or any name you want.
1 specific css file for a specific page when you want to specially separate this css from the global css file. Because it will contains css only useful for a few pages. For example you have a special component made by your own or a special functionnality. Example : you have made a spcial javascript code working with some html for uploading some file and you want to have your code js/css separate.
Usually, you can also have one css page for each page, but always one global css file for the entire site.
Note : Same question is also valid for javascript
Note 2 : You can also think about using a framework to minify your javascript and css into one single css / js file at the end. At work our technical boss use wro4j which works for java but it should exists many more other frameworks as you can search on google.
I'm using webpack to generate the appropriate files for a npm package which will host a few react components. They have some CSS attached, which references some fonts and icons.
When using the file loader, these assets are mis-referenced using their absolute paths (i.e. fonts/my-font.woff) in the main app which are missing.
Is there a way to fix this and make my main app look for the right files? I'd rather fix the package itself than doing things like copying the assets like someone has mentioned as I may not have full control of the main app.
Well, I'm going to preface this by saying that including fonts in a component is usually a bad idea since the main app likely has its own style/branding/etc that you'll be fighting with.
That said, if the fonts are something like icons you could base64 encode them and inline that in the CSS. There are several Webpack encoder plugins to do that.
You also mentioned icons, I would try to convert these to SVG and serve them up inside the code. You could also base64 encode the PNGs into your CSS as a fallback.
The benefits, to this approach:
Eliminating HTTP requests in the parent app
Parent app always has the latest (non-cached) icons/fonts when you update your package
You don't have to worry about paths, packaging external files, etc
Cons I can think of:
You're increasing script sizes significantly
You lose some caching benefits
If you're not the copyright owner of the icons/fonts, this may violate TOS
I have an app which needs to work in several languages, and several different color schemes and I would rather not load all the CSS every time since a large amount of it is not necessary or relavant (rtl css for example) but meteor automaticaly loads all CSS files he can find.
is there a way to selectively load CSS files?
Thanks.
If you place a CSS file within the reach of Meteor compiler, it's merged into the main app and in the current release there's nothing you can do about this.
You can however put the file in /public directory. Meteor won't touch it there, and you will be able to load it at will by adding <link/> tag to your page head.
Please have a look at https://stackoverflow.com/a/26694517/1523072 which seems a quite elegant way to do this and also explains why you shouldn't do it.
One of my apps currently loads 2.6MB compressed Javascript and 300KB compressed CSS, which seems like a lot. However, after the first visit all the resources are cached by my browser, which means the only thing that is transferred between browser and server after that is pure data.