[MUSIC]

>> So I need to participate in modern web conference today.

Got a lot to cover.

And so we'll jump right into it.

All right you all have this at the end so don't worry about writing anything down.

The only thing you'll want to write down towards the end is the email address, but

when I share the link it won't have that in there.

But anyone here, if you have a question about something that I talked about Or

just wanna e, e, you know, e-mail anything about JavaScript in general,

feel free to reach out to me directly.

I also love FontAwesome.

I started using the icons, realize I'd just give them a call-out.

I use it on all my projects and saw someone in the chat mention it earlier.

It's a blast.

I live in Iowa with my five kids and

my wife, and we're, you know, here at home right now,

so if you do hear any stomping or anything, it might be children upstairs.

All right, I work at appendTo, I'm not gonna belabor this point since Ralph

already covered this, but I love what I get to do,

work with some great people, I work from the comfort of my home.

So I really don't, I, just so many great things to say about appendTo and

I've really enjoyed the innovative things I've got to do while I'm here.

All right let's talk.

We're gonna talk about three primary things.

The DOM, we're gonna deep dive in the DOM events, kinda use it for a foundation for

messaging in our apps outside of the DOM.

We're gonna talk about the observer pattern and

how to use that with your objects.

And then right towards the end, we're gonna touch on the message bus.

This is certainly not gonna deep dive into architectural pieces about how to

arrange the entire, you know, entirety of your application.

All right, so, what is an event?

I went to the dictionary to make sure I could properly explain this and

this is what I found.

A thing that happens.

Especially one of importance.

Wow, man, I could, I could probably get in to writing definitions for

dictionaries if that's required.

A thing that happens.

So I found that very enlightening.

But it's true.

It's event is simply a thing that happens.

We have a lot of things that happen in our calendars.

We have a lot of things that happen in our life We share those with other people.

So in real life, we kinda understand the concept of an event.

But in the technical realm when we're talking about JavaScript events or DOM

events they're generally talking about a notification about the event I just wanna.

We're gonna be using the word.

I'm going to be using the word event today.

To use both together.

But really we're not handling the click someone already clicked.

We're handling the response to that.

And we're going to be able to respond to that notification.

And the same thing is true in our code.

We're not causing a, an event by announcing that it happened we're,

we're just notifying about what happened.

The important thing about an event is that it gives us voluntary visibility into what

would otherwise be an input only system.

I originally had closed system.

I didn't wanna be too specific.

Because a lot of times can have methods and really have

tight coupling between components that know about their internal methods.

But in general events give us that voluntary visibility into a unit.

Otherwise that would be operating on its own.

All right, so what do Facebook Twitter and Instagram have in common?

Well, they are your friends, or maybe not your friends, people that have added you,

and you've accepted that are notifying you about events in their life.

Again, it's voluntary.

You don't have to check those services.

You can voluntarily respond to those things, but these are a nice real-life

example of paying attention to things that happen, and then doing something,

maybe it's responding, maybe it's reading an article that was shared on Twitter.

But we have these examples in real life,

of things that are event-based, that we respond to.

All right, so, deep-diving into DOM Events, I'm sure this will be review for

many of you, but

there, hopefully you'll pick up things that you might not have known before.

If not, just to reiterate why DOM Events work is such a great platform for us.

You know, moving that out to our own application code, and

using some of the same patterns.

All right, a DOM event,

when you wanna be when someone clicks a button or it resizes their browser.

Xhr requests trigger events.

A number of things trigger events when we're dealing with HTML and the browser.

Going way back to early, early, early DOM specifications you would just add a,

a handler using an attribute and

then you'd have some sorta global function in your code that would do something and

you might even have the whole code right there in the onClick handler.

May not even be calling the function.

Obviously, big problems with this.

There's no separation between your HTML and

your JavaScript, so hopefully we're not doing that.

Anyone here's not doing that.

But it does, pollutes the global namespace.

There's number issues with this.

You can make it a little better by grabbing the element by its, you know,

an iclass name or id.

I just used id here.

And assigning it.

But it's still the same problem, just kind of changed a little bit.

Now we only can ever have one handler.

So if we attach it using this old method, which still works.

But if we attach it, and

someone else tries to add a collective event using the same pattern,

it would just remove ours, and theirs would be the one that gets used.

So this still isn't the solution.

So this is where, why we use addEventListener.

And I'll touch on the IE specific one in just a minute.

But this is why we addEventListener.

And there's just three parts: The event name, the callback that's gonna happen in,

and it'll pass a parameter with date details about that event.

And then the last parameter, which is going to signify whether you

want to have this execute in the capturing phase or bubbling phase,

which we'll talk about in a few slides.

This doesn't work in IE8 and under.

so, the cross-browser one, if you've been deep diving any of

the source code of libraries that abstract this, or maybe have written this yourself.

You test using feature detection, like Dave talked about earlier.

Say, does it have the method we want?

We bind the click handler.

And then, otherwise, we use, attach event, if it's present.

And that's the IE specific one for, again, IE8 and under.

The important thing is,

there's a lot of additional pieces here that don't function quite the same way.

The context of this inside of that callback attachment is not equal to

the element like you might be used to.

the, that doesn't get the parameter with the event,

that's available in window event.

So there's a number of changes which is why most of the time if

you're handling those older browsers using a DOM abstraction library like

jQuery makes a lot of sense.

Or something that does the same amount.

If you aren't targeting those versions, you're working in nine and

above, just use an addEventListener and then you can use both the capturing and

the bubbling we're gonna talk about, next.

Or soon, I should say.

Not next.

okay, so I'm, I'm coming into this talk with the understanding you've

probably been using events for a while in your JavaScript code.

You've been buying into clicks and mouseovers and

all these things to wire up your user interface.

so.

I'm going to just talk about some shared concepts because some of those same

concepts you're using will transition when we talk about messaging later in the talk.

The fact that it subscribed and

unsubscribed based on the event name that's a that will carry directly over.

We'll a lot of times call them topics if we're dealing with a message bus or

events with an event emitter.

But it's gonna be the same concept.

They often include a payload of information data additional meta

data about the event that happened.

This is a common pattern and

in a lot of times is why these events are hard to tell you that level of detail.

So you might be able to find out which key was pressed, on a key press.

[BLANK_AUDIO]

The event.

And then some, depending on what library your using to add events.

Some of them will give you the similar control over, you know stopping immediate

propagation or, or keeping or canceling it or changing default behavior.

Some of those will carry that over.

Your mileage may vary on the transferability of that.

Some of the key concepts.

That I wanna just deal with in this talk is making sure you truly

understand capturing and bubbling and,

and what happens where and for me, just understanding capturing really helps you

understand how jQuery can do some of the things it does, which is kind of cool.

And be able to do that in your own code, maybe without using the library.

One other challenge is just making sure you fully understand, based on that.

Event delegation how it works.

And then we'll deal with the specifics of,

of some other things with target and current target.

All right, so, we have a example structure here.

We're gonna start with our window.

Then we have our document.

Then we have the root element, which is HTML.

Then our body.

Then our header and then our logo.

So we have this structure of giving obviously just a slice of it.

But we'll use this to talk about capturing and bubbling.

So if we add an event listener to one of these elements using click we'll pass it

call back but we pass true instead of false.

That's that final parameter.

If we pass true it's going to capture an event during excuse me,

it's going to trigger the call back during the capturing phase of the event.

And this goes back, there's a huge history you can read about it on quirks.

Quirks mode on his website it talks about the history here.

But the idea is that it will start capturing starts at the top

most element in your, in your Dom.

In this case is gonna start with window, then document,

then go on down until it gets to the element that you started the event on.

So it starts, starts at the top.

Works the whole way down to the element that you might've clicked.

Which would be logo link.

Before it then switches and bubbles, which is the other direction and

then goes the whole way up.

90% of the time when you're doing something if you're using jQuery any of

those other pieces, you're using bubbling.

So that's where,

if you're already familiar with delegation and attaching handlers higher up.

You're expecting the event to move up and eventually get to where you can handle it.

Capturing does the exact opposite and happens first.

So it starts at the top, works its way down, and stops and

goes the other direction and works its way back up.

This is really cool we'll do a quick demo here.

I'll move over to the screen you're on.

If I click out here, just in the document, you're going to see it triggers on HTML.

I'm going to click this again, it will go away, so let's pay attention.

Capturing on window then document then HTML, and then it reverses and

goes back up.

I add the header, which is from our example.

We get Window document HTML header.

And then it goes the other direction back up, and that's the bubbling phase.

The whole way down to our anchor, if we had it included there.

So it gives you two different times where you can handle that event.

Once on capture, on the way down they're on the way up.

It's important to note, I'm gonna go back two slides here,

when you do provide this, if you're not on the element that was clicked.

So if this wasn't being bound to that logo, and it was one of the parents,

it will only fire this callback during the capturing phase.

In the bubbling, if we had it on one of the parents, would only fire the call,

callback during the bubbling phase.

If you had a event list and with either false or

true on the actual element that was clicked, it wouldn't matter.

It's gonna fire regardless because it's the during the context switch between

capturing and bubbling is when it's on the element that it was triggered on.

So whether you put true or false in that setting, it's going to work.

Either way.

The important thing here to know is that not all events bubble and

if you've been using JQuery a lot and it abstracts some of this and

makes all of the events bubble, you may not be familiar with this.

But not all events bubble.

You can check that using your event parameter, and

I just have mine named E here but you can just name that and

check for e.bubbles and it will tell you whether or not that event will bubble.

So if we attached an event listener or

focus to an input, it's gonna say false, that will not bubble by default.

And that's why jQuery gives you focus in and focus out.

It gives you that ability due to the fact that it won't natively bubble.

However, this is really cool, events that do not bubble can still be captured.

So if we were to add a focus handler to the document and

put true in the second part.

True right here.

