Predictable Data & View Flow

[00:00:00]
>> But now what it also means is, okay, added benefit that we can declare our dataToView relationships once, and when the data changes, the view will update. Well, that means, which is important, right, because remember our goal of UI, what'd I say, display content to users and for the user to be able to change that content.

[00:00:23]
And I love the ambiguity of that because it reminds us that that content is what they see and should be the underlying state of the world. Because that's exactly what it's like in the real world, when I change what I see, I'm changing the underlying state of the world, not in a computer.

[00:00:38]
But if they were to become a bit closer, because we've described that relationship one time and it's used again and again, we're getting a lot closer to content being a united thing. That the underlying data and what you see, they are not separated. Because we've described how the what you see is dependent on data, and it's only one place that's happening.

[00:01:03]
So they've kind of become tied, they've kind of become bound to each other. That can allow us to even trick ourselves a little bit visually to think that we've actually bound them together. So let's see that in a second. Remember our goals of UI, display content online data as view, if that's the case, make sure that the change of data just propagates, just appears in the view.

[00:01:27]
Why would you want them to be separate if you're saying you want to enable the user to change what the content is they see, implying changing the underlying data as well? Make them the same thing. Things like web components are all about trying to make them the same thing.

[00:01:40]
Okay, great, well, we're gonna see we've almost done that here. Enable the user to change the content, both the data and what they see. At least I'm predictable, both the underlying data and corresponding view of it. We need to run the dataToView converge on repeat. But if we do that, we essentially automate the process.

[00:02:00]
Here it is, so what have we changed here? The only thing we have changed is we run data review three different times here, right, in response to initial no user reaction, which is the first, I guess before the user takes action, then when user changes data, what sorry.

[00:02:19]
So even user action that's causing it's whenever data changes and user action is what causes data change here. It could be a server call. It could be something else. And of course, it's going from the app not being on to being on that is data changing, right? That's data becoming undefined to begin.

[00:02:33]
So whenever data changes, dataToView must run, including on initial data creation. When we do that, the view updates two or three times here. Well, what if we just had it running so often, that's a really slick move, people, had it running so often, every 15 milliseconds, that we didn't even need to rerun it in response after our chain of data.

[00:02:56]
Now in practice, I wanna make it really clear, we couldn't do this, it's gonna block, by the way, even some of those handlers running, we need to, sometimes it's only gonna block CS animations and smooth scrolling. All of which share a couple of processes in the web browser, completing tasks, but share some of those processes.

[00:03:14]
We don't wanna have that blocked by a function re-render our entire page every 15 milliseconds, 60 times a second. However, and we'll find a way around that with state hooks, they're gonna give us the impression we're doing it automatically, running that update function every 50 milliseconds. Actually, it means we'll only run it when we change data, which is what we do here, but the problem is I don't have to remember to run that data review.

[00:03:39]
I'm gonna change that data all over. I don't have to run data review every time. What if just for a hack way for now, this is a hot way just to get the fun of it. We had it run so often that we didn't actually need in, let's do it in green, I think, we didn't actually need to run it in here, we didn't actually need to run it here, we didn't actually need to run it here because it's running.

[00:04:02]
Basically, we finished running change the data it would run here, just because it's running every 15 milliseconds. Change the data, it would run here. This would run as you know 15 milliseconds in. Here, it would run basically immediately afterwards because set interval will take in a function and run it every 15 milliseconds, meaning it will take in a function, in this case, the dataToView function, and store it in another feature of the browser, it's timer.

[00:04:28]
And that is accessible by set interval and set timeout. Both of which allow us to pass it a function definition. In this case, it's going to be dataToView our converter, and say, run it every 15 milliseconds back in here. Therefore, it's obviously a horribly brute force looping to make sure whenever the data changes, but it's kinda badass.

[00:04:52]
Look at that, handleclick, change some data, handleInput, change of data. Don't ask anything else. Just know that dataToView is running on repeat right after a hundreds of times before you can even, whatever, fine. However, it has now made our view directly depend on our data, our view and data have become bound.

[00:05:19]
Which given, we wanna change data and view are the two parts of content that user sees there's underlying data and the pixels displayed of it, putting them in one bucket so that they are intrinsically tied, kinda cool. And then only allow the user to change the data that generates that view.

[00:05:35]
Don't worry people, we're going to move away from a 50-millisecond repeat loop on a function that renders the entire page. However, for purposes of pedagogy, very good excuse for everything, browser implementation and pedagogy, which we'll see it here allows us to make our few depend propagate from our data automatically.

[00:06:03]
We've added predictability to our data and view flow. Thousands of ways for users to interact in a modern app. Every piece of view, I guess every piece of content, I quite like to use the term content cuz it implies the view and the data, on elemental page can be clicked, typed, moused over, all of which need to change content, data, and what we see.

[00:06:26]
I would say exponential complexity, especially once you can have a flow of, I need to reason about what was it like when the user clicked as opposed to I know what it was like, it's whatever the data generated. I don't even care. I just say I don't even care.

[00:06:43]
I've written my code to well, maybe I care somewhat, I wrote my code to depend only on input data. Sorry, again, input not use word there. Depend on our data in JavaScript, there isn't sort of an input to our dataToView conversion. And by the way, in all of these things, we then have edge cases where we introduce workarounds that handle particular situations where we can't get it as simple as that.

[00:07:06]
We do care about the previous behavior, we do need to track change over time and things like that. But as a starting point mental model or design pattern, sorry, we have huge value from this. We need a predictable structure, better to be restricted, but predictable and overly flexible, impossible to identify which bit of our code cause our view and data to change.

[00:07:28]
So every interaction must change, jobs or data and then update all dependent views. Change the views via an update of data and a run of our single dataToView function. Now, again, in practice at scale, we'd have many maybe dataToView functions. And maybe we'd even need to flow through those in some way, a flow of data ordered through those, some sort of rules for flowing data flows.

[00:07:54]
But for our purposes to keep it super, I mean, as it is, that's like 12 lines of code and it's like a. [COUGH] Anyway, one-way data binding restricting all our users' changes of flow to some corresponding associated underlying data. And all changes of view to flow through a single converter function called a render function, a dataToView function.

[00:08:21]
A restrictive but powerful step to simplify our reasoning about user interface by an order of magnitude.