Challenge 12: Solution

[00:00:00]
>> Evan: Let's take a look at how we can make this happen. Think the obvious thing is we need to create a Vue instance somewhere and we can directly pass el into it because yeah, that's the same thing. And then model obvious should be passing to the data
>> Evan: So let's make it reactive.

[00:00:27]
>> Evan: And then view, so view is a function. View is a function that takes three arguments. And because view is essentially the render function, what we need to do is call it inside our render function. So we are essentially returning the view that's generated for our review function.

[00:00:46]
And the first argument is obviously the h. And the second argument is model. So we can, because model is made reactive here we can actually directly pass it in if you want to.
>> Evan: And really, the last question is, how do we create this actions thing, right? Directly passing actions probably does not work, right?

[00:01:15]
Because if you pass it here. When you pass the click, this will be called with, the as the argument is that of what you expect here which is our model essentially. And we also need to collect the return value from these actions in order to somehow trigger state updates.

[00:01:39]
So it's pretty, so we realize that we cannot just directly pass the same actions object into our view function. Instead we need to maybe, like wrappedactions or something. And this wrappedactions will contain the same tease, as the original actions object, but the implementation will be different. So what we can do is

[00:02:10]
>> Evan: Let's make wrappedactions an object.
>> Evan: And then we iterate through the incoming, the source actions.
>> Evan: All right? In wrapped actions, K equals something. So now we can think about how they are expected to work. They should receive the current state. So they should be, wait, wait, wait, sorry.

[00:02:49]
wrappedactions, let's just make it s function first. Think about what you do later. And these arguments. So this argument is actually what we receive from the click event. So for us that's really not useful so we can just ignore it. What we care more about is that this function is called.

[00:03:13]
And we will probably want to save the original action somewhere.
>> Evan: So when the wrapped action is invoked, obviously it should call the original action. And our original action inspects the model, so we pass the model to it. And the original action returns the next model
>> Evan: Right?

[00:03:44]
Now comes the interesting part. How do we take the next model and somehow make our state reflect what's going on?
>> Evan: So what we can do is
>> Evan: In fact I think we should probably do something like this down model like this.
>> Evan: Const app, well let's call it a vm, okay.

[00:04:20]
And we want to reference the latest model here. And vm.model = nextModel. So this could probably work. I believe this is slightly different from our reference implementation. But just for the sake of it, we should probably give it a shot, see if there are any errors, no errors.

[00:04:52]
And yeah, it works, so we've successfully satisfied the API requirements that we see in the exercise. So let's recap. The first thing we're doing is, so the thought process is actually in reverse. We first started thinking about the top level requirement is we need to create a view instance and mount it to l.

[00:05:23]
This view instance should take the incoming model and make it reactive. And then inside this instance, this render function, it'll invoke the view function and pass it to the necessary arguments. Which is the h, the model, and actions. Then we realize the incoming raw actions will not satisfy our requirements.

[00:05:49]
And we somehow need to essentially map the original actions to a another version of it to satisfy the API requirement. So we create another clone object, and then essentially create these mapped functions. And inside these mapped actions we will call the original action, feed it the current model to retrieve the next model, and then we replace the current model with the next model.

[00:06:23]
>> Evan: So as you can see, internally this is still sort of mutating stuff. But what we expose to the external is purely functional. In fact, you can see that this whole app doesn’t contain any mutation in any place. Everything is just functions, arguments in, arguments out. And the point of this exercise is really so show that despite the superficial difference.

[00:06:53]
So when we talk about going for a more functional style or a more whatever style. It's more important to understand the online connections between different paradigms. Similar to JSX versus templates or functional versus non-functional. I believe the most important thing is to understand what problems are they trying to solve.

[00:07:17]
Instead of just sticking to one thing and believing it's better than the other. So who's early, he worked on early on. He recently had a Tweet, which I like a lot. He says the things that you like probably not as good as you think. The things that you hate are probably not as bad as you think.

[00:07:40]
So I think it's important to always keep an open mind when you see confronting paradigms and try to. It's always worthwhile to explore the other side, to understand the benefits of both. That'll help you, even if you don't switch that'll help you understand the underlying problem better.