Then when we input, focus on an input the document level so

in a way delegated it will pick up the fact that, that input has been captured.

And if you go and deep dive the source code of j Query you'll see that's

exactly how they're able to implement some of those.

Features that other, otherwise wouldn't bubble.

So that's kind of a, a fun thing but it's something you can use as well when you're

in those edge cases and you just can't get access to something that you need.

StopPropagation is literally just saying once it's on its way up, stop.

And so, if, if an element was chosen, and you said stop propagation on

that callback, the parent would not receive a notification about that event.

The difference between the two, stop immediate propagation, is that any

other event listeners bound to that same element would also be stopped and

they would not fire.

So, if you had three click events mount at different times in the first one

calls stopImmediatePropagation, the second two would not fire.

Now, as a gotcha Oh, you know, what,

we're gonna talk about the gotcha in a minute where the event delegations are.

I'm jumping ahead of myself.

Events bubble.

Right? I discovered that in the last few,

few minutes here.

Why is that useful?

Now that's where event delegation comes in.

And I'll read this right off the slide but it's the practice of leveraging event

bubbling and adding a single event to an ancestor.

You know example would be the document.

Instead of adding multiple events directly to the children.

So here's a picture of that.

If we had all these child items and we attach click handlers to each one of them,

we'd have to first receive a reference to them.

And then be able to attach the click handlers to each one of those.

As opposed to we could attach one flick handler to the container, and

it would automatically because of event bubbling,

get access to all of those separate click events.

So event delegation is really powerful.

It's a great concept to make sure you leverage in your code to

keep things clean and fast.

Some of the modern day frameworks do this for you automatically.

Back1 I know is one of them.

React from Facebook does this automatically.

And theirs is even more complicated cuz of their it's a,

it's not even, it's a synthetic events system.

Some of the benefits, I'm not gonna spend too much time on this right now,

but there's less DOM traversal during setup.

You're not having to get a reference to each item that you wanna apply an event

handler to.

There's no cleanup needed when the child elements are removed.

You don,t have to stop listening or, or unbind something.

New child elements work immediately.

So if you're loading data in via Ajax or using local templating all of those

event handlers don't have to be bound and rebound for that new code to work.

As long it matches the selector or

the test that you're running against it, it will work.

If you're familiar with JQuery and you've used delegated events before then you

might find this next part interesting because we'll I'll show how to do it

without JQuery, and so you can kinda get an idea of what it's doing.

It has a little bit more streamlined, it has a number of tests in there for

browser support and it will use things like matches and matches selector.

Where I'm just gonna do simple tests based on tag name or or maybe an attribute.

A lot of code here.

But we'll talk through it a little bit at a time.

So this is the code that we'd be running.

This would at the end of the day,

where it'd be attaching to the document click handler.

That we're looking for a button that has an atribute of data ID.

That's the longest road of what we're doing.

And then it's gonna do something with that ID.

So, the first step we're gonna have is we're going to bind an event handler to

the ancestor element.

So, in this case the ancestor element is document.documentElement.

This is a quick reference to each HTML.

So, you don't have to do find owner by tag name, or

do anything crazy to get the HTML element.

Just document.documentElement is the HTML element.

And is available as soon as you have code running.

So that's the first thing, we'll attach a click handler there, and

we'll make sure we have e so we can have it available, so

we can interact with the event object that will come through.

Then we're gonna try to decide as quickly as possible,

because this will handle all click events on the page.

We're gonna try to handle as quickly as possible if we want to do

something with this particular event.

So the thing I'm using here is,

I'm grabbing the target which we'll talk about in a minute.

Look at it's tagging, making it lower case because there will be a difference in

what that is name using a an XML base document versus and HTML bas document.

So, my check for being button.

And then, the next thing I'm gonna do is try to get it's data ID and

it doesn't have one, I'm gonna return.

Now, if we wanted to there's.

A rel, you know, it's not rel.

It's not super new.

But it's another way of doing this is a lot faster which is calling matches.

In the latest version of Chrome and Opera, you can just call matches.

In older versions you can look at can I look at details on this?

But there is available VF prefix.

So for IE9 and up, you can do this.

While there is MS modem web kit.

And that's another great use for modernizer to be able to get

the correct prefix for the uh,for method that you wanna use.

But, in this case, all we have to do is call target matches button and

say, does it have a attributed data ID?

If it does, then we wanna handle it.

And then I can confidently get the id and then do something with it.

So it kind of shortens up our code considerably.

All right, finally the last thing we're gonna do is cancel the default which if we

were delegating on a link for instance or

a button that would've submitted a form, we can prevent the default.

We obviously don't want to do that at the top of our method before we know if

we should be handling the delegation.

This is at the point at which we're back to almost using a normal event handler.

Once we've ruled out anything that doesn't match what we want we know we have it

now we can kind of continue as if we're a normal event handler.

One more thing, I won't belabor this for sure.

When I share the links later there's a link to an article I wrote years ago on

fourier coding that explains why and when you might want to use the term false or

