4 ms·

Interesting, first things first, pK and sK naming are conflicts with Primary Key and Surrogate Key, they make me quite confused occasionally. The data structur

Interesting, first things first, pK and sK naming are conflicts with Primary Key and Surrogate Key, they make me quite confused occasionally. The data structure looks like it's well-designed for wide range of application. How is performance compared to DocumentFragment[1], and how DFlex is nicer than Node api[2] that also work with DocumentFragment out of the box? [1]: https://developer.mozilla.org/en-US/docs/Web/API/DocumentFragment https://developer.mozilla.org/en-US/docs/Web/API/DocumentFra... [2]: https://developer.mozilla.org/en-US/docs/Web/API/Node https://developer.mozilla.org/en-US/docs/Web/API/Node

jimmy2020 6y ago
Thank you so much for going through API. > pK and sK naming are conflicts with Primary Key and Surrogate Key naming the keys wasn't easy for me. I had to keep in mind that I am matching each node with each other. It's important to know how to deal with the registry that's why I tried to keep siblings/parent/children as sK/pK/chK and I thought it's easier to be remembered this way. > Node api & DocumentFragment The main idea here is owning the nodes to be manipulated as an object. In node API you can get the node and traverse up/down. While following DFlex approach you can traverse through the whole DOM tree including siblings at no cost. Why? because basically, you read the node only when "it's mounted" then you can deal with Web API by doing write-only. Your browser won't repaint or do any extra steps to get the nodes. This leads to the next part: letting the app interact with nodes by animation. It won't hurt the user experience and let the app change the DOM node smoothly.
- Existenceblinks 6y ago
  > Your browser won't repaint This is true for DocumentFragment as well. But I can see objects are lighter. One of my app is tree based .. so DFlex looks interesting to me, but would love to see Svelte style examples to see how easy to build things with it. Syncing store between collaborative session via backend would be interesting.
  - jimmy2020 6y ago
    You cannot traverse the whole document with DocumentFragment and same with browser node API. But anyway, the motivation is why to read the DOM nodes from the browser while I already have them in the app. I like to think about it as a layer that connects what's missing from any modern framework. See the effect in Drag & Drop. The great benefit of knowing exactly where the dragged element is going in the tree. The basic implementation is to `switch` with siblings in the same container. And perhaps do the same thing with the whole container. Being able to drag & drop containers with the same level/depth. Maybe later, expose the `switch` functionality so it can be replaced with `bounceToRight` or `JustHide`.. etc. I've been asked many times how this is different, and as far as I can tell it's not just simple implementation for draggable. Hope to reach the point where I can achieve a fully flexible layout. The Insertion and design can in theory done by the end-user. So much work has to be done Including add Svelte support. Edit: I've already started a project to compose flexible forms: https://github.com/jalal246/folo https://github.com/jalal246/folo And like DFlex the backbone is pure javascript.

jimmy2020 6y ago

Thank you so much for going through API. > pK and sK naming are conflicts with Primary Key and Surrogate Key naming the keys wasn't easy for me. I had to keep in mind that I am matching each node with each other. It's important to know how to deal with the registry that's why I tried to keep siblings/parent/children as sK/pK/chK and I thought it's easier to be remembered this way. > Node api & DocumentFragment The main idea here is owning the nodes to be manipulated as an object. In node API you can get the node and traverse up/down. While following DFlex approach you can traverse through the whole DOM tree including siblings at no cost. Why? because basically, you read the node only when "it's mounted" then you can deal with Web API by doing write-only. Your browser won't repaint or do any extra steps to get the nodes. This leads to the next part: letting the app interact with nodes by animation. It won't hurt the user experience and let the app change the DOM node smoothly.

Existenceblinks 6y ago
> Your browser won't repaint This is true for DocumentFragment as well. But I can see objects are lighter. One of my app is tree based .. so DFlex looks interesting to me, but would love to see Svelte style examples to see how easy to build things with it. Syncing store between collaborative session via backend would be interesting.
- jimmy2020 6y ago
  You cannot traverse the whole document with DocumentFragment and same with browser node API. But anyway, the motivation is why to read the DOM nodes from the browser while I already have them in the app. I like to think about it as a layer that connects what's missing from any modern framework. See the effect in Drag & Drop. The great benefit of knowing exactly where the dragged element is going in the tree. The basic implementation is to `switch` with siblings in the same container. And perhaps do the same thing with the whole container. Being able to drag & drop containers with the same level/depth. Maybe later, expose the `switch` functionality so it can be replaced with `bounceToRight` or `JustHide`.. etc. I've been asked many times how this is different, and as far as I can tell it's not just simple implementation for draggable. Hope to reach the point where I can achieve a fully flexible layout. The Insertion and design can in theory done by the end-user. So much work has to be done Including add Svelte support. Edit: I've already started a project to compose flexible forms: https://github.com/jalal246/folo https://github.com/jalal246/folo And like DFlex the backbone is pure javascript.