Dynamic Actions & Real World Benefits

[00:00:00]
>> I've hard coded some actions in, I'm loading them, I'm cycling through them. But what if we actually took actions that didn't even exist in the application at that time, and we were able to load them in so they could really come from anywhere is that somebody could send me a set of actions in the mail.

[00:00:29]
And I could type them out or load them in, and they could go. So now what we're doing is we're loading in an action. And then we're able to like a random action anywhere from in the world. Pull it in and dispatched. So not pre hardcoded actions, but let's imagine just dynamic actions from anywhere.

[00:00:55]
So what I have in the code, you can check it, out is I'm just fetching a single action from a server. I'm loading it and then I'm going to dispatch it. So if we go to the manual cycle, we'll actually go to the dynamic step. I'm gonna refresh this.

[00:01:15]
And I'm going to actually just pull this up. If we go to the Network tab, I'm going to fetch an action and so it's loading an action in And you can see here in the response. It's an action coming from this endpoint. Now what I can do is, in fact, I think I might even be able to change this, but we'll go fetch or let's dispatch this again.

[00:01:47]
Oops. Let me refresh this. I may have messed this up a little bit, but fetch dispatch. So now I was able to pull this in and I was able to dispatch, I wonder what would happen. I'm going to be. Rolling the dice here, but if I go create let me go set this to No.

[00:02:15]
And I'm going to call this individual please work. I am begging you If this doesn't work, it doesn't matter, but let's just see what happens. And it did not work. Let's see if maybe I threw an air not, well.
>> Did Ivy know who was with the strings?

[00:02:42]
>> So maybe it's because my ID note wasn't string. So let's. Actually just delete that. Please really work. And I believe it creates. And [LAUGH] yes. So that wa it. So thank you very much. And so now I was able to take and over here dynamically create an action.

[00:03:25]
And then send it in. And it worked. So now, I think we know where kind of this next logical step is, like, what if you could load in more than one action? Well, we can. And I think that's a fair request. So. Thank you for making it fetch and we'll actually do the dynamic cycle here fetch.

[00:03:52]
And so all I have now is a number of steps. And so just to keep it simple, it's select, select select, but you could actually do. Create select update delete. So just imagine here that you can actually dynamically load in, in dispatch, any number of actions to create this sequence.

[00:04:23]
So dispatch. And it is now pulling these actions over the wire via this endpoint. And we're able to automate the essentially a sequence of user interactions via these actions that we are creating. And so, just to kind of stop and summarize, where we are, we are talking about creating time and space by managing complexity, so we created a essentially a reducer Redux from scratch.

[00:05:15]
And then we started talking about how to manage time with observables. And then in this example over here, that we've separated out It created distance from the actual user interaction into the logic that handles it, in so much that we're sideloading or simulating or reproducing those actions. and then manipulating Or recreating those actions in our application without actually having to click anything on the keyboard.

[00:05:54]
So again, if I just dispatch my hands off the keyboard, and it's still replicating with high fidelity, a real user interaction and so. The question is, what does this mean? What can we do with this particular kind of paradigm or this possibility that I'm presenting. So if you have the ability To recreate state, or recreate a user interaction at any given time.

[00:06:40]
Imagine if you had an application, that was when it broke or when there was an error. It would capture that state and the last known good state. The current state, and then the action, that transition from one state to another, and it pulled it out. And it was delivered to you what that would allow you to do, is then to load your state into an application, play that action, and recreate the action or the bug or the faulty action that puts your app in a bad state.

[00:07:29]
And so now if we talk about, if you know everything about a system and the rules that govern it, Then you can know everything about that system in forward and reverse. And so I've actually done this. And there are a few libraries that exist. There is a company log rocket that has actually built in some tooling for this, that when you throw an error in your application.

[00:07:56]
Using a meta reducer is that it captures those known states and the action that caused it and it just sends it out to the server. You can then go back in sideload that state, play that action and see what exactly happened. To your application and how it broke.

[00:08:20]
So that's one very, very compelling use case is that I simply need to figure out what happened and why it broke. A second use case is that imagine. If you had a bunch of repetitive task. Well, you could essentially create a macro that would capture those actions. So think about if you were doing something and you had like a little record button, I want to just record this and all it did was capture The actions being emitted and I would save those into an array and then you could just replay them and automate that particular task.

[00:09:10]
So this is essentially what I have done here, is that. Imagine just capturing an array of actions. And then being able to say I just want to play this. So now you have the ability to accelerate and automate repetitive tasks because you've created space and time, from the actual human interaction to the result.

[00:09:34]
Until eventually It just looks something very, very, very, very quick, almost to the point where it just, you can't even manage it or you can't even really even process it because it's just boop, it just happens. And so I feel like this could be a little faster but you can imagine if you turn this up to like 5 seconds.

[00:09:57]
And the third application that I want to present is this idea of a thin component. And so in this angular application that we're seeing here, that Under the hood, it is absolutely true that we are using Redux to manage all of this state. And so there's no secret about that.

[00:10:34]
There's no way that we could do these particular things With out having some form of Redux that allows us to create this time and space. Now what I haven't mentioned is that the version or the Redux implementation of this Is not even in the application itself is that I've actually taken the version of Redux the implementation of it, and I've put it into a node server with socket IO.

[00:11:16]
What that means is that I can just open up Another window and because now I'm taking the state and imagine the beginning of the workshop. We're moving state. We started with a hidden state in a function And we've just been systematically moving it away from our component layer so that they become as thin as possible thinner.

[00:11:51]
And the question I asked myself is what if we actually took our application state and just ripped it out of the application itself. And we put it into a server that we could then use observable streams WebSockets to then communicate that state to a very, very thin client.

[00:12:17]
And so now what we can do Is things like this.You'll notice here that I am interacting with the left application. And as I do this, the right hand application is updating as well. Now think about this two separate applications time and space. They're totally separated in yet because we move the state into a even higher abstraction that we are able to keep these in sync because We've simplified state management across both of these, they're sharing the same state.

[00:13:04]
And then we have found a way to effectively communicate via web sockets and observable streams. And then because of this, we can now Interact within multiple applications and yet they are connected. And so now what we've done is we've taken time and space. We're starting to do interesting things by abstracting these things out in such a way That we can do things like imagine, if you had a user that needed support.

[00:13:46]
Well, it would not be hard to pull in their application state. And then also now you're sharing it and somebody remotely is providing support. From one application to another. Now, to top this off, and just to wrap this up, I want to show you the version of Redux that I am actually using in my application.

[00:14:19]
And hopefully, this is going to look very familiar. So this is in node. So our actions, I have some sample data clients, new client, initial state. I have a store I have actions or rather reducer functions. So select client, clear client, create client, update client. This should look very familiar.

[00:15:00]
This reducer and then all I had to do to enable this was drop in about 20 maybe 30 lines of node code, socket IO code specifically to make this available to the application into just pull this in. And so effectively, this application right here, is stateless because I've moved all of that Into a server, that we can now share, via real time connected clients, using, a reducer, or a redux implementation, that we use the four elements of programming, to bill.

[00:15:53]
And so, with that demo complete, this is where. When we take and we embrace first principles, when we start to stack these up in the proper way, and we really truly understand them, then we can do things like this. And for me personally, I can't think of anything more enterprising than doing real time distributed Applications in the cloud and so we are just right at that door.

[00:16:26]
But this is what managing state control flow and code volume will kind of pave the way and set the foundation for you to do things like this.