I'm working on my first production-ready React application, and I'm using SASS as a pre-processor for my CSS. One huge benefit I find when styling my React components is being able to break my CSS into separate modules and import the specific modules needed into the corresponding React component.
The more my application grows, the harder it has become to quickly find and update the correct CSS I need while developing. Which leads to my question...
I'm thinking of implementing the following styling, and I'm not sure if it will have any effect on the performance of my app and components:
1 - Continue to separate all CSS into SASS modules
2 - Import all of those modules into a single app.scss file
3 - Import that single app.scss file into all of the components that need styling
This will let me browse a single place - app.scss - for the specific css module I need, and then quickly tell me where I need to go in my app directory to access that file. I see this being beneficial as I could write brief comments in the app.scss about each of the individual modules. That way as the app scales, I'll have documentation about what each css module accomplishes and what components those css modules correspond to.
Thus, my question is will this style of loading so many modules into a single css file and then loading that single css file into each component that needs styling slow down my app/component load time/performance?
Related
I am currently working on a Vue.js project where i use the Vue CLI 3 to build components in lib mode like this: vue-cli-service build --no-clean --target lib --name ComponentName.vue. The components can then be used any website if registered in a Vue instance.
However, the website contains it's own stylesheets and the component too. To develop and see the actual styles applied to component i have to pull in these (shared) styles in every component i develop. Therefore they are also in the compiled stylesheets after building the component using the command stated above (vue-cli-service build).
My question: Can i exclude the (shared) styles when building the component? I can't find anything about it in the docs (https://cli.vuejs.org/). If somebody could provide the answer or a (Webpack) workaround that would be much appreciated.
Many thanks in advance!
I am not sure if I understand you correctly but there is an option to have these styles inline in the components itself, which would be much easier for development.
https://cli.vuejs.org/guide/build-targets.html#app
dist/myLib.css:
Extracted CSS file (can be forced into inlined by setting css: { extract: false } in vue.config.js)
I am building a SPA with Vue (Quasar actually) in which I need to be able to:
Load the contents of a CSS file into a JS variable (or Vue data
property) at runtime
This CSS file should be produced at build time
from a SCSS file
I don’t want to load a pre-made CSS file, I want to be able to author the CSS code via SASS.
I also don’t want to compile the CSS from SCSS at runtime, e.g. on every app load.
In other words I have the following workflow in mind:
Author the CSS in a pre-defined SCSS file that is part of my project structure
At build time (or at run-dev time) I want that this SCSS is compiled into a CSS file
Then at runtime, in one of my Vue components, I want to load the previously produced CSS code as string into a variable
The reasoning for that is that this CSS code will then be fed into and iframe (via postMessage-ing) and the iframe will use CSSStyleSheet’s insertRule() to apply the styles to the page.
How should I configure my project and packages so that this can happen? One thing that I found already is that I might need to use the raw-loader but how do I prepare the CSS file when building the project so that the raw-loader can get it at runtime?
From an initial look you have two problems here both of which are relatively simple.
The first one is you need to include a scss compiler plugin during your projects build step. Which one you use will depend on any existing tooling you may be using. Otherwise, you can just drop in https://www.npmjs.com/package/node-sass
The second issue is how to acquire the css at runtime. You have a couple options here. You can compile the file into your bundle or you could retrieve it at runtime.
Runtime would keep your bundle small and allow you to serve the css normally but this requires a server to serve it. Compile time would be faster to load initially but increase your bundle size.
If you are using webpack you could use the raw loader you linked but if you are not currently using webpack that is probably out of scope.
You could do this by adding a new step to your build that converts the css into a String literal which would alleviate the need to load it at runtime but increase your bundle side.
For loading at runtime, you could easily retrieve the file via ajax from an http server.
I have found the following solution:
Install the "raw-loader" loader
Import the SCSS using the following statement:
import style from '!raw-loader!sass-loader!./my-styles.scss'
Note: the "!" at the beginning is to override the default loaders configuration. In my case Quasar chains the "style-loader" for SCSS files by default (to output a tag in the head) so I have to disable it in this case.
And now I have the compiled CSS code in the style variable.
First, run the following.
npm install path sass
Aftre that...
const path = require("path");
const sass = require("sass");
const css = sass.compile(path.join(__dirname, "style.scss")).css;
console.log(css);
I'm refactoring some Angular (7) components, and I don't know if there is some optimal location to put common scss style to reference it in many components' styleUrls.
Before refactoring, the scss was all global, and had to be built in order to be used between the different apps. Now, most of the scss has been encapsulated, requiring as few global style as possible.
However, there are still some global scss that I could get ride of in the build since they affect a known number of components. In order to do that, I extracted the scss at the root of all those components, and refered it, just before each individual components scss, in the styleUrls. (using some structure tips from this article )
Here is what the import looks like for every components requiring controls.component.scss
styleUrls: ['../controls.component.scss', './autocomplete.component.scss']
The structure looks somewhat like this :
LibName1
src
assets_source
global_styles
_global-files.scss
main.scss
lib
controls
control1
control2
control2.component.html
control2.component.scss
control2.component.ts --> here is the styleUrls
...
controls.component.scss --> the file I'm using to store cross-components style, importing in styleUrls.
Up until this point, everything is working out fine. The problem arises when I want to use this same scss file (controls.component.scss) outside of this app. The more high-level structure of our project and libs look like this :
ProjectName
src
app
components
component1
component1.html
component1.scss
component1.ts --> Where I want to refer to the controls.component.scss in the styleUrls
component2
...
libs
LibName1 --> The LibName1 from the previous structure example
I would like to be able to use the styles in the file controls.component.scss inside different components without having to build the lib and referencing its css in the main Project. I'm open to moving this file somewhere else, and what I would like is not to have to manage super longue relative paths.
I want to know what are the best practices in this scenario.
To use global for your app just put everything into your style.scss it will affect whole application style
If you want to import scss file from the library simply do like this
#import "~bootstrap/scss/bootstrap";
#import "~toastr/toastr";
#import "~font-awesome/scss/font-awesome";
Simply use ~ to import the scss file from node_modules folder
Question: How are custom Redux containers and CSS normally handled through NPM? The below structure doesn't work well with traditional package distribution platforms such as NPM as I need to edit the custom files such as the Redux container and the CSS in different projects.
Given that I have many components in a custom React component library with the following structure and files:
> Component root dir
> Component.js
> Component.css
> Component_container.js
> Component_custom.css
The Redux container holds store references which change from project
to project
The CSS also holds customisable styling for each project
These components reference other components through their containers
For example:
App.js
=> Component_1_container.js
=> Component_1.js
=> Component_2_container.js
=> Component_2.js
This is great in that it allows me to separate out custom code from the shared code, I can update Component.js and Component.css in many projects without touching the code in the custom files. However the custom container and CSS files can't be managed through NPM.
I can easily see how the CSS could be extracted into a separate folder. The Redux containers are harder because they are referenced by other components as dependencies as in the above structure. Moving them out of NPM and into another project folder would make references between components difficult to manage.
I was thinking of very similar issue and I think you could create a separate module (no matter npm module or just a folder in you're project marked as a module) named ui-kit and all components there will be Redux free, since the client of this components can use other store or work with out any.
Also, you're gonna have folder component or something you have now and your high-level component(App.js) will know only about your component which will know about ui-kit
Structure:
app
-> Components (containers)
-> Component.js
-> Component.css
-> ui-kit (Redux free components)
-> Component.js
-> Component.css
App.js (High-level component)
Having been through quite a guides and example repos, it seems that the best approach to this is to have just a few container elements sitting at a higher level controlling many related components.
I felt it was a decent idea for each component to have individual access to the store with its own container and which could change from project to project, but it is an unmanageable solution.
The main takeaway here is that presentational components should never call container components as a dependency.
Having separated out container and custom style files from the component directory, it is straightforward enough to then create NPM components which contain only the reusable code.
The question is how many containers to use in an app, here is a good summary of how to grouped components against containers which I found useful in answering this question:
http://www.thegreatcodeadventure.com/the-react-plus-redux-container-pattern/
I was reading the source code of ant-design and noticed each component got a index.ts and index.less in the style folder. Why js is used here for managing dependencies? What's the difference if I just move it to the less file and use #import?
int ant design each component using less file as modular less component it means you less never applying for another components except in :global pseudoclass
have a look "react-app-rewire-less-modules"