by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Mike Botsko
    @viveleroi
    yup that seems to be it. the old nodes override the matching index in the new ones
    so I need to find a way to tell vdom that even though there are still 20 children, they're all different
    using the key property in h() doesn't seem to help
    Jamie Gaskins
    @jgaskins
    @viveleroi Do you have a small reproduction case for this?
    Mike Botsko
    @viveleroi
    no sorry, I might spend time doing that tomorrow but I've been over and over my code and it's generating the keys correctly, it's returning the new h('ol') with the correct children. a node that isn't even present in the second batch remains despite having a unique key.
    Mike Botsko
    @viveleroi
    I put together a basic example but it works as expected, so I'm really confused as to what's different. I'll toy around
    Jamie Gaskins
    @jgaskins
    lol
    Is it possible that your pagination is concatenating arrays?
    Mike Botsko
    @viveleroi
    it's supposed to because it's a "load more" feature, but even when I try replacing the entire set, the originals stay.
    Mike Botsko
    @viveleroi
    In the real app I'm regenerating the ol with an expanded set of lis - so I have some cached nodes, some new, so I'm not sure why vdom isn't recognizing one of those nodes changed (the old "load more" li/link is still there, overriding whatever new li should be there)
    my test version isn't caching anything so that's the only real difference I can see. I have no idea why it's different, because the live app caches each old node but the list itself is rebuilt
    Mike Botsko
    @viveleroi
    yup, that's the issue
    I guess I don't fully understand how the cache/thunk works. I have to regenerate the nodes for the updates to change
    Mike Botsko
    @viveleroi
    ya I think I'm just confused about how a thunk really determines if a node has been changed. it looks they're comparing two separate elements, not just the individual LI versus the brand new LI.
    Jamie Gaskins
    @jgaskins
    @viveleroi I've never used vdom thunks directly. I've always abstracted their functionality into a shouldComponentUpdate-like method because it's easier for me to understand. Here's a quick example (disclaimer: I wrote it in Gitter, so it might not work as written):
    function MyComponent(prop) { this.prop = prop; }
    
    // These two never really change
    MyComponent.prototype.type = 'Thunk';
    MyComponent.prototype.render = function(previous) {
      if(previous && previous.vnode && !this.shouldComponentUpdate(previous)) {
        return previous.vnode;
      } else {
        return this.body();
      }
    };
    
    MyComponent.prototype.shouldComponentUpdate = function(previous) {
      return this.prop !== previous.prop; // Your cache-invalidation logic here
    };
    
    MyComponent.prototype.body = function() {
      return h('div', this.prop); // Your content here
    };
    Mike Botsko
    @viveleroi
    I have too I just didn't want to refer to it and confuse anyone further. I have a VCache that does pretty much what yours does.
    Anyway, this is falling into place now. I'm realizing that one "vdom element" is compared to another in this scenario. When my "load more" li is being "replaced", vdom passes its state to the new li's comparator. That's totally not what I was expecting because I thought states were only compared against themselves (hence where the key attr comes into play)
    Mike Botsko
    @viveleroi
    In summary, it seems like vdom can't tell I've given it a brand new element, so it compares it with the original.I wasn't expecting that
    iambumblehead
    @iambumblehead
    merry christmas
    iambumblehead
    @iambumblehead
    and happy new year
    Grant Callaghan
    @gcallaghan
    any idea how React Fiber compares to the virtual-dom reconciliation algorithm?
    Jamie Gaskins
    @jgaskins
    @gcallaghan It doesn't stop and restart partway through like Fiber does. It just goes until it finishes, regardless of diff size. The good news is that it's significantly faster than React in most cases, but it does require you to manage your own render performance if your app makes huge diffs.
    Daniel Stuessy
    @dstuessy
    Just wondering. Is this project still maintained and under active development? Seems to have gone silent for over a year.
    iambumblehead
    @iambumblehead
    no development has happened in years
    I found inferno, with inferno-hyperscript, to be an almost perfect replacement for virtual-dom
    with the added benefit that my pages render and update much faster than they did with virtual-dom
    the changes made for inferno were appreciated --inferno has a more sensible way of applying attributes and using childs :)
    also inferno is under active development and they respond to bug requests in a nice and non-whining/complaining way :)
    Daniel Stuessy
    @dstuessy
    Nice, thanks man. I'll check 'em out!
    iambumblehead
    @iambumblehead
    once you switch to inferno...
    when you're telling people about the virtual-dom library you use
    you'll be able to keep your head level with the horizon and you'll be able to look them in the eye
    Jamie Gaskins
    @jgaskins
    "years" is unnecessary hyperbole. It's been a little over a year. Still a long time, but it's not many years. And Inferno's great but trashing an open-source project in their own channel is a dick move. If this library hasn't met your standards, I'm sure the maintainers are willing to refund all of the money you paid them to use it.
    Daniel Stuessy
    @dstuessy

    I have to say that inferno doesn't seem to have what I was looking for anyway. As far as I can tell, there isn't a virtual dom library that builds upon the existing dom without tearing it all down and re-rendering it yourself. This is a bit annoying if you use .NET Razor templates to render server-side but want a decent front-end library to build UI components.

    There is server-side rendering support for most popular vdom libraries, but I've found these all require a node process to run outside of .NET, which for some hosted cloud solutions is not viable.

    Is it just me or does it seem there is a use-case for a non obtrusive UI component library?

    Jamie Gaskins
    @jgaskins
    As someone who also doesn't do back-end JS, server-side rendering/hydration of client-side apps is indeed frustrating. If the language you use on the back end has a way to compile to JS (there seems to be a JS-targeting compiler for a lot of languages these days, but I don't know about the .NET ecosystem), server-rendering becomes a lot easier by writing your front-end app in that language.
    This doesn't help you much if you already have an app and you just want to add server-side rendering to it, though. :-)
    Daniel Stuessy
    @dstuessy
    haha yeah, man. My knowledge of virtual doms is limited, but I was wondering if vdoms inherently require the original state of the dom to be re-rendered by the vdom. Any chance one could implement a vdom library that just extends the initial dom state?
    iambumblehead
    @iambumblehead
    Jorge Bucaran
    @jorgebucaran
    Also check out picodom? https://github.com/picodom/picodom
    Jamie Gaskins
    @jgaskins
    @dstuessy I just checked and you can pass the DOM node itself as the initial state to run the diff from (so instead of the first render being run with create(vnode), you do diff(domNode, vnode)).
    in fact, I just ran patch(domNode, diff(domNode, vnode)) and it worked just fine
    admittedly, it was a simple test, so I don't know what all the implications are. :-)
    Pepe Becker
    @pepebecker
    Hey guys, is it possible to get the value from a virtual input[type="text"], like vInput.properties.value?
    const textInput = hx`<input type="text" placeholder="Name">`
    textInput.properties.value
    
    const addButton = hx`<button>Add Person</button>`
    addButton.properties.onclick = () => addPerson(textInput.properties.value)
    Jamie Gaskins
    @jgaskins
    @pepebecker AFAIK the data only flows from the vnode to the DOM node, not the other way, so the rendered <input/> won't populate the textInput. What you can do is set up a hook to get a reference to the real DOM node:
    class Hook {
      hook(node) { this.node = node }
    }
    
    const hook = new Hook()
    textInput.properties.domNode = hook // It doesn't matter what the property is called, so we call it domNode
    
    addButton.properties.onclick = () => addPerson(hook.node.value)
    Pepe Becker
    @pepebecker
    @jgaskins, thank you for the explanation!
    walter0331
    @walter0331
    Paulo Sergio
    @PaulaoDev
    Hello guys
    Rafael Bitencourt
    @rafaelbiten
    I’m working with hypersrcipt and virtual-dom for the first time and I’m wondering if there’s a way to import and use .svg files with it. And just to be clear, I have an icon.svg file which is just a normal svg file that I’d like to use inside the virtual-dom / hyperscript project