when you're not gonna want to use it.

And so you can read that.

But it, long story short will stop propagation and

prevents default which breaks delegation if you're planning on using that.

All right, so one of the challenges with event delegation, one of the challenges

here is that if you were to have a click event that you want to handle

on this lowest level, let me actually select from the screen you can see,

the lowest level here, and you wanna delegate it to document.

But you wanna stop propagation so it doesn't maybe trigger a run on body or

trigger a run on HTML.

You can't do that.

Because if you consider bubbling, even though it's fired here,

that's the source element.

It's gonna, by the time your handler gets it,

it's already propagated the whole way up to the document.

And now you're handling the delegated version of that event.

So stopping propagation will keep it from moving to the window, but

it wouldn't stop it from moving up the tree here from header to body in HTML.

So that's one gotcha just to make sure you pay attention to.

The second one is that target, event target.

It may not be what you think it is, so let's talk about what that is, and,

and what it means.

Target is a reference to the element where the event originated.

So if you clicked on a link, it would be the anchor tag.

If you clicked on a button, it'd be the button.

Current target is a reference to the element that holds the event listener.

So in that case, it's document if we bound to that or one of the parent elements.

It will be the same as this, unless you've actively changed the.

Context of your callback, which happens when you're using it with a library or

with a component.

So e.currentTarget is the object that's the parent.

That's the one you have event delegated to, and then target's different.

There's some notes, if you're using attach event,

there's no equivalent to currentTarget, and

there is an equivalent to source element, which is available on window.event.

Let's look at some more code here.

So here's where I'm gonna use just a few Bootstrap classes for

our button, so it looks a little nicer.

Let's talk through the code, we're gonna grab just using query selector to

grab a single reference to this outside wrapper.

We're gonna add an event listener so we're delegating and event to this wrapper.

And we're gonna just check to make sure we clicked on a button, and

then we're gonna display the date.

So something very simple.

We click the button, the date's displayed, but we're doing it through delegation.

Run the demo.

Click the button, and I see the date, which is great.

This is what we want.

We click here.

Again, it doesn't work.

And so it's somewhat sporadic, we don't know why.

But let's go ahead and

check our, our we'll do some debugging here in the browser.

So again alert is not a debugging tool, unless you really, really need it.

But console log is.

So we're gonna use that.

We're just gonna, instead of doing anything else in here,

we're just gonna check what's the target, and what's the current target.

So if I click on the, this DIV out here that we're binding to,

it just says the target is DIV and the current target is DIV.

If I click on the button, you'll see it targets the button.

But actually I was clicking on the icon, and that's where our problem was.

Because the icon is not a button.

A parent of the icon is the button that we're interested, interested in.

Well, you're not gonna like the solution.

This isn't a, this isn't a good solution.

This isn't something I would use in production.

I'll show you.

It's a much more complicated, you'd abstract this out,

and once you've started going down that road, you should just use a library, and

I'll show you how to do it in jQuery.

But in this case I'm just gonna check whether it's a button, and

then I'm gonna check whether the parent's a button,

cuz I know that there's not gonna be multiple nest elements in my button.

So yeah, I am using the word target a lot.

I see that in check.

[LAUGH] Anyway this will fix our problem because we're checking whether it's

the icon or the button in, in both will work.

So now, once you've seen how to do it all yourself, this is why you go back to

the library and say wow that looks a lot whole cleaner, and it does it all for me.

So this is what it would look like with jQuery.

We just have the click event.

We checked. This would be the selector.

It's gonna put through to make sure it matches that selector.

And then if it works it will, it will run our, our callback.

So in this case this works out of the box of what we'd expect it to.

But I thought it's important that you know how to do it yourself,

if you ever need to.

Or just to understand what's going on behind the hood in some of

the abstractions you might be using.

All right so, just went into the very detailed pieces about targets and, and

bubbling and, and delegation.

But let's take a step back now and look at, we use these all the time right?

How else would we interface with our controls on a page if we

didn't have events and then the methods to control them?

One thing we never expect though is that a button on a page is gonna reach out and

talk to some of our internal app code.

We don't ever have that expectation.

We know that it's going to concern itself with what it needs to do, and

only what it needs to do.

So that's a great pattern where it's completely self contained it has a single

responsibility concept built right in and it's not gonna

do anything with our internal code, it has no knowledge of how it's being used.

It just, knows that it needs to work a certain way.

Which means our, we've also learned that components that expose meaningful events

are easy to work with.

So that's the output from the component, our meaningful events,

whether that be a key press or keydown or

keyup in an input field or whether that be something more abstracted.

Like a return to a XHR response.

But its gonna give us these meaningful outputs.

And then they also take a meaningful set of inputs and

that's the method API that you expect to work with.

And this is where our frustration lies between output and input, and

cross browser compatibility when they don't do the same thing.

When an event in one browser gives you more information or

gives it under a different attribute, in another browser And so,

when they're consistent and they work, man this is how we build stuff.

So that's fantastic.

These are great patterns.

