@eightyeight not sure if you still need an answer, but it's not because of saving memory
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
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.
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?
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?
I was able to work around this
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
@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
@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 ... :)
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
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 ;)