I'm trying to observe a 'drop' event and fire an alert when an element has been dropped into it. By setting draggable="true" on the div being dragged it's able to identify the dropzone but doesn't look good.
I'd like to be able to move items between dropzones and know what items are in which dropzone.
like this --- http://jsfiddle.net/rniemeyer/Jr2rE/
Here is my code ---- http://codepen.io/tomsapps/pen/pEBawQ?editors=1000
Thanks for taking a look!
@rpominov I bumped to a situation like this with Kefir:
stream .flatMapConcat(it => Kefir.fromPromise(funcThatProducesPromise(it))) .log('value')
One would expect that there would only be one
funcThatProducesPromise running at any given time, but for some reason Kefir calls the function that produces the flatmapped stream eagerly, and buffers the produced streams instead, effectively calling
funcThatProducesPromise as soon as
stream produces new value, even if the previous one is still running. To me this seems pretty confusing design choice, I think it'd be more logical to buffer the inputs and only call the producer function when the previous stream has ended (this obviously affects
flatMapConcurLimit as well). I tested the same thing with Bacon to see whether it's just me who feels this is wrong, but seems like at least Bacon does it the way I'd expect. I "fixed" it by making the promise-function calling lazy by doing:
.flatMapConcat(it => Kefir.constant().flatMap(() => Kefir.fromPromise(funcThatProducesPromise(it))))
But still, I'm wondering if this can be considered as a "bug". It can lead to quite substantial bugs as well, for example in my case I was implementing a worker queue with concurrency limit using
flatMapConcurLimit, and it worked fine when there weren't new jobs coming that often, but sometimes when multiple jobs started in short time, the worker queue ended up draining all connections from postgre pool, which caused the whole worker process to completely hang and not do anything. Nasty.
flatMapConcatdoes is correct, but there is a problem in
Kefir.fromPromiseAPI, it should also accept a function returning a promise, i.e. both
Kefir.fromPromise(() => promise)should work. I actually thought it's done that way already, but turns out it's not.
Kefir.fromPromise(() => promise)would call provided function lazily only when someone subscribes to the observable.
_spyHandlers) for debugging. Eliminating those when they are not used would slow down things when debug features are used, but would reduce memory usage when they are not used. Another example is the way
Dispatcherwork: a sequence of
addoperations followed by
removeoperations perform as
O(n^2)(https://accidentallyquadratic.tumblr.com/). That can be improved so that typical patterns, i.e.
removein reverse order of
add, run in
O(n)time. A third example would be that the implementation currently seems to create lots of copies of event objects unnecessarily. Avoiding unnecessary copying could give a performance boost as avoiding allocations really seems to be one of the keys to improving JS perf. Shall I create PRs for these optimizations?