-
Notifications
You must be signed in to change notification settings - Fork 148
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How can i get primary or secondary color? #65
Comments
This would work in most cases indeed as it is a side-effect of the implementation, but we might look into doing it properly at some point. Right now we are not sure if it makes sense with the rest of the literal values in the color prop throughout the lib and how valuable it is. Any reason you don't want to use a literal value, like |
For example, you give the ability to change the accent color to the user. So you don't know what the accent color really is. the current workaround for this: import { useThemeContext } from "@radix-ui/themes";
const currentAccentColor = useThemeContext().accentColor;
<Heading color={currentAccentColor}>hello</Heading> Another example: maybe at some point, I wanted to change the accent color to another one. So I need to find & replace all violet with blue. Related: #33 |
Right, this is a bit of niche case for many apps though and as you said, there is an easy workaround for it. We are aware that it is super common to use a keyword for the accent in component libs, but we don't want to start mixing semantical keywords with literal values as much as possible. The other risk is that this invites an argument for other keywords, like "secondary", "primary", "tertiary", etc., which dilutes the API. That's why I am curious about the practical problem at hand that @eder3232 experiences
This is a big change design-wise and a plain find/replace seems manageable; you wouldn't have to use the accent keyword most of the time anyway as it's the default. |
Agree 👍 |
@vladmoroz That's a shame that "accent" is not part of the possible values in the color enum. I get that this seems to be messing with your mental model a little bit (semantic vs literal and all) but it's really what feels the most natural from a DX point of view (IMO). I would also argue that the value of the Theme provider itself is to be able to change a single props and all your components gets updated according to your new theme, so saying that a search&replace is the way to go kind of defeat the whole purpose of theming feature don't you think ? In my case, I need to have some I don't want this comment to feels like a bad appreciation of the tool, Radix is a great tool that I'll probably use on my projects from now on, I just wanted to add my two cents to the discussion and see where it goes :) |
So, so far the arguments for an
It's a reasonable, even conventional request, but both cases still seem too fringe to warrant the API compromises, which we value strongly in its current form. It's not often that you change an accent color in your project, and user-configurable accents are even more rare in the kind of projects that Radix Themes is geared for. That said, there are also workarounds if either case is important to your particular situation—you can create a plain string constant with your literal accent color, or extract it from the theme context if you need a dynamic value. As a general rule, we don't optimise the API for rare cases that have straightforward workarounds.
No, not really, all “colored” components default to the accent color, so the value of the Theme provider isn't nearly defeated. For the handful of components that don't use accent by default, I think that find and replace is easy enough for the few times you might change it throughout the life of your project.
I'd really recommend to stick to the API we have and give literal values a try 🙂 |
Not to belabor this, but... (please read) Wouldn't the API be better off not providing any colors? There are some odd 26 colors right now. But that's it. If you wanted to create your own custom palette, you would essentially need to hijack a color you don't think you'll need and override all the color variable definitions. I think the only colors that should exist out of the box are: Again, this is not to diminish the auto gray matching or any of the other features that work out of the box. Those are all amazing. But from a component API perspective, I would call them unnecessary. Rather, I would propose the following: (see update in next comment)
|
Having thought on this for 5 minutes... This should be a breaking change. Some edits: @radix-ui/themes
@radix-ui/themes-palette
|
Hey, I came here as well while looking for a way to use primary, secondary and semantic colors (success, warning, error, info), like in Material and Bootstrap. Do I get it right that Radix does not support it? Just one accent color? Actually, it is a common design thing to define your brand colors (corporate identity) with a color schemes that includes primary, secondary, neutral colors to be used throughout your UI. (like described here). It would be really cumbersome to use only named colors all over the place, including issues with consistency and find/replace when you need to update your primary and secondary colors. |
Hey @goerlitz I suggest that you try to give literal values a go. If that still bugs you and you absolutely need semantic colors, you can always wire them up for yourself:
|
Just climbing in here to say that for an eco system of reusable Radix components it makes a lot more sense to be able to add custom colors like primary,secondary,tertiary then to only allow specific colors. Because when components with specific colors get combined it gets messy. Whilst components made by multiple devs that all used 'primary' / 'secondary' would easily look well integrated by defining those colors |
When you want to access the colors there is no way to select the primary or secondary color, like this:
<Heading color="text-primary-content background-neutral-200"> Trabajo final de estructuras de datos y algoritmos </Heading>
It would be good if they take Daisyui as a reference for the topic of primary, secondary, neutral colors, etc.
The text was updated successfully, but these errors were encountered: