Wrapping Up

[00:00:00]
>> What questions can I answer? So yeah.
>> Regarding the holding cycle you recommend anyway? Is there a standard way of doing it? Like, for example, if you want to be able to know the internet has been fulfilled or there is an error.
>> Yep.
>> How do you go around doing this?

[00:00:22]
>> Is there like a standard way of doing this?
>> Yeah,
>> Is like everyone is different so.
>> Yeah, that's the tricky part with especially the lower level redox, which is like it's whatever code you write, right? Redux toolkit is going to automatically fire that pending version of the event.

[00:00:42]
Then it's gonna fire you this filter the error one I think in the absence of a better pattern. Taking an officially sanctioned library like Redux toolkit and doing what they do is probably a great idea, right? But if you were to do it by hand, you would have to fire each one of those.

[00:00:57]
So it's basically cool fire the pending event effectively, like before we launch the promise. So you'd do it here, you'd fire your dispatch upending event. This is a pseudo-code now you dispatch a pending event here. Dispatct the action, you would then catch the air. If there was an error, you dispatch an error event, otherwise this special filled when you basically do the same life-cycle yourself.

[00:01:27]
All the Redux toolkit is doing for you is taking care of that. Now, in terms of what do you do? It all depends if you're just doing something lightweight dunk works really well. If not, it's things like Redux observable, you can kind of like change the flow of different actions into dispatch stuff.

[00:01:43]
But really, if you think about it, you have following the promise life-cycle isn't the worst idea in the world, right? Like you've got a pending promise. You've got to fulfill a promise and you've got either an error or rejected promise. Those are really the three states that you need to worry about.

[00:02:00]
And for the most part, I would just since if you're especially if you're using promises or whatever. Having the actions based like that very core thing we talked about in the beginning of the workshop, which is like your action should be just the facts, right? And naming the action types based on what happened inherently makes sense, right?

[00:02:22]
Hey, if fulfilled, it's pending, it errored and kind of just going with the same promise life-cycle, is probably your best path forward.
>> What about Redux, observable aware, they will be, injected.
>> Yeah.
>> Slides.
>> Yeah, so with Redux observable, which is honestly one of my favorite libraries.

[00:02:45]
So Redux observable installs itself as middleware, right? And just as we saw the very beginning of this workshop, middleware can listen to any action and they can either consume that action it can let it pass through. It can dispatch more actions. So Redux observable sits like alongside the rest of this listening to every action that comes through then through your RX j s Epics or icon pipelines, they're called Epics in Redux observable.

[00:03:16]
Will listen be like based on this, I wanna do these, this observable workflow and then I wanna spit out these other actions that will then go into Redux. So it almost sits alongside dispatch listening to everything and deciding what it wants to do based on that.
>> And the other said bigs, organized like accordion state slices for.

[00:03:41]
>> So it's completely separate from that. It's just again, it's only listening to the actions you can get the entire store but is completely removed from either Redux toolkit or even your read out the shape of your Redux state. It is solely listening to all the actions that flow through.

[00:03:54]
You do have access to the store, which is again, like all this did was use combined reducers, right? So, it's using this like Redux tokens using the same Redux stuff on the hood but it like Redux observable is completely agnostic. To any of your slices or anything along those lines is just listening to actions.

[00:04:10]
Every action that flows through, flows through all of your epics just like reducers. It flows through all of your epics and the epics that care will do something with it. They'll maybe dispatch more actions or whatever. They'll throttle the actions, so on and so forth. But they're just listening to the flow of actions through your application and then using reactive programming through RX JS to figure out what to do based on that.

[00:04:35]
>> Do you have any thoughts like what the community decided to go away from that? They keep saying build your own kind of state management solution.
>> Yeah.
>> We kind of follow that, but we came to the point that we find ourselves like replicating all the APIs and new Josie we already have.

[00:04:53]
And that wasn't like super beneficial, I wonder if you have more insights out that.
>> I mean, some of this is we're gonna enter the realm of pure conjecture. Sometimes the user does always build your own is a thing that you very frequently hear in a new library.

[00:05:12]
Right, cuz there isn't everything yet, right? It's you should build your own. And then enough people say that and then, okay, maybe we need an abstraction around this, right? I've been, been around long enough that very early libraries and frameworks, yeah, you can just, we have a plugin API.

[00:05:27]
Build your own and do it yourself is very I think you hear very early on. And then what happens is, and there's a reason for this, that works. Which is the answer is like, we haven't built enough large scale applications to know what the answer is. So what happens is people go and build their own, we start to realize what the best practices are, right?

[00:05:45]
Rather than somebody sitting in their ivory tower going like, okay, I have created a new library, and this is what we should all do. Nobody really knows yet, what happens is we all go and we build things. Some of them are, some of them ended up working better than the others, right?

[00:06:00]
And we start to align on the practices that have worked and start to avoid the things that got us into a lot of trouble. Right and so a lot of times in a very early stage we don't know. Right, and so it's try stuff out and then we start to learn enough things.

[00:06:17]
Okay, everyone should probably do the same seven things. What if we begin to pull them all together into an abstraction that help people not have to make these decisions all the time? I think a lot of libraries walk that convention over configuration, right? Convention is there are the rails way of doing things.

[00:06:36]
There is the Ember way of doing things, you very much go with the flow. Redux toolkit is a little bit closer to that convention side, which is cool. This is the Redux toolkit way of doing things. There's that extra reducers escape hatch, which is totally neat. But early on is more like hey, here's a very lightweight thing.

[00:06:53]
You can use it any way you want. It's a lot of times a lot easier to get started with and wrap your head around if that makes sense.
>> And Steve, could you please give a piece of advice? For the medium large project, what is the best like solution of state management using raj's Redux observable is Redux still a good choice.

