The ability to reply to discussions is limited to PRO members. Want to join in the discussion? Click here to subscribe now.

Read effects from the DOM: click events

Read effects from the DOM: click events

6:00
So far we only had effects that write something to the external world, we are not yet reading anything from the external world into our app. This lesson shows how we can change the DOM Driver to return a "DOM Source" representing read effects, such as click events. We will leverage that to create an interactive application.
Watch this lesson now
Avatar
egghead.io

So far we only had effects that write something to the external world, we are not yet reading anything from the external world into our app. This lesson shows how we can change the DOM Driver to return a "DOM Source" representing read effects, such as click events. We will leverage that to create an interactive application.

Avatar
Steve

This video confused me... I think I see what you are doing but don't really understand the why. Why you would you want to put the DOMSource in the imperative DOMDriver? Based on your discussion in the previous videos I expected all Rx.Observables to belong in the logic/functional main(?).

What is the reason/benefit for putting some Observables in the Driver and others in main()?

In reply to egghead.io
Avatar
Andre

Hi Steve. Every Observable that represents an effect from the external world should be created in a driver. This is important later on if you want to test the main function. If we would create the Observable of clicks in the main function, you could not test the main function without involving real clicks from the user. But if the Observable of clicks is provided as an input to the main function, then it's just a function, you can provide an Observable of fake clicks and test if the main function still works as expected. That's what it means to have "main" pure.

In reply to Steve
Avatar
Steve

OK so if I think of drivers as abstracting away streams of input/output events; then would timer based observables would also benefit from being contained within in one or more "Time" drivers? Then one could test/implement activities from time based events without having to wait for time to pass. In this example you might want the screen to update hourly instead of every second. Am I thinking about this the right why?

In reply to Andre
Avatar
Andre

What you suggested is perfectly valid, but for practical purposes we can consider "Time" to be pure. If you give input streams, your output streams will behave always in the same way, even if you create Time-related Observables internally in the main(). But it's a good practice to put all created Observables out of main() and it may beneficial if you want to abstract away time from minutes and hours as you said.

In reply to Steve
Avatar
Steve

Thanks for helping me understand.

In reply to Andre
HEY, QUICK QUESTION!
Joel's Head
Why are we asking?