A lot of rules like "some fields are hidden / shown based on other fields" come from restricting users to only expressing valid object states. E.g. I have a form where a user can pick a "notifier". They get a first dropdown select which is email or teams-message. Then based on that selection to get another which fills the details relative to that.

In that case, the backend will likely have a class instancr representing it, with the first field being a discriminator on the class and the remaining fields being the details. And regardless of what the frontend does, the backend will revalidate always because you can never trust data sent from a frontend.

All that to say, maybe the form could be server side rendered, with an adaptor to convert a class definition into an html form fragment, and either embedding the js "rules" into the html itself, or making it a web component for containered usage.

Doing it this way is a big deviation from the current status quo, but I've found it to work very well and cut out a whole range of bugs. Plus it makes me think about what is truly client side state (no chance of staleness) vs server state cached in client to avoid repeat server calls (could be stale, leads to bugs).