It's interesting that this pattern has a name.

And the question is why don't we write our code like this everyday if it's so

great to work with.

We don't have an option with browser code.

We can't dig into the internals and do something different or

expect it to do something different.

So why don't we write code like this all the time?

Well it's called the observer pattern, and

it's when you have a reference to another element, and then you indicate that you

want to be notified when it has an event that you're interested, interested in.

So the object itself, that's holding all those subscriptions or,

or that will be triggering the events, doesn't care.

About who's subscribing, it just knows that someone subscribed, and

they wanna know when I trigger the event click.

Or when I trigger something different.

It doesnt' care if there's 100 or one subscribers.

It doesn't, it just honestly doesn't care.

So that item can be completely self contained without any knowledge of

who's doing the listening.

But can just broadcast those information, that information when it wants to.

All right. One major difference.

Just wanted to clarify this, that these events don't bubble.

Normally when you're dealing with events on components that

you've written yourself.

Maybe you're using a mix-in that will provide an event emitter,

something that you can use with your code.

They're not gonna bubble.

There's no document hierarchy for those to bubble through.

A notable exception, will be Angular.

If you're using their event system is built in a,

a structural way that reflects very similar to how the DOM works.

that, the other point of this is that delegation isn't something that,

technically delegation.

Well or key there because there's no bubbling.

So we use a message bus instead of delegation when we're

dealing with pure eventing and stuff like that in JavaScript.

All right, you're heard the term Pub/Sub or publish and subscribe.

Technically the observer pattern falls into this category.

But I, it does, I mean it clearly falls into this category.

I tend to use Pub/Sub when I'm talking about a separate message bus.

And event system is what I'm talking about.

You know what we might expect from a DOM event, or

from backbone events and so forth.

So it certainly publish and subscribe, you're triggering or

publishing an event and then other people are subscribing to it.

But if you hear it used a lot,

it may mean something bigger like a message bus as opposed to true eventing.

Okay, so here's where it's gonna be fun.

We're gonna jump into a, example application.

We're gonna build not actually build.

But we're gonna walk through it as if we're building it.

And kinda think through how we can try to integrate,

some of these eventing systems into our code, and see how that looks.

The nice thing is, with the observer pattern and a good API,

we can build our sites and applications as a collection of these discrete components.

That communicate with each other, using methods for input and events for output.

Of course we can use this pattern with non-visual components.

So those events don't have to be user interactions, it can be you know,

something from a web socket,

it can be one of your pieces of code is firing on, on a timer.

Any number of things can, can pose these events.

All right, so, why would we even bother, to add this to our code?

Well, components that are standalone, like I'm talking about,

I'm gonna walk through building, they're testable.

They don't require a huge infrastructure to test,

you load up that component, you test it's inputs.

Test the expected outputs, and you're good to go.

And then, of course, the components can be tested on their own, or

maybe tested how they integrate with your code.

But they're very easy to test.

They're completely separate.

And hopefully you guys,

when you're writing JavaScript are able to unit test that code.

So you have confidence in what you're doing.

It's reusable.

When a component knows intricacies about another component,

it has to always be used on tandem with that component,

unless you're building a lot of conditionals in there.

So our goal is that we have something that is able to be reusable, and be able

to maybe use throughout your application, not necessarily on another project.

It may be specific to your app.

But at least throughout the project without this brutal nature of oh no I've

gotta make sure I load that, and load this and then all of it will work correctly.

[SOUND] all right.

The example application we're gonna build which after I

gave a talk that included this application in Vienna and

someone told me apparently, all illustrations are of video searching apps.

I didn't know that, but it actually works really well for what we're doing.

so, we're going to work through building this example video app.

So you see we have a Search bar at the top,

it's gonna show us movies at the bottom.

Maybe you know things are gonna open our theater, whatever.

It's gonna show us that response.

And then when we click on one it's gonna show us a Details tab,

which is gonna look like this.

So it's, you know a very simple interface.

We've got the Search field, the Search button and then our Result view and

our Details view.

All right, lots of code.

We're gonna step through it, don't be overwhelmed.

Walk through it one by one here.

But this is the code.

This is just for the searching, that I'm showing here.

And then we'd, we'd have code for the other part as well.

But so here, don't take this and go write an app that looks like this.

I'm starting somewhere that would be where there's no components.

There's nothing that's been separated out.

It's just straight jQuery code.

So this is where we're gonna start and then we'll move toward a separate

components that admit events and accept inputs.

So, as we step through this.

Here's our search form.

We're just listening for the submit.

Please never bind to the click event on a submit button.

You can either bind to submit event on the form.

That way the user can't accidentally submit the form.

Then we're gonna prevent defaults so that form doesn't send to the server.

We're gonna look up our query variable which is the search field.

If there's not a query we'll return it.

We won't do anything else so

they can't hit Enter in an empty field and have it ex, execute a search.

Finally we're going to make our AJAX request to our endpoint here.

Passing the query.

And wait and handle the results all in this method.

