Which components are adding emotion css global styles - javascript

Two global syles entries are added to my pages and I cannot have control over them.
Could you help me to understand which components are injecting them?
App developed in gatsby using:
Grommet
Styled components
Code gets included in header section
<style data-emotion="css-global"> ... <style>
<style data-emotion="css-global"> ... <style>
I would like to know, how I can debug the issue? Let's say which component is responsible for adding these two lines.

These are defined in Emotion's <Global /> component (emotion global styles). If you used a starter or theme this is probably the source. If this isn't enough direction, please share a link to the starter or theme repo, or to your repo.

Related

Is there any solution to these problems with Next.Js?

So i recently migrated from react to Next.Js, I am facing these issues and want to know if these have a solution :
Unlike react next can't just change a specific part of webpage and keep static part like navbar same throughout all my pages, I have to specifically add my Navbar component to all pages
The {styles.example} way of using css seems like a lot of work, I saw a lot of people using to do css within the js file, but it becomes a mess when I try to make it responsive. Is there any way i can use css just as normal like import it in js file, and use classname='example' in example.module.css
use _app
https://nextjs.org/docs/advanced-features/custom-app
import css in _app is global
https://nextjs.org/docs/basic-features/built-in-css-support
css extended
head(html way, won't apply loaders,make sure resource placed as refered): https://nextjs.org/docs/api-reference/next/head
import css (_app just like head but go webpack, named if not _app): https://nextjs.org/docs/basic-features/built-in-css-support
styled-jsx (inline,scoped by default, set global via prop): https://github.com/vercel/styled-jsx
element-style-prop: the react way
example cases
head in _app: compiled global css like bootstrap reset...
import css in _app: global custom css
head in component: compiled css for component, like date picker
import css in component: named fassion
styled-jsx: css fassion, scoped by default, global if global prop set
element-style: react fassion, element level

Apply css style to all primeng dialogs in my angular app

I am using prime ng dialog all over my angular application. I can change each specific dialog style by using ng-deep. For eg I have contact us page for which I have these files:
contact.html
contact.component.ts
contact.css
So I place the below css in contact.css and it changes the contact us dialog title bar color.
:host ::ng-deep .ui-dialog .ui-dialog-titlebar{
background-color: red
}
I want to do this for all the dialogs in my application, how can I do this? I placed the same css in style.css file in src folder and it didn't work.
So angular components by default employ a very handy strategy of Style Encapsulation which makes it so that styles don't bleed out into other components and cause unwanted effects.
You can utilize ng-deep like you have to allow styles defined within it to be inherited by child components of where it's specified.
However for things to be globally inherited you'll want to define them highest up in the order of inception so those styles cascade down to selectors below. In a default angular application that's not using SCSS or another pre-processor one of the easiest ways to do this is to add them to one of the first files initialized that hosts the child components such as index.html or app.component to allow components initialized afterwards to inherit them when they're rendered.
Hope this helps, cheers!

Override or remove the appTheme CSS injected into a Buildfire App

So I faced the challenge of created a large custom app through the Buildfire platform. The client had a lot of custom element styles that were being overridden by the appTheme settings in the dashboard, and overriding these styles in traditional CSS fashion was growing to be a monumental task.
I wrote this small function to remove the custom styles injected into the application and so far all of the client's custom styling is showing correctly.
I figured I would share this with the community since this has been an issue without resolution for our team.
If you wish to disable the appTheme CSS in your plugin, you can simply use a meta tag in the widget's HTML, like so:
<meta name="buildfire" content="disableTheme">
This is covered the SDK wiki under the meta tag section.
This code is inside my index.html file for the AngularJS Application.
<body ng-controller="mainController" onload="removeCustomCSS()">
<script>
function removeCustomCSS() {
let links = document.querySelectorAll('[href*=appTheme]');
links[0].remove();
}
</script>

Difference between importing CSS from HTML header VS JS file VS Vue Component

I am experimenting around with Vue (having webpack installed) and am wondering what the differences are in methods of importing CSS. It seems as though there are three ways in which you can import CSS:
Importing style sheets in HTML headers: <link type="text/css" rel="stylesheet" ... >
Importing css files from JS files (e.g. main.js): import '#/assets/css/app.cs' / require
Importing css files within Vue style tags: <style>#import '...'</style>
In which situations would we want to use one method of importing over the other? What are the best procedures for this?
To my understanding, importing from HTML headers act as "global" stylesheets. This is especially useful if you need Reset or Normalize CSS file which doesn't need to interact with the rest of the components at all.
Importing from JS file is a webpack feature. I usually use it to import styles to my main (or) individual page components, which then share the stylesheet for their child components.
Lastly, VueJS style tags are commonly used for "scoped" styles. This is especially useful if you need to have unique styles for many child components and doesn't want to conflict with other component styles.
You can use the scoped styling like this.
<style scoped>
/* Your styles over here /*
</style>
You can also use CSS Pre-processors in Vue style tags like:
<style lang="scss">
<style lang="less">
Of course the pre-processor styles also can have scoped attribute.

What is the best way to deal with CSS style conflicts in React application which has dashboard and landing?

I'm not really into styling, I'm a programmer, so maybe I'm doing something wrong but I can't figure out how to deal with this problem:
I have a SPA on reactjs which has admin dashboard and a landing page. Depending on whether user is logged in or not, different module is rendered on the same domain and url.
The index.html page is very simple:
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title></title>
</head>
<body>
<div id="app">
</div>
</body>
</html>
There's a session check in index.js, and if user is logged in Dashboard is rendered to the app div instead of Landing.
I didn't create dashboard style myself, I took a bootstrap template from the Internet with it's custom styles of course. I also have styles.scss file with the following contents:
#import "./custom";
#import "./font-awesome";
#import "./app/admin";
#import "./app/daterangepicker";
#import "./app/nprogress";
#import "./app/skin";
#import "./bootstrap";
This file is imported to index.js.
The problem is that dashboard's custom styles conflict with my landing page's (which is also built with bootstrap) css styles.
So my first idea was to create 2 scss files with imports, one for dashboard and one for landing. But is there any way to attach different css files depending on what part of the application must be rendered and to be able to do it in a conditional statement without reloading the whole page in the browser?
Or maybe there are some better ideas to get around this problem?
This is generally a hard problem to solve nicely after-the-fact. These css specificity and shadowing problems have not had nice solutions, in my experience, but you have some options.
You can give some top-level component for these two views an additional className based on the page and then scope your scss bundle, or the specific custom styles you need to take precedence, under that class. For example, say that app.scss has all the styles:
#app {
// shared styles
&.landing-page {
// landing-page specific styles
.bootstrap-component {
color: blue;
}
}
&.dashboard {
// dashboard-specific styles
.bootstrap-component {
color: red;
}
}
}
A cause of this problem is simply that you have two different custom styles for similar components that use the same classes. As best you can, try to be consistent in the UI for a component so that the same component uses the same styles, with minor modifications applied through new classes. If that's not possible, maybe there is a different way to approach styling these components:
The changes to Bootstrap styles shared between the two pages can be made as custom styles to that class but differences in the components' styles should be brought out instead, as modifiers to that component. Using the BEM class naming convention really helped me to do this better: brief | more helpful
For example, if Bootstrap had a header component and both your dashboard and landing page wanted it to be green rather than blue, include that in your changes to bootstrap's styles. If the header, however, is smaller on the dashboard page and bigger on the landing page, those changes can be applied by new classes altogether.
If the server knows the authentication status beforehand (via some token - which it likely does), you can serve different html pages or different versions of the css. This kind of combines server-side rendering with some smart css minification. I don't think that's what you're looking for, but is possible depending on the scope of your project. I think that the point mentioned about about trying to isolate the shared and unqiue styles to a component is a better route, though.

Categories