yes, that's a good way to put it. i provided default dom representation for the most common data types, so i can just directly render them, but later customize arbitrary parts of the data by turning those parts into records and implement a render function them
Thank you!
I haven't actually designed it, I just built it as a need has arose for a feature.
You can see its evolution was just about 4 steps:
1. https://github.com/enumatech/cljs-abi-viewer/commit/d3c74ef7877aaae1e4295d7761d62f9e61ad889c
2. https://github.com/enumatech/cljs-abi-viewer/commit/657ace1952410b0724818934453a565d3e6b20a0
3. https://github.com/enumatech/cljs-abi-viewer/commit/4eb2eb35767fc0a78dc49bc65aeadec2aefa4c6b
and then i came up with the Elem
protocol with the render
method idea to keep the data and its visualization connected but as loosely as i could possibly think of:
https://github.com/enumatech/cljs-abi-viewer/commit/fde773ccf58ba77bc6ad50793ce081f44998d542#diff-c8c65fd8671e437d18217fbfe0865542
i had some mirthil experiments last year, but i dropped it after about 5-10 minutes because when i was editing text in an input field rendered by mirthil, the cursor was jumping to the end of the input text, but not in every browser as if the whole input element has been recreated. then i tried some hoplon and react examples and none of those had issues with the same browser... but their state management story is not the best either, so i moved on...
Another interesting thing I've been looking into a little bit: https://github.com/nyxtom/reconcile.js. Let's you diff/apply diffs of regular js elements
seems pretty performant and easy to use in my initial experiments