[00:07:23]
Or are there any new libraries?
>> Yeah.
>> If any insights regarding that.
>> So there's always a new libraries, in JavaScript, right? The big question is is really interesting to watch as I've been doing this for longer I used to be like, what is the new hot thing right, let me go use that.

[00:07:45]
And as I get a little bit older, I get a little bit more boring, we in the kind of refactoring re architecture and of that drag-and-drop email editor that my team and I started working on in 2018. Now, we were trying to rescue just like this, application had started out as a rails app that then some people threw some jQuery on.

[00:08:09]
But then they threw a react app on top of that, and it was like their first react application. And it was all of these things stacked on top of each other, to the point where we couldn't move anything anymore. And then when the backend was moving completely to AWS, we had to refactor so much that it made more sense to kind of like lay a new foundation.

[00:08:26]
We did the research we looked at are we gonna use thunks? Are we going to use Redux saga? We're gonna use Redux observable, we did a bunch of proof of concepts. We ended up picking Redux observable for us and it turned into like. We haven't regretted that decision, right?

[00:08:44]
When I've had teams move to one of the other code bases, they want to bring that with them. So, new libraries and come out in I'm hard pressed to the idea that I could make the idea that we can make a technology choice and three years later, not regret it.

[00:08:58]
Is not common, right, and the idea that has worked in this fairly large application is pretty, pretty powerful, right? Like is argumentation perfect, no, right? Do newer engineers copy and paste some of those epics and just tweak things in a lot of cases. Absolutely, but generally speaking, it has stood the test of time for us and has not been a major source of bugs in our application.

[00:09:24]
So that is my personal opinion that doesn't, a lot of this stuff becomes the point of subjectiveness after a certain point as well. But, I've been pretty pleased with using Redux for really complicated state management as long as Redux observable to deal with all of the other things.

[00:09:39]
Now, to be clear, Redux thunk might be fine if you're just like doing some basic CRUD operations for us, we've got like autosave and drag and drop. We need to do all sorts of throttling to bouncing for all sorts of different kinds of things. And some of our API's involve kind of very complicated state machine logic that, that having Redux observable helps us with.

[00:10:01]
It could be overkill if you're like I needed to fetch some news articles from an API and put them on this page right? Maybe you don't need all that we definitely did. And even in the sophistication of that application have not learned to regret it yet, knock on wood.

[00:10:19]
>> And the monolith architecture microphone dance.
>> We do a mono repo.
>> One mono repo with micro flow tensor so just a monolith right but yeah, I guess.
>> If you say monolith at a tech company, they don't let you do it. So you call it a monolith and then everyone's happier.

[00:10:39]
>> Because currently at our project we are writing into micro front ends and we are searching for the best solution like to encapsulate state in our macro for dance, and at the same time. To share the state between these microphones at some shareable state, and we're just wondering, which is the best choice for a micro front ends architecture?

[00:11:01]
>> I don't know. I tried to like we originally wanted to use a micro front end architecture, and for the life of us couldn't figure out one. Didn't, when you start drawing the diagram and it starts getting you can tell like this is getting complicated. So then the decision was stick with a single repo and a single monolith and then, we'll deal with this later.

[00:11:23]
And it's been three years, and it's not the problem, right? We solved all the complaints individually, with the monorail there's only one staging environment. So what we did was we built an infrastructure that every PR gets deployed to his own S3 bucket. And so you have per PR staging of the front end assets right?

[00:11:44]
So now nobody was blocked by one staging environment anymore, right. We can't deploy a once well actually master would go so if some something passed all the tests. We just solved all the problems that people had with a mono repo rather than saying that the mono repo, the monolith was the problem per se.

[00:12:00]
Because yeah, a lot of our microservices on the back end makes total sense because you can have these isolated pieces. But we have to eventually at the end of the day expose a consistent UI to our customers, right? And it gets really hard to do that when everything's kind of fragmented, right?

[00:12:14]
We have other large code bases that are currently micro front ends that used to be a monolith. And guess where they're going now they're going back into a monolith again, right? Because it comes incredibly hard, now you're updating. Okay, you have all these micro front ends that are all running a slightly different version of react right?

[00:12:32]
Or all and sharing state between them gets really hard. So we've opted just not to do that because I and I interviewed a lot of front end architects a lot of companies as we're doing this, and ever the only, we struggled with it, right? Nobody had a really great answer and sometimes were we tried it and failed and went back right.

[00:12:49]
That doesn't mean that it's an unsolvable problem, but I haven't seen a particularly compelling solution to the problem just yet.
>> Yeah, that one remark regarding sharing dependencies react version, so currently is, it in part five others model federation and delighted ours to cache. Share some dependencies common dependencies and various assembler logic for choosing the proper versions of the packages so try this one.

[00:13:30]
>> Yeah, it gets it's tricky, right? It's definitely I see the benefits, I see why we all want to do it. I just don't know if we've totally figured it out yet, right? Both of them have most things, both of them have trade-offs. There's not necessarily a right answer, and it becomes about which set of trade offs you're happier with.

[00:13:47]
All right for us, we decided just keep it in one repo mostly cuz we just got a bad sense about it. But I know clearly the architecture works for some people because it exists, right? And the tooling, we're we're constantly working on the drone. I wouldn't be surprised if in short order or even today becomes more of a possibility than it was for us back in 2018.

[00:14:11]
>> Steve, thank you.
>> My pleasure. Thank you all so much.
>> Yeah, it was nice to meet you.
>> You too. Late after watching your courses offline. So it's my first experience watching the line.
>> Awesome, it's good to meet y'all.
>> I am enjoying yours sense of humor to experience, yeah.

[00:14:37]
>> Awesome, thank you so much. Thank you all for joining me and spending eight hours of your life together as a group