Handling Multiple User Interactions

[00:00:00]
>> Next user action, thinks back, next user action, type. Can you see this type? Is the user is gonna type? I don't know, let's have something more interesting than Hi. I like Ian, Ian the user is gonna type Ian.
>> Let's go.
>> Exactly.
>> Let's go.
>> Let's go Ian.

[00:00:22]
And we know actually this was me. I, that's gonna trigger the handle input function run, but just keep it more interesting. We'll have it, grab the whole each time it runs anywhere to be updating the value and running through and adding i to the pose and then to the div.

[00:00:41]
So we'll do start with Ian, typed Ian into a field because you cleared it now. My pens, because you've cleared it now. And so immediately on the DOM Ian shows up. If only we could grow it from here and stick it on this div, if only but we can't not.

[00:01:02]
Instead, fortunately, another event is going to trigger this handle input function to come on to, I needed to wipe our handle click from the callback queue, and then clear our call stack, and we get our handle. Well, I'm not gonna write it here, it goes into the queue and handleInput goes on to the call stack, there it is, handleInput.

[00:01:33]
And our orange is back to mark that this is being handled by JavaScript. And add it to the call stack it goes. And now our handle input is gonna be executed by JavaScript. A brand new what everybody?
>> Execution context.
>> Beautiful, a brand new execution context. Perfect, and into it we go.

[00:01:58]
Where we are going to update our JavaScript data. With, okay, let me track through this. With our current, we've got no current, we gotta go get using the value getter. JsInput.value is a getter of the associated corresponding C++ DOM object input, we get the value. It comes back as they go in.

[00:02:37]
And then that will update our post value, poster value in JavaScript. So there's Ian, Ian is now safe to post. Beautiful, look at that. And now we are going to update our-
>> [LAUGH]
>> We're gonna update our text content setter to take that post. Now, with a value of Ian, and we're going to set it on the DOM element as the value of text, Ian, there we go.

[00:03:22]
And then that will show up on our view for the user. So that has updated what the user sees in the div. Anyone read why we were doing this I literally can't remember between the pen episodes of the past ten minutes? No, I'm kidding. So we now have a more complex, to be fair, maybe that's a good thing.

[00:03:48]
Because we now have a more complex UI. We are starting to struggle to think about how it's doing its work. We have had to flow the data back and forth. This already, even with two elements, even with two handlers, is becoming harder to reason about. I had to work out, so I had my post data here, I had the input field with some default text set in line 5, what's on your mind?

[00:04:18]
I then chose hand, look in my code here, line 5, line 9, line 12. Every one of those lines in a, I mean, actual code here is like probably nine lines of code. Every one of those lines, line 5, line 9, line 12 affects what the user sees, affects our view.

[00:04:39]
In line 5, I fill in my default text with what's on your mind. In line 9, I update my text content if the user has started writing something with that post value. Only if the user started to write something. So now I've got a string of conditional changes, initially display what's on your mind?

[00:05:02]
If user starts to write something, well, sorry, if the user clicks, remove that. If user start, which is the handle, click set the back. If user then starts to write something, start display something. What if somehow the user was able to write something without clicking? I mean, then we've got still the what's on your mind text in the, I'm not saying that it could happen, but like I've got a reason through all those possible paths the user can take.

[00:05:30]
This is a flow of user actions with conditional on that changes to view. And this is with two little boxes. Imagine a thousand elements, it would be profoundly difficult. It's not that what we choose to do here is right or wrong. But it is one way of trying to prevent this reasoning process of working out conditional on the last thing the user did display that, did they take that?

[00:06:04]
Okay, so it took that list steps? No, we only allow the user to affect state, posh word for data. And then every single thing the user can ever see will be dependent in some way on that data. There will be a full one-to-one relationship between saved data and what the user sees.

[00:06:28]
And there's a mindset shift that we take. Yeah, so we're changing our view based on multiple possible user interactions. We had two handlers, as soon as we introduced multiple of those, the route the user can take, is this one better run after the click happened. Otherwise the user is going to be still see text here, will it append it?

[00:06:50]
I mean, technically here it would overwrite it, but depending on how we did it, we could totally end up appending. So it would say what's up, and then Ian starts writing and now it says what's up. Ian, that's not so bad, I guess.
>> [LAUGH]
>> It's like a great bonus feature.

[00:07:02]
But we're having to reason even with this tiny amount of content on the page. Reason down the user's journey in all these expanding pause. They exponential essentially because you are 40 handlers for a thousand different elements, each of them has 40 handlers, theory, right? Maybe, and then each of those can affect a thousand other elements.

[00:07:22]
You're dealing with a 40 by 40 by 1,000 possible scenario paths. Actually even more than that, right? Because it's 40, you can take one, and then another, and another, all of them are depending on the previous action the user took to ensure, we need a way to make these changes as predictable as possible, how?

[00:07:40]
Restrict every change to view to be via one, an updated data. And two, a run of a single data to view converter function. It's just one approach, but an immensely popular one. React, Next, View, Angular, Svelte, all use it. It's also gonna allow us to do semi-visual coding as well.