Effects Q&A

[00:00:00]
>> And is it possible to share a state from lacy logan libraries to other libraries?
>> Yes.
>> My challenge is in some projects in the past, I've had the challenge to share a state. And the challenge was because one library was Lacey loaded. So how I make sure that I share this data across multiple libraries?

[00:00:28]
Is this core module for example a good place to store the data? In the core state module?
>> Yeah, so the question is if you have lacy loaded modules then sometimes data is not available within those lacy loaded modules. And so how do you make that available to the rest of the application?

[00:00:48]
Is, for instance core state a viable approach to that. And I would say yes, I believe so, that at some point you kind of have to establish that there is a canonical source of truth. Ultimately, I believe the ultimate source of truth is your data layer in terms of what's in the database.

[00:01:14]
And so what's interesting about that is that Imagine you have someone running or multiple people running the same application and they're manipulating data at the server. Well, this is actually a real problem is how do you deal with data synchronization and data transactions and still data. That how do you handle the fact that somebody could have changed data at the server and you are actually staring at an older version of it?

[00:01:55]
And which then could adversely affect your decision making if you've ever tried to buy a ticket online, and it's like there's 12 tickets, just kidding, there's no tickets, which I've been burned. Or if you've ever bought something off of Amazon, and in my case, my wife is in the other room, also adding stuff to the cart and then the single source of truth is the Amazon database.

[00:02:21]
Now listen, whereas I wanted a book, I ended up buying a book and a tractor and a Christmas tree, because it was in the cart and unbeknownst to me, I purchased it. And so the reason why I'm making that analogy is because you have to find The lowest possible abstraction that still covers all interested parties.

[00:02:47]
And so, if you have a module that needs to share data with another module, then you have to go one abstraction above that to put that there. So ultimately, and so NGRX allows for lacy loaded or for you to load slices of state so you can do it the store for route or you can do it for feature.

[00:03:12]
So it allows you to add those pieces in incrementally but ultimately, I recommend having a core state module or library that is that abstraction that sits just above all the interested parties. Now, I should never quite said it like that, but I think it makes a lot of sense.

[00:03:35]
Is that everything that we've been doing since we got here this morning, or from the beginning of the workshop up is we've been just incrementally abstracting complexity. Away from really the component layer or the point of contact, which is, what is the user state and we're moving it away.

[00:03:58]
To the point that I've actually written versions of Redux that exist in a note server, that anybody who's sharing that data now they're sharing a single, unified store across not only modules, but across an application. This is the entire premise of Firebase is you're just moving in, you're promoting that to just one layer above all interested parties.

[00:04:34]
So to sum it up, the answer is yes. [LAUGH]
>> Okay, thanks.
>> All right, What other questions do we have? This is only like probably one of the most complicated pieces of development period. Anybody?
>> I was looking like an online 16 action that doesn't seem to be used anywhere.

[00:05:03]
>> The observation was in this particular block of code on line 16 it doesn't appear that we're using action. The reason being is because there's no payload to go get the collection. We're just saying go get it, versus if we go down to create we do need the payload off of that.

[00:05:24]
And so we're saying the action is update widget and we're pulling the widget off the action item. Does that make sense?
>> Yeah, so that payload is trickling down from somewhere.
>> Yep. So-
>> From the component?
>> Yes. So let's walk through this real quick. I'll just kind of step through this and how this works.

[00:05:48]
So, in the widgets component, We'll go, I'm going to save widget, and there's nothing fancy about this. This is a widget, it's either gonna be a new widget or an existing widget. And then from here, in the façade, yeah. So in the façade, I'm saying does this widget have an ID, yes or no?

[00:06:22]
And depending on that, let's go with create. So from here, I am saying widgets actions create widget. So this is just to be clear. I'm referencing all of the actions. So, if we go here, down here, it's Create Widget. So this is the actual what I consider the trigger event.

