I have the following configuration in the antd.customize.less file:
#btn-primary-bg: #ffe900;
#btn-primary-color: #primary-color;
#btn-default-color: #primary-color;
#btn-default-bg: #ffffff;
On hovering a primary button everything is ok, but on hovering a default button the text color in the button changes to #btn-primary-bg, which I want to override, but I couldn't find any property like "#btn-default-hover-color" here. How can this be overridden, if at all?
I faced the same issue but I'm still looking for a better solution. However, for the moment, I can suggest that you add something like this to your global style file:
.ant-btn-default:hover, .ant-btn-default:focus {
border-color: #bee2e5;
color: #fff;
}
UPDATE
After antd has been updated to version 5.0.0 there is a prettier way to do it using ConfigProvider.
Let's suppose we have wrapped our App and assigned to the theme an object with parameters.
<ConfigProvider theme={{
components: {
Button: {
colorPrimaryBorderHover: 'red',
colorPrimaryHover: 'lightgray',
colorPrimary: 'red',
colorPrimaryActive: 'lightgray',
colorPrimaryTextHover: 'lightgray',
}
}
}}>
<App />
</ConfigProvider>
Acctually there are a lot of parameters to customize the appereance of your app which you can find in your
node_modules/antd/es/config-provider/context.d.ts file
However your config might be huge but to keep your code readable you might pass this object with interface of ThemeConfig as an exported value from another .ts file.
<ConfigProvider theme={myCustomTheme}>
...
Working with reassigning less variables. Thied to edit everything that connected with #primary-color, nothing changed color generated by Antd for hover/active state. Looks like there is no way to do this with less variables.
Related
If I use #tailwindcss/forms it will be styled like Unstyled on the following site.
chackbox should look like Simple on the following site.
Currently, when you press down on the checkbox like Unstyled on the site, a border is displayed. I want to eliminate it.
enter link description here
//taiwind.config.js
plugins: [
require('#tailwindcss/custom-forms'),
]
You will have to override the the style for box-shadow which is applied on checkbox and radio:
[type='checkbox']:focus, [type='radio']:focus {
box-shadow: none;
}
I'd like to use custom themes in Tailwind config to set primary/secondary colors for light and dark mode. The Tailwind docs only go over using classes in an html/jsx element like so:
<div class="bg-white dark:bg-slate-900...
Instead of declaring this on every element in my app, I'd like to do the following:
<div class="bg-primary text-secondary" />
and then in config, define something like:
colors: {
light: {
primary: "white",
secondary: "black",
}
dark: {
primary: "black",
secondary: "white",
}
}
Does anyone know of a way to do this? I am using Tailwind with React.
You can use #apply:
.bg-primary {
#apply bg-white dark:bg-slate-900
}
/* ... */
You can even go so far as to write a script to generate this CSS.
https://tailwindcss.com/docs/functions-and-directives
To anyone looking for answers in the future:
I was also looking for the same thing, and the best I think we can do at this point is:
Define colors in your tailwind config use css vars
in root/body have 2 sets of css vars. One default, and other for dark class
More information about setting tailwind config using css vars:
https://tailwindcss.com/docs/customizing-colors#using-css-variables
I actually found two solutions for this:
Daisy UI has a pretty good solution for this built in. However if you don't want to get stuck with using the entire component library, you can do what daisy is doing under the hood with:
Tailwind theme switcher
Is there a way to get only the CSS value of a Tailwind CSS class? For example, if I have translate-x-4 tailwind class I want only the 1rem CSS value (since class translate-x-4 is --tw-translate-x: 1rem;). This would be pretty useful with Framer Motion, because framer motion animation object can accept a wide variety of CSS values like 1rem, #ff3322. Is there some kind of way to do something like this <motion.div animate={{ x: getValue('translate-x-4') }} initial={false} />.
I know there exists twin.macro but it "returns" entire Tailwind CSS class. Is there a similar utility for getting only the value?
I think xwind is what you are looking for.
import xw from "xwind";
const styles = xw`text-red-100 hover:text-green-100 hover:bg-blue-200`;
// OR (with custom array syntax)
const styles = xw`text-red-100 hover[text-green-100 bg-blue-200]`;
Xwind converts your tailwind classes into Postcss-js / JSS compatible syntax.
Something like this:
const styles = {
"--text-opacity": "1",
color: ["#fde8e8", "rgba(253, 232, 232, var(--text-opacity))"],
"&:hover": {
"--text-opacity": "1",
"--bg-opacity": "1",
color: ["#def7ec", "rgba(222, 247, 236, var(--text-opacity))"],
backgroundColor: ["#c3ddfd", "rgba(195, 221, 253, var(--bg-opacity))"],
},
};
I prefer to use vscode and enable extension Tailwind CSS IntelliSense. This way, when you hover over any tailwind classes you can see the complete CSS.
TailwindCSS has a function called resolveConfig that returns an object of the generated values. The theme attribute stores the css values. I used this in my React app as follows (at the top of my file):
import resolveConfig from "tailwindcss/resolveConfig";
const styleConfig = resolveConfig().theme;
styleConfig then is an object with things like backgroundColor, gap, etc.
I can't seem to find in any of the Material-UI documentation where the "light", "dark" and "contrastText" properties of a PaletteIntention are applied or what they are used for? I know I can access them with hooks or HOC directly, but I am wondering if those variants are used in any of the built-in components automatically? This is probably obvious, so thanks in advance.
Yes, those theme values are used in MUI components.
The keyword PaletteIntention has only appeared in the document theme/palette/customization for explanation.
What it wants to say is that we can customize the theme default settings.
If we take a close look at the built-in component source like the most common one Button
Refer: the source of MUI Button
You can find that the default styles are using the theme
export const styles = (theme) => ({
/* Styles applied to the root element. */
root: {
...theme.typography.button,
boxSizing: 'border-box',
minWidth: 64,
padding: '6px 16px',
borderRadius: theme.shape.borderRadius,
color: theme.palette.text.primary,
transition: theme.transitions.create(['background-color', 'box-shadow', 'border'], {
duration: theme.transitions.duration.short,
}),
Which is quite common. I mean, why not they use the style solution inside their own package?
The document may not list all the default style one component is using, still, we can see it inside the source, and we can always customize them via the CSS API document, or override them using the MUI nesting selector or other style solution provided by MUI with theme.
Refer: document of
MUI style solutions
MUI theming
customizing-components
advanced/#theming
I've got a question about composition I'm hoping someone can help me with.
I'm using react-css-modules with Sass, and I'd like to know the best way to compose things for one of our basic bottom-level components.
Here's our component:
import React, {PropTypes} from 'react'
import cssModules from 'react-css-modules'
import styles from './style.sass'
const Button = ({children = 'Submit', ...props}) => {
const align = props.align ? `-${props.align}` : ''
const type = props.type ? `-${props.type}` : ''
const styleName = `button${type}${align}`
return (
<button onClick={props.onClick} {...props} styleName={styleName}>
{children}
</button>
)
}
Button.propTypes = {
align: PropTypes.string,
onClick: PropTypes.func.isRequired,
type: PropTypes.string,
}
export default cssModules(Button, styles)
And here's the stylesheet so far:
#import "~components/styles/variables"
.button
color: $button-default
background-color: transparent
font-family: $font-family
font-size: $default-font-size
font-weight: $font-regular
line-height: $default-button-height
margin: 0 $pad 0 0
outline: none
padding: 0 $pad*2
.left
float: left
.right
float: right
.primary
color: $background-interaction
background-color: $button-default
.button-left
composes: button, left
.button-right
composes: button, right
.button-primary
composes: button, primary
.button-primary-left
composes: button, primary, left
.button-primary-right
composes: button, primary, right
Right now, it's pretty painful. Every configurable prop we add exponentially increases the number of composed classes we have to provide. We can currently configure align and type, and since both can be null we have 6 possible combinations, so 5 composed classes to create in addition to the base .button.
If we added just one more prop, say just a boolean bold, we now have to add a whole bunch of new composed class names: .button-bold, .button-left-bold, .button-right-bold, .button-primary-bold, .button-primary-left-bold, .button-primary-right-bold.
I know with react-css-modules we can just enable the allowMultiple setting to allow us to specify multiple modules to apply to an element, but my understanding is that is against best practices. I feel like we have to be missing something here. What are we doing wrong?
I think maybe there's a mix of concerns in the example, and that's why it doesn't fit the "one class per element" rule. One of the reasons to enforce the one class per element rule is so that we can easily change the appearance of an element's state without actually touching the element. (Basically the promise of CSS itself, finally realized.) If you have multiple classes on an element, it's difficult to control the appearance without changing the element. This is especially true if you use appearance (rather than semantic) classes.
A class like "button-primary-left-bold" has some semantic meaning ("button-primary"), but it also has some layout meaning ("left") and some text appearance meaning ("bold"). A Button component probably has no business controlling its own layout. Remember, you can compose React components too! So you can have something more like:
<Left><Button type="primary">Click Me!</Button></Left>
Now the CSS module for the Button component can worry just about the types of buttons. And the Button component can be used anywhere, with any layout, not just a float-based layout.
Even better, the float could be pushed into a more semantic component as well. Perhaps something like:
<ButtonBar>
<Button>Cancel</Button>
<Button type="primary">Save</Button>
</ButtonBar>
The ButtonBar can have its own CSS module that does the layout. And later you can swap out that janky float layout for a swanky flexbox layout. :-)
Your "bold" modifier example certainly has no place inside the Button component. Better to think about why something is bold, and then make a component or semantic property for that. Otherwise, if the design calls for changing those "bold" buttons to "italic green" buttons, you have to go around changing a bunch of elements.
If you do this (exchange visual/layout classes for semantic components and break up components and CSS modules), you'll have less "exponential increases". If you do end up in a situation where you really do have a need for multiple semantic properties being combined, there is still some value in having those states be spelled out. A good example might be "primary-disabled". This is better than "primary disabled" for a couple of reasons. First, it's easy to look in the CSS module and see the explicit state listed. Second, there aren't ambiguous uses and relationships of those classes. Is "primary disabled" actually a valid use of those classes? That can only be known if somebody documents that use. The "disabled" class may override something in the "primary" class, meaning there are implicit ordering dependencies. It's easy for a well-meaning edit in the future to break things, because the relationship between those classes isn't obvious. As is often the case, choosing something implicit to save some keystrokes can lead to subtle errors. Paying that bit of keystroke tax locks things in and makes it obvious what will work and what won't.
Another small point that will save you a few keystrokes: there's really no reason for the "button-" prefix. That's exactly what CSS modules are for. Do this instead:
.normal
color: $button-default
background-color: transparent
font-family: $font-family
font-size: $default-font-size
font-weight: $font-regular
line-height: $default-button-height
margin: 0 $pad 0 0
outline: none
padding: 0 $pad*2
.primary
composes: normal
color: $background-interaction
background-color: $button-default
The filename itself essentially is the "button" prefix.
I think I'd move away from compose in this case and nest your classes. Here's my suggestion (pardon me if my jsx is a tad off):
import React, {PropTypes} from 'react'
import cssModules from 'react-css-modules'
import styles from './style.sass'
const Button = ({children = 'Submit', ...props}) => {
const align = props.align ? `${props.align}` : ''
const type = props.type ? `${props.type}` : ''
const styleName = `button ${type} ${align}`
return (
<button onClick={props.onClick} {...props} styleName={styleName}>
{children}
</button>
)
}
Button.propTypes = {
align: PropTypes.string,
onClick: PropTypes.func.isRequired,
type: PropTypes.string,
}
export default cssModules(Button, styles)
And the SASS:
#import "~components/styles/variables"
.button
color: $button-default
background-color: transparent
font-family: $font-family
font-size: $default-font-size
font-weight: $font-regular
line-height: $default-button-height
margin: 0 $pad 0 0
outline: none
padding: 0 $pad*2
&.left
float: left
&.right
float: right
&.primary
color: $background-interaction
background-color: $button-default
Fully acknowledging that "left" and "primary" could conflict with other class names in your app. So it might not be a bad idea to come up with some slightly better (more scoped) names.