[thomasikzelf]

If you are writing the same DOM update code in each event handler you can abstract it into a function.

[dsego]

What I'm saying, say you have 3 dependent dropdown pickers, selecting an item in the first one determine which of the other 2 are shown. When you have reactive interfaces like that, it's hard to extract the common "business" logic. Either you redraw everything from scratch or you do a sort of show/hide on DOM elements as in jQuery days. Not sure how you can abstract that. If you do abstract it, you end up with backbone, vue, react, or other in any case.

[austin-cheney]

You are still thinking in terms of framework goodness, which is why this is challenging for you. Don't do that. Don't redraw anything. Don't create some shallow copy, cloned node, or other insanity. You don't need any of that. You don't need to litter your code, most especially your DOM nodes, with a bunch of business logic insanity.

All you need is the event handler. The event handler can be assigned to a node's event property directly, but if this is for a commercial site with lots of third party analytics/spyware you need to use a event listener instead because those third party libraries will overwrite your event assignments. The event handler receives an event object as an argument with a reference back to the given DOM node.

All the business logic should be stored in a single location representing a given business function, typically far away from the browser logic. It makes sense when you write the code without using a framework. If you write the code and try to make it look like a framework it will look like a framework, unsurprisingly. If you don't do a bunch of framework component insanity it will not look like a framework.

This is a person problem, not a technology problem.

[thomasikzelf]

    <select id=dropdown>
        <option value=a>a</option>
        <option value=b>b</option>
    </select>
    <select id=a style="display: none">...</select>
    <select id=b style="display: none">...</select>
    <script>
        const $ = name => document.querySelector(name)
        $('#dropdown').addEventListener('change', ev => {
            $('#a').style.display = ev.target.value == "a"? "block" : "none"
            $('#b').style.display = ev.target.value == "b"? "block" : "none"
        }
    </script>

vs

    const [showing, setShowing] = useState(null)
    const handleChange = ev => setShowing(ev.target.value)
    let other
    if(showing == "a") other = <select>...</select>
    if(showing == "b") other = <select>...</select>
    return <>
        <select onChange={handleChange}>
            <option value=a>a</option>
            <option value=b>b</option>
        </select>
        {other}
    </>

some notes:

- The complexities of both of these tiny pieces of code is similiar (I would say)

- React needs to load a big bundle

- React spits out a large stacktrace with react internals if something goes wrong

- React is slower

- React code cannot be easily stepped through with the debugger

- React needs a build step

- React performance is very unpredictable (this is more of a problem with many elements and dynamic code)

Your next question might be what you do once your form grows huge. See my other answer to @iliaznk how I handle that.