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.
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.
const myHandler = function (event) {
console.log(event.target);
};
// this is simple and easier to troubleshoot,
// but you can only directly assign one value to an object property
myNode.onclick = myHandler;
// for pages with JavaScript code from third party domains
// use event listeners instead
myNode.addEventListener("click", myHandler);
When leaving frameworks you have to stop thinking in terms of components, isolated code islands that exist only in their own isolated world. Instead think of areas of the page as parts of a larger whole. You can manage each part independently or not. You wouldn't program outside the browser using something like React, so your programming inside the browser should reflect how you would build an application if the browser weren't there.
Yes and then add few other pieces of state and interdependent components, the reactive code will extend, the manual patch job of connecting listeners and mutating DOM will start falling apart. The first example is okay for a one off but can't be reused as a component. It's also easy to get in a place where you have to update 3-4 different handlers to include a logic change. In a component based library/framework, you ideally update the state logic in one place and the UI just reflects that.
For example, making the UI dynamic with a button that adds/removes multiple items that need this show/hide logic, you would need to attach new listeners, clean up listeners, clean up DOM items, and so on... my first example was only illustrative, but not to be taken literally. There a complex UI state in many apps, and reactivity with component based reuse is easier to manage and make sure all states are covered. Many times in my jquery years 10-15 years ago I had failed to update one piece of the DOM and there would be bugs that just aren't happening with component UIs.
I agree separating your UI into components is important. If React learned us one thing it is that keeping related stuff together is the way to go. Separating into components and keeping your functions as pure as possible gives you 95% of what makes React great! You can read my answer to @iliaznk on how I do this.
cleaning up listeners or cleaning up DOM nodes is rarely needed. Just remove the component element and the browser cleans up automatically.