And that's where, just assume between those three dots that you're seeing here,

that there's a magical templating library that's taking care of RenderMan's force.

I don't wanna get bogged down in the details here.

And then we're finally setting up for HTML and, and to, to stage point from earlier.

Hopefully at this point this is trusted HTML from our server,

not user input each time.

Okay. So just to reiterate what happened in

a visual way, clicking the Search button gets the search query,

ensures that one was provided, executes the AJAX request, and renders the results.

That's a lot of stuff for a Search button to do.

And then clicking on an individual movie fetches data over Ajax,

renders the results, and then changes the tab to show the details.

All right, so obviously there are some issues here.

We can't test any of these pieces on their own.

Just to test the display of results, we'd have to fill in the search box and

trigger a click, on the Search button.

That's the only way we could do it.

We'd have to simulate a click on the Search button,

after having filled in the search box and

then we can see if the events rendered correctly, the movies rendered correctly.

We'd have to have a live endpoint running, which isn't that's an issue, but

the mock, we can mock a request.

We certainly do that quite a bit in front end development.

And then that's all just so we can verify that the rendering function works,

cuz it's nested so deeply into that code.

And then to change our Details view maybe from a tab to a dialogue we'd have to

change the event handler for an individual movie.

I didn't show this code.

You can imagine,

if we have code that looked like that the rest of it would be similar.

And clicking on an event is the thing that shows the details.

Now the event for that click is responsible for

rendering the details which, as you say that loud you start to

realize this doesn't sound like a well architected piece of application.

All right.

Does it work?

Yeah. Theoretically it would work just fine.

As long as it didn't get anymore complicated it would work.

Can we make it better?

Yes. And that's what we're gonna talk

through in the next little bit.

All right so the first thing you'll wanna do is take a step back,

instead of just saying I need to wire this to this and do this to that, we wanna take

a step back and identify what components, what pieces are we going to need.

I do wanna call out,

I'm not talking specifically about the spec web components.

I'm talking about just modularizing your code into reusable chunks.

So just, I don't wanna get anyone caught up in the terms.

All right. So if we look at this,

we see there's this area that's related to Search Query and Execution.

That's one segment up at the top.

We have our Search Results for you.

We have a Details view, which I don't show on this screen again, but

you saw that earlier.

We have the Details view.

And then we have Tabs, those are just great,

they do one thing, which is switch between views.

And we've seen two different ways to do tabs today,

so you should have, plenty of ways to do that.

And then you may or

may not have a movie object depending on how complicated your app might be.

But we could potentially have something that's called a [INAUDIBLE].

Excuse me.

All right, so when we're at these components, we want them to have to obey,

a focused use which is called the single responsibility principle.

Where right now,

in our previous version here that we just showed, the Search button.

Are the form being submitted is responsible for getting the results and

rendering them and validating the query that was entered.

So it's doing a lot of things.

Nothing's related directly to what would visually appear to be its use.

And then we wanna make sure that whatever we build has a clear public API.

That's in the, it's not public in the sense of users using your app but public,

in the sense that the rest of your app can depend, that it has these methods and

fires these events.

So let's talk about that search component.

That's the one at the very top.

What is its purpose?

When we really sit down and look at it, what's its purpose?

Well, allow the use to enter a search term.

Make sense?

Start the search.

Okay it's gonna trigger the search.

Ad it wants to continue to display the search term, once the search is rendered.

So we don't wanna hit search and have the term go away.

We want it to be kind of at most like a header, and

show us what the results are for one that we're currently looking at.

The thing it is not supposed to do, it is is not supposed to request data, or

render results.

That doesn't make sense for a search component to do.

It would be like an input making AJAX request in html.

We just wouldn't expect that to happen.

So our search component, that's not part of it's core purpose.

So we see it's going to output, we're,

talk about the output first it's gonna publish a search requested event.

And this can provide the term hobbit.

This is our, not always hobbit, of course it will be whatever it searched for,

but, hobbit's a good term.

So we'll have search requested, and

then the term will be whatever they searched for.

That's when a form's submitted, and when it's filled in.

So, we wouldn't do anything if the form was empty or just blank space.

The input, it's gonna take two methods.

One is set search term.

That will set what should show up in that box, but it won't trigger anything.

And then trigger search.

And this allows us to programmatically,

cause a search to happen without filling in the input and clicking the button.

Right now we're using methods through an API.

It's a lot cleaner, and doesn't require our,

the rest of our app to understand how the internals of this component are running.

Okay, here's the internal responsibility.

That was the external responsibility.

That's what you have to maintain for the rest of your app.

Internally, we'll listen to the submit event on the form, and run triggerSearch.

Now we have a method to run, to do this.

The triggerSearch method can retrieve the value of the search box.

Make sure a value has been entered.

And then publish that message force.

Okay, so taking a step back, how do we publish the event?

Being somewhat, this talk being somewhat framework agnostic I'll show you how to do

it in Backbone and then I'll mention how to do it in angular.

You can of course do it a million different ways.

