It was refreshingly simple and, despite being more verbose, it was clear what everything would happen once a certain event would happen. With a bit of clever refactoring dealing with elements factories wasn't too bad, even without a templating engine.
Not having to think "How is this going to be rendered by React, is it going to be efficient or trash performance" was great and I think it's intrinsic of picking a certain abstraction and we'll always have that.
Sure, the better the abstraction the less this problem happens eg. Solid is calling the component function once, which makes things easy to reason about
And yeah, this definitely set off my alarm bells like "maybe I shouldn't be using React here." I guess the initial goal was just getting something that works out there using the thing I know best (React), and the second phase could be a rewrite using a better tool for the job-open to any thoughts and suggestions on that.
Unfortunately I don't have more specific suggestions, but just in case the verbosity of vanilla is a turn-off, I will namedrop Bliss.js.
This is the case currently, but when field-sizing: content; lands, you can do it with a single property.
Also I get a weird feeling when something like React makes simple things hard and low performance. The solution of pouring a lot of time into debugging and optimizing (in context of React) feels even weirder to me. Sure, you might not need React here, but what if you do? What's the next best solution? Integrate the React "frame" with an "island" of vanilla?
I don't know, something about having this issue puts me off in a major way.