1. 8
    Simple drag and drop with Observables
    12m 35s

Simple drag and drop with Observables

InstructorJafar Husain

Share this video with your friends

Send Tweet

Armed with the map and concatAll functions, we can create fairly complex interactions in a simple way. We will use Observable to create a simple drag and drop example with basic DOM elements.

Stephen
~ 10 years ago

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!

Shawn
~ 10 years ago

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.

Jafar Husaininstructor
~ 10 years ago

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.

Thomas Burleson
~ 10 years ago

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

Nolan
~ 9 years ago

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

Chris
~ 9 years ago

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 :)

Angelo Moreira
~ 9 years ago

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

Nik
~ 8 years ago

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

Ray Dai
~ 8 years ago

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

Akshay Patange
~ 6 years ago

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

J. Matthew
~ 6 years ago

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.

J. Matthew
~ 6 years ago

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.