Simple drag and drop with Observables

I'm looking forward to the "avoid nesting forEach statements".

I have recently created a layered category filter for an array of products and all I seem to be doing is nesting forEach's.

This series is great!

Good series. Look forward to seeing Observable patterns for async requests.

Would like to have more big picture context for rx: where it is most commonly used, is there overlap with ES6, history and best practices of the library, etc.

The RX video was just a sneak preview to show you how the skills you are learning relate to asynchronous programming. The goal behind the Observable video was to give you the context you need to understand why we are learning how to program without loops. In the next series we will discuss asynchronous programming in-depth and you will get more context around Observable.

Jafar, This lesson with Drag-n-Drop and Observables is very provocative and valuable. For me, it presents a significant shift in perspectives to UX coding techniques. #awesome.

I searched your source and then online at reactivex.io to find out more about the ReactiveX method takeUntil() method. If anybody else is looking for more information regarding takeUntil, it is part of RxJS and you can find the docs here http://reactivex.io/documentation/operators/takeuntil.html.

Thanks again, Thomas Burleson

Jafar, great series! very relevant to collaboration web apps. Obvious applications with canvas and SVG

Jafar is a crisp excellent and amazing teacher, very happy to have watched his series on data-driven map/filter/forEach paradigm of Javascript programming :)

Thank you Thomas you just saved me some time, I knew I wasn't the only one wondering about takeUntil :)

What is the next series?Is it the one by Andre Staltz?

mouseDowns.flatMap is a good one as well, by bashing down one level.

Why is the Observable not listening on the mouseup and mousemove events on the widget? Why on the parent?

What is the next series?Is it the one by Andre Staltz?

I wondered that, too. It must be that course (https://egghead.io/courses/introduction-to-reactive-programming). It links back to this one in the description.

Why is the Observable not listening on the mouseup and mousemove events on the widget? Why on the parent?

It's probably intuitive that the mousedown event has to be on the widget to force you to click on the widget; that's the "grabbing" part of the interaction. But it's less intuitive why the rest.

The reason mousemove is on the parent is because of what the rest of the code does: it jumps the widget's top-left corner to the mouse position. So the position of the mouse relative to the widget changes - it was over the body of the widget when you clicked, but now it's on (or just off) the corner while you drag. Since the mouse is no longer on the surface of the widget, this breaks the mousemove event if you attached it to the widget, so the widget stops moving. Attaching the event to the parent ensures that as long as the mouse is over the (much bigger and static) parent, the widget will keep moving.

Note that it doesn't have to be this way. You could add an additional offset to the widget's new position, to keep the mouse over the body of the widget instead of at the corner. In that case, attaching mousemove to the widget would work.

As for mouseup, the answer is basically the same. Since the widget jumps to just off the mouse's position, it wouldn't register a mouseup. If you implemented the offset described above, then you could indeed attach mouseup to the widget. This might offer a better experience, in the sense that if you do manage to get the widget outside the bounds of the parent, you could still drop it, which you can't do currently. On the other hand, the surface area is much smaller, so it would be a lot easier to accidentally get the mouse outside the widget at the moment that you release the button, preventing you from being able to "drop" the widget. This is still a problem with the current implementation, though.