Open ankoh opened 5 years ago
I think we want to move away from the change list stack machine approach because
and also supporting these refs would be easier if dodrio held onto the dom elements from wasm.
That is to say, I agree this is a feature that Dodrio should support, but I think the right way to do it involves switching away from the change list stack machine approach.
@fitzgen I have written a version that does away with the current approach to the change list, and directly calls into the various JS bindings. The code lifes here: https://github.com/dignifiedquire/dodrio/tree/x-direct So far performance seems at least similar, but it is hard to really measure, let me know if you are interested in a PR for this.
@dignifiedquire Hi! Thanks for PR.
Mind if I ask if you are still pushing for this PR #146 ?
I have a project based on dodrio 0.2.0 and would really like to see how it works with the reworked change_list module. This PR would also make compilation easier since it won't require loading the change_list.js which made using dodrio inside web-worker hard. Thanks anyway.
I really like Dodrios design but one thing is holding me back a bit. There should be a way to get DOM refs. In some situations you NEED to have the actual DOM nodes that have been derived from the virtual one. One quite easy example is the HTMLCanvasElement.
From what I've seen this could probably be done quite elegantly within the change-list interpreter. One could just tag specific vdom nodes and let the interpreter maintain the dom refs globally. That would result in something similar to the ref of React.
I'm just leaving this here now to start the discussion. Right now, I'm compensating the lack of DOM refs with a hacky pseudo CSS animation. I could add that if my pet project stays alive and if this is in your interest.