I've mostly done back-end work in the past, but I'm taking it upon myself to learn how to use Vue, and in addition to being partially color blind, design is not my strong suit. As such, I'm using a template so that I can at least have a base to start learning from.
Weirdly, however, I've noticed many times the way the CSS is loaded on my copy differs from the template, and I cannot seem to figure out why. Simply put, it seems like the SASS I've copied to a new project does not override in the same way.
My Version:
Template project, directly from GitHub:
I can get around this somewhat by finding the CSS in question and adding a "!important" to the end, though this feels like a rather hacky solution to the problem, and I'd be better off finding the real culprit, though perhaps that is the best solution.
The SASS has been directly copied from the template, so I know that nothing there is amiss. My version and the template also use the Vue-CLI that comes with Webpack, so I'm not sure if it can be some variation there, with Webpack choosing that one file cascades the other? I have all the same dependencies in my package.json file, so I know I'm not missing some crucial dependency.
I've labeled the Imgur pictures in the link I provided, but for clarification, I'd like the background to be transparent for the inspection I provided. In the template, the transparent background overrides the white, but when I run the copy of this template, the white overrides the transparent. This happens in a good handful of places I've found, so it is not just one specific part.
Hopefully this question doesn't have so many possibilities that it's impossible to answer. I just don't understand at all what could be amiss.
As you can see, the two CSS rules have the same specificity, so all things equal the rule that comes second will overwrite the first rule. In this project, there are essentially two style imports: Vuetify and the SASS files for the template (found in #/styles/index.scss).
I was able to recreate the issue by moving around the imports of these two style sheets.
In order to get the intended behaviour, you must import the styles provided by vuetify-material-dashboard after the stylesheet provided by Vuetify.
In the template project, Vuetify is imported first in main.js as import './plugins'. The vuetify-material-dashboard stylesheet, which overrides Vuetify styles, is imported in App.vue (a child of main.js).
Related
I've built a library that will be used by several Angular applications (multiple teams and no monorepo). This library includes a scss-theme. This theme uses two SVG-files. However, I can't get it to work. The path is always incorrect.
My theme scss:
.test::before {
content: url('/test.svg');
}
I've written a Schematic that can be used by the library consumers to store the images inside a subdirectory of the assets folder of the application (e.g. src/assets/test-path). The Schematic does work as expected.
It does work when I add the following style inside the client's scss:
#import "test-company/test-lib/theme";
.a-client-test::before {
// This is just an example and assumes that the test image is located at this path.
background-image: url('../../assets/test-path/test.svg');
}
But as soon as I remove the line above (that actually uses the image from the assets folder and is not required at all). The path won't work anymore.
I've tested the following paths inside the library: ./test.svg, ~/test.svg, /test.svg. Only the latter does work but only with additional styles like the one above (that wouldn't be used) on app side. That's something I want to avoid as maybe we provide 50 icons on the library-side and it would be tedious to add these classes only to use the assets.
Some additional information:
I've added node_modules to the predecessor options in angular.json.
All other styles are working correctly. Only the image doesn't work.
I know that I can use ccsUrl: "inline" option inside the ng-package.json. However, I think this option only works (as far as I know) on styles that are used by components. But I actually copy the theme styles over after the build process. Additionally, the number of icons that are used inline shouldn't be too big, otherwise, the bundle size will increase and is therefore not an option for me.
I also don't know what is best practice for a scenario like that. I just couldn't figure out a proper way so far. But I assume writing a Schematic that copies over files is also not the best approach. Maybe there is a better way (e.g. a way to reference assets from the library but keep in mind I have the styles inside my library and the path is, therefore, complicated to figure out for all modules).
Just to make it clear again: My library has a scss file that uses an image. That image path is clear at the built time but doesn't work when used by an app. I can copy over the images, but that only helps when those images are used by the app somewhere in the styles. Then the path /image.svg works. The image as well as the scss that makes use of it are provided by my application.
Thanks for your help!
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 trying to break up my monolithic React app into reusable parts that can be shared with other projects.
I want to extract some generic components (e.g. Button, Header, Dropdown, etc.) into my own little UI library. The problem I'm running into is how to manage the CSS. Right now, my app just has a single stylesheet that takes care of everything.
These are the solutions I have seen:
Embed the CSS styles for each component in the JS for the component itself (CSS in JS).
import or require the CSS files in the JS for the component and use webpack to bundle the CSS file for you.
I really don't love either option. I understand the appeal of co-locating the styles with the component, but I feel like: a) it clutters the component definition, and b) it fights with how CSS works (no more taking advantage of cascading styles since everything is so tightly scoped to the individual component).
And, I can't bring myself to import a CSS file. That just feels so wrong. We're not even writing javascript anymore at that point.
I realize that these aren't exactly popular opinions, but is there a 3rd option that I'm missing for getting a good old fashioned CSS file from an NPM module that I can just drop in my HTML and use? Ideally one that doesn't involve copy/pasting it from node_modules. :)
Thanks to the tip from #EmileBergeron I found the PostCSS import plugin. It can find and inline stylesheets in node_modules and in your own code.
So, my workflow will be:
npm install my-ui-library
Import the React components you want to use into your JS files import { Button } from 'my-ui-library'
Import the corresponding stylesheets into your CSS files #import 'my-ui-library/Button.css'
That way I'm importing CSS into CSS and JS into JS which feels a lot more natural to me. It might also make sense to just have one stylesheet for all components instead of breaking it up per-component, but that's a detail I can figure out later.
Then, I just need to add PostCSS into my build system to inline everything which has been pretty simple in testing.
I'm new to web development and am developing a website using bootstrap. I've got quite a few .css files that involve bootstrap, an open source bootstrap theme, some style sheets for the plugins I'm using and etc. Thing is, I feel like I'm doing the same thing over and over again, putting a lot of overhead on things.
For example, this is how the styles on the web page I'm developing currently operate:
Bootstrap default theme is loaded
Bootstrap custom theme is loaded, overrides the majority of the default bootstrap css configurations
My own custom css file is loaded, overrides the majority of the custom theme css configurations
I guess it's worth mentioning that my custom css file only overrides colours and borders.
I'm thinking if the theme is open source, should I just edit the theme itself? Or should I still be editing everything within my own custom css file?
Again, I'm very new to web development so apologies if this is quite a silly question. Optimisation is key for me, though. After the development stage I will combine the CSS files using bundles provided by the Microsoft.NET optimization package.
Never modify a library directly (css, js, php etc.). What if a new version come out, fixing some bugs. You can not download it, because it will override all your fabulous work.
You get the right process right now. Import your libraries, then override them with you own file and lines of codes.
In your case, it does not matter at all the number of files you are importing, because you will combine and minify them.
If you really care about performances, I suggest you to look at the "CDN" systeme, for Bootstrap or jQuery it could be interesting and provide some good benefits.
Look at this question and the answers, they will give you some good hints : Single huge .css file vs. multiple smaller specific .css files?
I have an issue with sass compilation.
When I have a project with a partial _partial.scss and have it imported in multiple partial files (because it contains color variables) it will end up in the compiled css multiple times!
This is ugly because the same rule will 'overrule' itself multiple times which makes debugging info (chromium dev tools / firebug) rather unreadable.
I presume there is a solution for all this. I just can't find anything on the issue, anywhere.
The solution is to either not include the same file multiple times or don't have any code that directly outputs CSS in the file you're planning on including more than once. If your variables were in a file by themselves, they could be safely included anywhere you'd like without selector duplication.
Maybe this #mixin helps you: https://github.com/wilsonpage/sass-import-once.
Have a look at the example and note how the reset is only included once in the final CSS.
It seems that just for this, sass (and thus, scss) now have #use instead of #import. From the #use documentation (emphasis is mine):
The simplest #use rule is written #use "", which loads the module at the given URL. Any styles loaded this way will be included exactly once in the compiled CSS output, no matter how many times those styles are loaded.
Sass also discourages further use of #import:
The Sass team discourages the continued use of the #import rule. Sass will gradually phase it out over the next few years, and eventually remove it from the language entirely. Prefer the #use rule instead.
Any projects having this problem could try running the module migrator tool and check if the problem is resolved.