missing things

[ghost]

Hello! I like your script, but....
Thunks, are that supported or something that are going to be supported? And are you going to add a component as in https://github.com/localvoid/kivi/blob/master/lib/vdom.js#L84-L86 You have Text and Tag. Virtual DOM has widget. https://github.com/Matt-Esch/virtual-dom/blob/master/dist/virtual-dom.js#L564 Any function for for only updating parts of the DOM tree? Example you have a ul tag with 4 li-elements. And you only want to update li-element 2 and 4 NOT 1 and 3. Is that supported? And how are states working? Whislist to make this very cool:

1. Thunks
2. Component node
3. updates as described with li-tags
4. caching of the DOM tree
5. fragments

[jails]

1) In dom-layer the "thunk feature" has been generalized to all virtual nodes logic, not only the diffing process. So in other words Tag & Text are "thunk". They embed all the logic to be rendered/patched/diffed/removed etc. This way you can create you own GenericThunk, for example, if you provide all the necessary logic to make it works (i.e it will need to provide at least all methods in Text ). This is the choosen way to make nodes customizable.

2) dom-layer has only one concern, the virtual dom layer management. All componentization related feature must be managed in a higher level of abstration (i.e. on top of dom-layer). I'm working on the component layer in another library but it's not finished yet, so I can't really show something. Anyhow it would be similar to something like dekujs

3) As explained in previous points, you can take the control of your rendering/diffing/patching by providing you own custom node for some mico-optimizations. But imo fine grained updates shouldn't be done at a dom element (too complex) level but more at a component level. Each component would have a isDirty() method to be able to check whether a component needs to be re-rendered or not. Then to be able to update a single component, instead of mounting a whole tree in one go, each component will be mounted individually using mount(). Finally we will need to iterate through all mounted components (using mounted()) to run update() on dirty components only.

4) I don't really get what kind of caching would be interesting and in which context.

5) There's a couple of different definition of fragments around but if you are talking about the Reactjs one, I don't really get its value. I followed a discussion recently but the uses cases provided by the author of the issue to demonstrate the need for fragments didn't convince me. The "extra complexity behind" versus "the gain" doesn't worth the effort imo. So If a smart guy (like @paldepind from which I took the diffing/patching algorithm) can provide such feature with no extra overhead, why not, but I probably won't make the effort on something I'm not interested at.

[ghost]

I got it. I'm starting to look forward to your component library. You know when it would be ready?

For caching. Have a look here: https://github.com/Matt-Esch/virtual-dom/issues/222 and maybe some ideas you can grab from the linked in thread?

After a quick github check, I found that @paldepind is a dane, and snabbdom? Have you asked him about this? What is his ideas? Or open a ticket in his repo?

[paldepind]

After a quick github check, I found that @paldepind is a dane, and snabbdom?

Yes. I'm a dane.

I've heard of the fragment feature before. But I think it has rare uses and I've not needed it myself so I've not implemented it. You're welcome to open an issue in the Snabbdom repository and then I might take a look at it when I get the time.

[jails]

@marcorra to support reuse of virtual nodes in virtual tree definitions virtual-dom need to walk through the DOM to find the real node during patching step.

This is not the choosen approach in dom-layer. Since in a higher level of abstraction virtual trees will be generated through HTML, JSX or equivalent templates, the "virtual node reuse feature" will become useless. So in dom-layer since you can't reuse virtual nodes, each virtual node can store a reference to its corresponding DOM element, so the walk through the DOM algorithm is not needed.

And for the component library, I should be able to show a first draft probably at the end of the next month (or so) .