3 ms·
This is really cool, and I am one of those people who rolls their eyes whenever there is another article about some newfangled way to build Javascript apps on H
by gfodor 13y ago
This is really cool, and I am one of those people who rolls their eyes whenever there is another article about some newfangled way to build Javascript apps on HN.
One logical step from here is instead of having a one-to-one correspondence between the "virtual" DOM and the browser DOM is to introduce a higher level meta representation based upon the context. This seems like a logical path towards a generative, projectional approach to controlling UI and browser document rendering in general. It's been tried before in several contexts and the hacks I've tried myself have always been to hard to get my head around since it's a complex problem, but this seems like it could be a really decent foothold to build a projectional, transform-based paradigm. For example, having a meta-DOM that encodes mathematical notation (probably inspired by LaTeX), which gets transformed into the current virtual DOM, which is used to update the real DOM. User manipulates a integral on screen, and the downstream transformations are performed lazily and efficiently all the way to the screen. This type of lazy evaluation from document to screen is essentially the core challenge (from a engineering standpoint) in building a usable real-time projectional editor like that demonstrated by intentional software back in 2010 [1].
[1] http://www.infoq.com/presentations/Intentional-Software-at-Work http://www.infoq.com/presentations/Intentional-Software-at-W...
- peterhunt 13y agoThat's exactly what we encourage :) composition of higher level components that render down to other high level components that eventually render to (virtual) DOM.
- jarpineh 13y agoI wonder if this approach would work with visual XML (Docbook) and HTML editing, where resulting DOM can be complex and large. Competent writer might generate loads of input (writing 100 letters per minute, copy-paste). If my writing tool has latencies, that annoys me far more than game latency. Other approach I have been testing is contenteditable, but this won't work with virtual DOM at all. Though how you parse an existing XML document to React's virtual DOM is beyond me. Perhaps you have to generate function calls SAX style.
- peterhunt 13y agoWe could do that probably. Would need your own parser With content editable we can just parse he html. We have an example in the repo.
- jarpineh 13y ago> We could do that probably. Would need your own parser Parser for HTML and XML to generate React components and generate virtual DOM from that? This got me thinking. > With content editable we can just parse he html. We have an example in the repo. It must be the weekend denseness setting in... I grepped through React repo, but I just found bits in the core that had something to do with content editable. Could you perhaps point me to right direction? If I understand this correctly, I could parse the entered HTML to virtual DOM.