That's what I've done too. The tailwind pseudo classes can get pretty gnarly if the field is required, has error validation, animations, and other design requirements.

@@anttihiljacan u share some code showing the gnarliness of tailwind in those situations? I’m starting a new project (remix, prisma, tailwind). So far it’s been a dream but I am starting to have some trouble with styling a component based on if the error state exists

Same 😂 In that case I would use the useMemo derived from fetcher.formData.get(field) and revalidated value

I am mindblown, I didn’t know it is technically a let. I would have used useState and do a whole bunch of extra code😂

You should never mutate a prop, meaning if something like an object is passed in you should not mutate the values in that object. The reason being a) you may know what else is relying on that prop, and b) you might not know when React is going to re-render and re-change the value of that prop However, what Ryan is doing here isn't mutation, he's just reassigning the prop let a = { key: 'this thing' } a = { key: 'that thing' } The object originally assigned to a wasn't mutated, the variable a was just reassigned a new value. All that const does is says "a can never be reassigned" a.key = 'new value' Anyway, all that to say if this makes you nervous, you can just declare a new variable const copyOfProp = prop Hope that helps!

@@ReactTipsWithBrooks Amazing explanation! Always helping the community ❤

To be even more clear, it's the destructuring that declares new aliases for the values. Consider: let {a, b} = props; This is essentially the same as: let a = props.a; let b = props.b; You are now free to reassign `a` or `b` without mutating `props`. If you would mutate the thing _inside_ of `a` or `b`, for instance by doing `a.push()` or something, then `props` will be mutated to. But reassignment just means that `a` or `b` are no longer pointing to values inside `prop`.

Technically `var` but the kids don't know what that is.

It depends on what the action returns when that happens. Assuming it returns normally (i.e. some JSON) instead of throwing an error or alternative response, then the revalidation will kick in the same and reload the data from the server. The component will re-render with the old name, and the action's JSON available through the fetcher. If it *does* throw, then Remix will want to render an error component AFAIK.

Remix will do that automatically. It'll fetch the actual data from the server wheter it changed successfully or not.

You must be a villain ai