Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    GÁBOR Áron Zsolt
    @ashnur
    (monday is blaming day)
    vuejs/vue#2873 looks good lol
    Daniel Buckmaster
    @crabmusket
    @ashnur I agree, dom-delegator is still the most impenetrable part of mercury for me
    GÁBOR Áron Zsolt
    @ashnur
    it's not that complicated
    i think that mercury overconfigures this part, we shouldn't have magic that wraps the handlers, instead we should always wrap it manuall
    then you can just pass the handlerWrapper to the views and everything gets a bit simpler
    Daniel Buckmaster
    @crabmusket
    am I right in thinking that dom-delegator actually performs some kind of event delegation to save memory and not attach new listeners to every element? but that it needs support in virtual-dom to do this?
    GÁBOR Áron Zsolt
    @ashnur
    @eightyeight not sure if you still need an answer, but it's not because of saving memory
    afaik
    the crucial problem is that you want static views that can be serialized, however event handlers are not static most of the time they need some bit of state. so dom-delegator wraps events to solve this problem
    Daniel Buckmaster
    @crabmusket
    huh. I can't say I fully understand, but thanks, that makes it a bit clearer. I'd seen a lot of advice about using event delegation (in jQuery, etc.) on pages with lots of elements to improve performance, and the name of the module suggested something similar.
    Steve Lacy
    @stevelacy
    Question regarding large app state.
    I'm on a large (100+ nested views and components) mercury app and would like to 'split out' features into their own render loops.
    I am currently using a hook on load to attach the child view to the dom via appendChild.
    Is there a current documented way of splitting an app into many separate state atoms?
    Grant Callaghan
    @gcallaghan
    hey all, I'm trying to implement the drag handler like in the geometry example. however, I don't enter a render loop until the mouseup event so elements "jump" to position. does this sound familiar to anyone? anybody know what I could be doing wrong?
    Grant Callaghan
    @gcallaghan
    I was able to work around this
    Grant Callaghan
    @gcallaghan
    Looks like it was a difference in behavior between observ-struct and observ-varhash. changes to a varhash value did not seem to invoke a render call
    Grant Callaghan
    @gcallaghan
    @ashnur do you have an example of where you used datascript with mercury? I couldn't find it easily trawling your github repos?
    GÁBOR Áron Zsolt
    @ashnur
    @gcallaghan i will have to put it there, so far i only have it elsewhere, and the version i can share is not very complete because it was a constantly evolving project :)
    because i definitely wanted to use js-csp to hook internal communication up
    and i was running into problems
    then someone mentioned that the next level in this direction is the OTP architecture from Erlang ... :)
    GÁBOR Áron Zsolt
    @ashnur
    actually, i remember that it was @bodil https://twitter.com/bodil
    Grant Callaghan
    @gcallaghan
    @ashnur thanks for the links :smile:
    GÁBOR Áron Zsolt
    @ashnur
    :D
    Grant Callaghan
    @gcallaghan
    has anybody else run into a performance problem using observ-*? what have you done about it? I am attempting to create a moderately large graph in svg that is draggable. storing translateX and translateY and using the technique found in the geometry example lead to extremely slow performance when compared with a d3 implementation
    GÁBOR Áron Zsolt
    @ashnur
    svg will be slow anyway
    canvas is at least a hundred times faster (apart from firefox)
    i have not tried to use observ for large values because i was having issues with querying the data from it
    also, d3 is very well optimized, for such task, i would use d3 in all situations ;)
    this is also a "draggable" graph
    to some extent :D
    GÁBOR Áron Zsolt
    @ashnur
    @gcallaghan all that said, i am not quite sure in your case what would be the actual cause of bad performance...
    maybe there are too many updates triggering, and some simple event caching/collapsing/skipping would help a lot
    Grant Callaghan
    @gcallaghan
    @ashnur I tracked it down to the individual "sets" when have every node be an observable
    If the graph is a single observable, performance is equivalent to d3
    GÁBOR Áron Zsolt
    @ashnur
    well, observables are weird functions that have a method, and the whole construction is (IMHO) not very JIT friendly, BUT, this might be just tremendous bullshit, so don't trust me on it :)
    i am nowadays using datascript for anything that is just a bit large (although not for graphs yet, but will have to try it, i am thinking that it wouldn't be too slow :) )
    Daniel Buckmaster
    @crabmusket
    would be great if someone could help this person out Raynos/mercury#218 I don't have an active mercury project and my memory is lagging!
    Artur Slomowski
    @Tarvald
    @crabmusket Thanks :)
    Artur Slomowski
    @Tarvald
    i would be appreciated if someone who actualy use mercury would have minute to talk :)
    GÁBOR Áron Zsolt
    @ashnur
    @Tarvald ? :)
    I started to appreciate mercury just for being something completely different from almost any angle than conventional frontend frameworks
    Grant Callaghan
    @gcallaghan
    @Tarvald any luck with your table?
    Daniel Buckmaster
    @crabmusket
    @ashnur thanks for the presentation; I'll take a look sometime!
    I've been using Vue and its approach to state management is pretty cool. Maybe slightly too magical for me, but it's proven reliable. I wonder if it could be extracted and used in the place of observ
    It would eliminate the sort of 'I forgot' errors that can come from observ, at the cost of more under-the-hood magic.
    GÁBOR Áron Zsolt
    @ashnur
    can you be a bit more specific about why you like vue's state management? i have not had the opportunity yet to try vue.js
    i think observ() is way too clunky :)
    it was a constant struggle for no reason at all
    now i replaced it with constant struggle for some kind of reason :)