But at the end of the day you need a library that has an event emitter built

into it or you need to load an event emitter,

and I'll show you one called monologue in a minute.

So you need something that has an on, an off and a trigger or emit method so

you can subscribe to events, unsubscribe from events and

then have a way to trigger or emit those events.

So there's plenty of libraries out there that do this.

Some of them have it built in.

If we looked at it in Backbone I'm not showing you half of the code here but

you can imagine we have a backbone view,

there's a render method somewhere else that's doing stuff, and in here.

You're going to, when we click Trigger Search and

we, when we make that happen, we're going to grab our current context, which is

going to be the root of the control, find that search field, grab its value.

If you're working with a model back view,

you're just probably gonna get that off the model.

We're gonna use jQuery's trim method to go ahead and

just remove any blank space that might be in there.

Make sure a term exists.

Which is this line here.

And as long as there's a term that exists, we're gonna allow the code to continue.

And we're gonna call this.trigger, search.started.

And actually I meant to say requested here.

But search.requested with our term.

And that's how that will output Let me do this so

I don't have to remember to do it later, a second.

One of the features of the Blazen is this, requested.

There we go. See?

It's like I never even made the mistake.

All right so this is search requested.

And this will trigger that for our element.

If you're using something like Angular I know a lot of people are using this.

It has a concept of a message, or excuse me, an event emitter.

You can use emit on your scope which will publish an event up the scope hierarchy,

the whole way up to the, to the root.

You can use, if it's not stopped, somewhere along the way, broadcast,

which will take the context element and go the whole way down to any bits children.

Which is something that we don't really have a parallel with in the DOM

eventing we're looking at.

At then of course, if you really needed the root level and

everything you could go to rootScope and then broadcast it there.

If this doesn't make sense to people who don't use Angular, it's okay.

It's just meant for those who do use it to know how, how to where to find it.

And I have a link to the documentation, so

you could read more about the event emitter that's there.

And I didn't do it.

And I wanna thank Jonathan Creamer for helping me.

God, help with that aspect and making sure that that is useful for everyone.

A monologue is a completely standalone event emitter.

I use Postal, which is for a message bus.

And Monologue is kind of a companion library to that.

So it's something you could check out as, as well.

All right. The important thing.

Take the step back.

We've looked at everything.

We have these components.

The important thing is that you honor that external contract.

The events that you're gonna publish.

And the API that you have.

As long as you keep that consistent, you can change the internals of

that control 50 million times in your app and you won't break anything as long as

you publish the events when you should and you accept those two methods we mentioned.

So, now you can't look at it anymore as a search box and a button.

It's the search control.

It's like, the table.

It's like the form.

It's, it's a single component that does a single use, and here's its API.

You have to honor that or else this all breaks down.

Soon as your search box and button reaches out to a parent element and

calls some method it knows about, you've broken the, the reusability and

testability of your code.

So make sure you honor that external contract.

All right. We're not gonna go that deep into each of

the other objects, but we can expect that our

Results view would accept a method that's called updateResults.

And that's gonna pass in the data from the server.

That will, it will then be in, responsible for rendering.

Will have an output of movie selected, so when you do click on a movie,

the Results view is the thing that's gonna output that event for

you, knowing that a movie's selected.

You don't have to bind an event for your app, directly to that movie.

We'll have tabs that will maybe accept an input of changeTab, and

you can give it the idea the tab you wanna go to.

And it's gonna output when the tab.changed.

The code that I'm gonna show, the pseudocode, doesn't use this one, but

this makes sense.

You'd wanna know when the tab changes.

And then final the detail view is just going to have one piece which is

show movie.

We say show movie and give it some code.

It's gonna know how to run through that and properly display it.

So now we've kind of split this up into these components.

We have a tabs, search control, our results and details.

We have these separate components now that we can use.

And this again using any number of object patterns here.

As long as you have an event emitter, you'll be able to do this.

All right, here's what our updated code looks like.

It's a lot easier to understand.

We remember, keep in mind these variable names, tabs, search, results, and

details, cuz this is kind of a continuation of that code.

So if we listen using event emitter to the search requested event We can wait for

that, and under the data its gonna have that permit we need.

And so we can make an AJAX request with that term.

When Ajax results come back, we can tell our results to update the results.

We don't care about how it's going to do that.

We don't have the rendering logic in here like we had before.

We're just going to put this in here.

We could go even further and do something like amplify request using AmplifyJS to

abstract out that Ajax request.

There's a lot of things you could do, but this cleans it up considerably.

Now when a search is requested it will change the tab to results,

which that's the one that's showing.

So if details was showing before it will show the results, make our Ajax request,

and then render those, render that data.

Now the same thing for movies selected.

When a movie's clicked we're gonna change the tab to details, make a request for

the movie and then you show the movie.

But if you sit someone down here and they look at

this they don't even have to understand what your dom structure looks like.

They can read, read this code, understand what's going on and then when you need to

make a change to the detailed view, you're not looking at the event handler for

movie, you're looking to the detail component.

