I have a custom component that displays an error message or a response success message. They only have these 2 "states", so the styling for the element can only be one of the two:
for success:

background-color: green;

for error:

background-color: red;

Is it a good practice to have a state for the element that just changes the "className" property to one of these info__success / info__error and have the styling typed in css like so:

.jsx

const errorClassName = "info__error";
const successClassName = "info__success";

const [ classState, setClassState ] = useState(errorClassName);

return (
  <div className={classState}>Message</div>
)

.css

.info__error {
  background-color: red;
}

.info__success {
  background-color: green;
}

I know i can just use a list like below and have it as a state but it just gets really messy if i have a lot of css to update.

 
const [ error, setError ] = useState(true);

const style = {
  background-color: error ? "red" : "green",
}

return (
  <div style={style}>Message</div>
)

Is there any better way of doing this that is not messy in the code and practical to use. I really don’t like writing css inside my .jsx files, and i don’t like tailwind that much.

>Solution :

Your second choice is definitely a better one between the two. But there is a third option which would better fit patterns I see in production code, and I think it would be more pleasing to you. Use state to keep track of whether or not there is an error, as in your second example. Then use the error state to determine the class, as in your first example.

const [ hasError, setHasError ] = useState(false);

return (
  <div className={hasError ? 'info__error' : 'info__success'}>Message</div>
)

My understanding is that directly manipulating the style would be fine if you’re not using a utility framework like TailwindCSS. I wouldn’t necessarily have an issue with that until it got complicated (more than a few properties). But I would push back against storing the class string directly in state.

The class name is a side effect of what you’re actually keeping track of: the error state. And, by keeping track of the error state directly, you can easily employ other side effects, which you should do for accessibility reasons (a color change is no change to someone who can’t see color). This could include rendering a hidden-by-default error message and/or managing focus.