React and TypeScript, v2

Passing State Methods to Components

Steve Kinney

Steve Kinney

React and TypeScript, v2

Check out a free preview of the full React and TypeScript, v2 course

The "Passing State Methods to Components" Lesson is part of the full, React and TypeScript, v2 course featured in this preview video. Here's what you'd learn in this lesson:

Steve refactors the Fetching API exercise solutions to demonstrate what the code would look like if setQuote were passed through to the Quotes component. The setQuote function is added to the QuoteProps type definition.


Transcript from the "Passing State Methods to Components" Lesson

>> I did say that pulling count out does cause re-renders. Like I said, at this point I would probably keep it normally because the performance, it's not worth the added headache. But let's talk about what this would look like if I wanted to pass set quotes through instead.

So instead of onSubmit, we're gonna give it just the set quotes function. And again, this is a refactor that I will know is finished when the red squiggly stop. So then we can push count, yeah, the countdown. Accounts need your state, nope, no duplicates, cool, cool, cool, we're not using that anymore.

We're not even doing these two. What we want, Is to be able to pass through a set count. But what is it? I mean cyclops rather. How many times have I done this? It's a function, but what's the signature?
>> Start typing in [INAUDIBLE] [LAUGH]
>> Well, the problem is for when you're defining the arguments, it doesn't have the information yet.

It's like, yo, these are the things I'm ready for, it can't reverse engineer. And be clear, I await a future version of TypeScript, be like, yeah, I can, right? I saw you use it somewhere else and this is the one time you gave it something, I'm sure that I can't wait for that comment to be out of date.

But presently it's true. And so if we look, it is this function which likely takes an array of quotes and returns void. And I could hard code that myself and that is what I did for years, right? But that's actually, then if I change it to something else and I refactor it's like my reinventing the wheel did not serve me.

But what I could say is, this is a very valid type, I can literally just grab this, Say this is what kind of function it should be. And that, let's save everything in this case, and now we just say, Did we pull that in? Yep. Then we set the quotes.

Hope we didn't define it here. Cool, now that all works let's see, where else am I getting yelled at? We took that off, that's fine. Let's actually define that and we'll say, now I get to use that new thing again. Check it out. It's like I didn't even have to go see, there's Arizona, I have not looked at them yet.

Cool, pass that through. That no longer takes accounts to get rid of that. Or does it? Awesome, no issues found, everything is good, big reveal. Yeah, it works, right? And so the refactoring helped and the other part that we brought in, basically everything we've talked about so far and then went for a little bonus run by passing down set count.

Like I said, I would probably do it that first way, but I think it's useful to show one, the active refactoring. And then two, if I needed the type for something that I didn't totally know. Like a lot of times, especially if I have the value already, I can reverse engineer what that type should be.

And there's actually ways, there are some utility methods called return type that you can literally hand it the type of a function and it will get you even the return values or parameters that will get you the parameters, right? There's a whole bunch of ways that I use throughout my codebase to figure out stuff based on other stuff.

So it's not like, here's the set of types that have carved in stone everything must adhere to it. I can dynamically figure out types based on actual properties and use cases that I'm using in my application. So we have that kind of all in place now and it works and the refactoring becomes a lot easier.

If I was doing that normally, I would've to switch back and forth between the browser, look at the next error. But for me a lot of times even hovering over some of the stuff, I could see the answer and get a sense of it incredibly easily. This still, I will show you why I would probably use use reducer in this case because it just become simpler.

That is true of React in Vanilla JavaScript, and it is also especially true because then there's just one dispatch, it becomes very easy to pass around and use. That kind of just to set the roadmap for us kind of going forward a little bit, which is cool. We've now seen how to deal with props.

We've seen how to deal with event handlers. We've seen how to deal with state from use state, kind of the next kind of few hurdles, we've had to deal with asynchronous state. The next few hurdles for us are, okay, how does this work with use reducer? What about the context API, right?

That's the thing that we all tend to use as well. And then we'll see, because the context API has some interesting problems with the time space continuum. And then, we will just look at, hey, it seems like I'm taking a lot of stuff from the underlying elements, like a form, like an input, and retyping them myself.

Could I just have some of that goodness that you're just talking about where we can use some amount of dynamic typing to figure stuff out? Absolutely, and so we'll talk about that as well.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now