That makes it a lot easier to find where things are going wrong and

where you need to fix it.

All right, this is better, right?

There's probably more code now than there was before but

does it meet our needs of being maintainable?

Yeah, you know where stuff is and it, it has a single responsibility.

Is it testable?

Absolutely, these components are far more testable than they were before.

And it's even reusable.

We can use that search control to do other things throughout the app, and

we could make it even more generic if we wanted to.

So it gives us a lot of benefit for what we're working on.

All right.

Talking about earlier, with the dom event, event delegation is, is great and

you can do all this cool stuff with it.

Can you use it with event emitters?

Well, in. Let's talk about what delegation gets us.

Cuz I say in a general sense, yes, but I told you earlier you couldn't.

So let's clarify what I mean.

Delegation gave us the ability to listen for

events without a direct reference to the element.

So we could add, add the event handler higher up on the dom, and

then the event would bubble up.

And it also allowed us to filter what we wanted to do based on

characteristics of that element, and we can do that with delegation.

When we're talking about eventing and

doing this apart from the DOM we use a thing called a message bus.

And there's a number of different names for

this event aggregator, mediator, message broker.

They all have the same concept though,

which is they introduced a shared object that is used to

communicate between components instead of requiring a direct reference.

Because right now our

app required a direct reference to each of these components to wire them up.

Which is fine.

It's a great pattern.

So our app we'll come back to that slide in a second.

But our app looks like this.

There's the app then it has referenced each of the controls.

The message bus works like a shared observable object.

So it's going to have events that are emitted.

We call those topics generally, or messages rather, and

then the event name we call a topic.

The methods for these are often different, so unsubscribe, subscribe, and

publish, that's where you get kind of more of the pub/sub terms.

Though they certainly can still have on, off, and

emit as the API depending on the library that you're using.

But it takes our app from this and makes it look like this.

So, instead of everything, the app having a reference to everything else,

these items will have reference to that global message bus.

And then could publish something on the bus that then the app could pick up and

go back the other direction.

Again I mentioned we wouldn't go too deep into this but there are some differences.

One thing is that your methods need to support now,

your objects rather need to support being called via an action message.

When we're dealing with events on objects traditionally those aren't actions.

Those aren't going to say things like start search or, or

some things very specific like that.

They're going to say this happens.

So search requested or form submitted.

Anything like that.

That's kind of an event.

Message bus you now need to be able to process inputs through the same

channel that you're sending the outputs.

And that's where you get action messages like search trigger and

maybe that would handle that method trigger search.

So the action message, it needs to be kind of wired in and there's ways to do this.

But you, it's one difference between a true event emitter and

then something that can handle inputs through that same event emitter.

Two libraries you can check out.

One the AMPLIFYJS, the one appendTo's written.

And that one has a very simple pub/sub.

It kind of gives you that shared object.

There's someone, I can't remember the guy's name,

he tweets a one that fits in tweet.

There's another very short one that's used by quite of few people.

For message buses, things that are shared that way.

Postal.js is the one that at appendTo we traditionally use.

It gives you a lot of power.

It has it basically matches if you've ever used RabbitMQ or

something like that on the server, it has the same wildcard matching support.

It gives you a lot of power when you're building complex apps to put

those things together.

So those are some libraries that you can use.

All right, we are coming to the end of a large number of slides.

I just want to reiterate if some of this was new information.

Kind of putting it all together, what would be a good next step?

If you don't group your code in components at all right now and

you just kind of have that initial example where you have a lot of jQuery code that

maybe runs in document.ready and tries to wire everything up.

Just start looking at your application based on components.

Start breaking it up into reusable components, making it easier to maintain,

easier to test.

That's a great next step.

Don't worry about the message bus.

Maybe not even about the event emitters yet.

Just try to break your code up into more usable pieces.

If you already are doing components, but really aren't using those events, and

you're kind of one component knows the internals of another component and

they're interacting with each other that way.

A great next step would be to get an event emitter in there,

maybe you already have one, you're just not using it.

Get that in place and start using that to kind of separate the, the logic.

So this child component doesn't have to know about the internals of the parent.

That's a great next step.

And if you're already doing those two things you have components and

they're of using event admitting but

you're not using a message about something that's more global.

Look at your app.

See is it complex enough that it makes sense that I want to

have these as truly separate components.

The tool we're using here, Blazen, it uses a very complex message bus.

And part of that is we're forwarding information through, and

back out of an iframe.

And, it's filtering that for content, making sure the stuff correct.

But we're running everything in a sandbox, but

allowing people that are logged in to make edits from the parent page.

So, because we go through a message bus, and everything serializable,

we can send it directly to the other frame and back if you go to the server and back.

There's a number of things you can do when you use a message bust that you

just simply can't do another way or, or as cleanly another way.

There's a lot of really cool stuff we can do, but

that's it that's what I had for you.

I hope that there's some questions that I can answer.

I've actually got done on time which I was worried about given the number of slides I

was going through.

Any questions that I could answer?