Wrapping Up

[00:00:00]
>> That is the kind of large part of the, these are the things, the kind of the more between the transcript, between some of these two lanes, between some of the practices around that. Things that you will encounter kind of beyond the basics as you go to then put in tests, put in TypeScripts, start putting some of the fetching pieces, right?

[00:00:24]
What you choose to do will likely impact an existing application, right? And how you pull these things together is that, if you're doing NPM and it maybe you can do the some of the basic stuff a lot of times. Stuff that you can take piecemeal and just grab that has that reliability of immediate typing, easy to test, I think, becomes the pieces of infrastructure that you can more reasonably rely on over time.

[00:00:55]
I think it's a trope, but I think as I've done this longer and longer, when I get what about this shiny new tool, I'm kind of like, I don't have it in me, right? I need something that's simple, reliable, easy to test. But then when I do need to do kind of advanced things, has an ecosystem ready to plug it in.

[00:01:15]
And those, I think, become much more sustainable patterns over time.
>> Is it rude to just go into work on Monday and just start using Redux Toolkit on my own without referencing or asking my team?
>> All right.
>> And TypeScript and all these other things. [LAUGH]
>> [COUGH] All right, let's peel apart parts of that question.

[00:01:33]
>> [LAUGH] Is it rude, first of all?
>> That's the question we're gonna answer. I have the secret advantage of being the boss. So I have to still tread lightly because nobody likes [LAUGH] the person who then goes. Yeah, they have to hear me talk cuz I can say stuff like that towards the end of the workshop cuz there's no way.

[00:01:54]
So I think it depends. So to the point that we made at the beginning of the workshop, stuff like the create action, create reduce or even create slice fit in an existing Redux. There's no, we have to change everything. TypeScript, you're gonna get yourself, you're gonna have to sit down have a conversation, right?

[00:02:14]
Because the way it worked for us, which is I remember it very clearly, which was like we were starting this, this was 2018. And we were gonna start this rewrite cuz I think I've told this story before. It was an application that was originally Ruby on Rails app.

[00:02:34]
Then it was a Ruby on Rails app with a CoffeeScript and jQuery hat. Then they put a React hat on top of the CoffeeScript and jQuery hat. And then they were gonna move the back end to AWS and rip out the Ruby on Rails that was underneath, right?

[00:02:50]
So I say that because I am not the person who cavalierly goes into the rewrite. Having done now two of them in my life, I would like to never do it again. But that was the first, so I've made the mistake a second time since then, but yeah.

[00:03:06]
So there was this, okay, we have to, we're basically there, take out the foundation of it. We're gonna have to do something here. And it was definitely one of those. We started a small team, was just kind of someone's got to keep the lights on in the old thing, set trail on the new thing.

[00:03:25]
It was like, we should do it in TypeScript. Nah, the team's gonna revolt. And then at one point, we just kinda floated the idea and then everyone's like, why aren't you all doing it in TypeScript? And we're like, we thought you wouldn't let us, right? So you might get lucky in that sense, but like-

[00:03:44]
>> I know that's not gonna happen.
>> I think it's also easier in 2022, right?
>> Another question. So it seems straightforward with Redux toolkit where I can just start doing it in Files moving forward and we can slowly go back and refactor old ones. But with TypeScript, is it something you can just like, okay, I have this new component I'm gonna make.

[00:04:01]
I'm gonna do TypeScript on this even though nothing else is TypeScript yet.
>> Yes-ish, when we talked about in the React performance course, a lot of those I didn't pure JavaScript simply to make them accessible. I didn't wanna have a prerequisite on TypeScript. All of the utility functions and all of the reducers that I was just using to manage the state, a lot of those were all in TypeScript being imported into JavaScript files, right?

[00:04:28]
So yeah, it takes a little tweaking in the configuration. And stuff along those lines, but you can integrate them. Now backwards, they all get typed as any.
>> The other way around.
>> Yeah, they'll get types and you can pull JavaScript files, cuz obviously, as we know, the JavaScript ecosystem is way bigger than the TypeScript ecosystem.

[00:04:48]
You can pull them in, you just then have to, in one of those definition, the d.ts files, you then have to go and start declaring types for what it should be based on stuff, right? And so you can integrate them and to your question of, what is the sell on some of these things?

[00:05:08]
Some of this is dealing with the fear, uncertainty and doubt about it, which is the store, you've always theoretically been able to slowly migrate from JavaScript to TypeScript. However, the 2018 version of that story, I guess, it was technically true. The 2022 story is a lot better, but sometimes you always have to deal with, well, I tried TypeScript once and I didn't like it, right?

[00:05:34]
And yeah, I tried Flow before I tried TypeScript. And I was like, nah, not for me, right? Sometimes that learning curve is tricky, but I think the benefits. I am at the point now where it's not using TypeScript, or even though I use it, I will reach a Redux very quickly as well.

[00:05:51]
Because the reliability especially with Redux toolkit, the reliability I'm getting those types and just the as I'm coding, it's every time I go back to just not having either Vanilla Redux or and or because the types, right? It's very nerve-wracking, right, and I think once you see the benefit, but yes, how do we to tell your team, hey, next sprint, what if we were slower cuz we were learning a new thing?

[00:06:20]
It is tricky, right? I think it's one of those things that has to be done with a lot of empathy. So yes, you will annoy them. It will be rude, but maybe it's good, yeah, yeah.
>> Yeah, if I recall correctly, the lazy version of the query will let you have control at exactly what point you can fetch.

[00:06:37]
>> Yeah, when you choose to kick it off. So you can have the hook with lazy, you choose when you want to invoke it. That one is just gonna fetch the data.
>> And that happens. So effectively, it's equivalent to started rendering the same fetch, or how does that work?

[00:06:56]
>> I have not, so I have dug into the colorful SWR, which doesn't use effect, right? They do a trick with a ref.current and then to concurrent, get it at a different point in the cycle, right? And then use that ref.current to make sure they don't repeatedly do it.

[00:07:11]
So they do it initially, and the reason we use use effect is that array, make sure it doesn't happen again like the empty dependency array. A ref has a current that is persisted through re renders. So once you set that from false to true or whatever, you have access to it again.

[00:07:29]
My assumption is that is what they use, right? I have not dug into this code base, I have dug into some of the other ones to figure out, what you're doing in there? And that is the methodology that those use and that is what I'm going to assume that they're doing but I don't actually know.

[00:07:43]
The other thing could be actually, if I was gonna make assumptions, the store is already going. The store is completely external and not relying on a hook. There's probably, we saw it, hold on. Let's go back over. Here's my hypothesis, because that's what you wanted, right? [COUGH] I'll start this up again.

[00:08:07]
My suspicion is that around the time that an event got fired, [CROSSTALK] yeah.
>> Yeah, because there is a timestamp of zero difference, right?
>> Yeah, so it's probably, they probably can fire an action on the mountain, too. Since the nice thing that Redux gets that hooks doesn't get you is it is completely pulled away from the reaction component cycle and not beholden to it.

[00:08:31]
Anything involving use the fact, anything involving the component lifecycle, it can dispatch events. It lives outside of the component lifecycle and do whatever it wants.
>> But I think you're right, judging from the timestamps, there is zero delay between when middleware registers and depending.
>> This was the application component, so we're kind of cheating to write.

[00:08:54]
It is the very first component that mounts in the application.
>> I know.
>> But likely, I'm gonna guess that the hook fires that basically immediately. And it doesn't need to use use effect because it's not a component, it's not beholden to the re renders. Awesome, thank you all so much.

[00:09:15]
>> Thank you.
>> [APPLAUSE]