[00:06:56]
So back to here. Widgets. So dispatch, which is calling the store so this sorta dispatch, I'm passing the action. And what that is, it's an action object for create widget, and I'm passing in an object with a widget so it's just a generic object with a widget property.

[00:07:24]
Then what this does is whenever we create this is listening for the create widget and the effect and I say, Okay, good. So it's called widget service create, and it's passing that in. And then once we've completed, then it's calling create widget success, and it's passing that widget into who knows?

[00:08:00]
I mean, in a way, we don't know yet because it's just dispatching this object or returning it, because the effect is like the middleware. And then from here, if we go to the widgets reducer, then create widget success is taking your application state the new widget and it's just saying hey, I want to add this to state.

[00:08:24]
That makes sense? So from the component, it basically-
>> That's cool.
>> Cool so façade, which then gets dispatched and either gets picked up by the reducer or an effect. It performs some operation and then let's say it goes into the effect then it completes and then it dispatches a new action with that a loop that goes into the reducer which that update state.

[00:08:49]
Which then now triggers that absorbable strings that says hey, something happen, update yourself. So it's some head knots here, this is good. All right. Any other questions?
>> A general question with the, NGRX and stuff? Basically when does it not make sense to use it? Like even on large-scale applications when doesn't just kind of just has complexity?

[00:09:30]
>> So the question is when this does not make sense to use NGRX? I would say if you're doing something very kind of temple like a proof of concept, then I may consider not using NGRX. So for instance, I'm just doing a quick proof of concept. I probably would just use a façade at the same time, that everything that I've done for the most part has been off of a command line.

[00:10:05]
So it's very quick if we took everything that I've done, just sort of the command line, we can reduce a lot of this application development into 20, 30 minutes. In fact, all of the commands that I've done at one point were in a single shell script that just think about that.

[00:10:25]
So now, I would say when somebody truly understands how NGRX works, I think it's just as efficient. You're just changing things and putting them in the appropriate place. Where I do believe it becomes slightly problematic is when you're working with a team that is not in a place to really grasp it.

[00:10:54]
And so I have worked with teams where they are missing some fundamental concepts, that makes wrapping their mind around NGRX really hard. And I think there's a certain arc in a developers kind of journey where they're kind of ready to start thinking about state management. There's other times where they're not ready via they just are learning how to program or they've just got a lot of bad habits.

[00:11:26]
And so at that point, I would prioritize the overall health of the team over my enthusiasm for NGRX proper state management. I have a really hard time thinking of a downside because a lot of the, what people would call boilerplate which I don't believe it is. But a lot of those, the ergonomics have been improved so much from the command line in the schematics that I think even though the surface area is a little bigger.

[00:12:04]
That you're solving a problem upfront that you're not going to grow out of. Versus if you start going on the path of everything is a service with a subject, that becomes a larger problem down the road. And all you're doing is you are essentially distributing that pain, you're not really addressing the complexity, you're only deferring it for a while, which is totally fine.

[00:12:35]
If you know that's what you're doing especially in a brownfield project is that I may opt not to integrate NGRX immediately. Now, again you have Akita in a couple of different libraries. As long as you're doing proper state management which is stay with me statement or proper complexity, you're addressing it properly which is state management, control flow and code volume.

[00:13:03]
I'm somewhat ambivalent in terms of how you actually do that. I like NGRX but we can use mob x Akita, whatever the team votes on cuz it's all to the same end which is we're writing great software to put into production
>> Yep, make sense? Kind of wonder because I remember reading somewhere that more often than not when you wonder if you need Redux in your react project, you don't need it.

[00:13:32]
Because well some people think about it like a spoiled brat I guess or?
>> Yeah, so the statement was if you think that you need Redux for your application, you probably don't. I would say anything non trivial. I would say this is a intrinsic immutable fact, if you're building something that's non trivial You need to take state management seriously, whatever library you use to accomplish that.

[00:14:03]
I think we could have a discussion around that. But state management is, in my opinion, the major contributor of complexity, which is the hardest thing about programming.