Transcript from the "Q&A: Defining Components, & More" Lesson
>> Speaker 1: Just a question about defining components, when to use functional components versus EXS class components.
>> Brian Holt: One Airbnb's linting rules are gonna yell at you so that's a pretty good indication. But the principal underneath that is if you have no state, if you have no life cycles or anything like that, it's a good idea to use functional components.
[00:00:27] The reason why is that they're more simple and I am a big believer in the, what is it, the,
>> Brian Holt: The rule of the least powerful abstraction, right? So you want something that's the least powerful possible that fulfills what you're doing and that kind of reduces your area for bugs right?
[00:00:49] So there's not really a whole lot that can go long with the function for example, right? As soon as you start introduces classes as CF more to like mentally parse to get through it and then you have more power, right? You can have life cycle methods, you can have state, you can have all these different things, whereas a function is more simple, it's just it's easier to not have bugs.
[00:01:11] So that's my general principle of no lifecycle methods and no state, then use a stateless functional component, otherwise use and EXS class.
>> Speaker 1: Have you ever had to use context?
>> Brian Holt: I have. In fact in version two of this, we do talk about how to use context just because it was necessary with previous versions of React router.
[00:01:40] So, I showed you how to use props, and I showed you how to use state. But there is a lurking third type of way to store your state which is called context. So instead of saying this dot props dot whatever, you are going to say this dot context dot something, right?
[00:01:55] The difference between context and props is that you're app has one context, so as soon as I said context in one component it's available everywhere in your entire app. Right? It doesn't sound scary to you, that's because it's scary. That's a bad idea, right? In fact, inside of the React document it says this is an experimental API, and you should use caution when building upon this.
[00:02:25] It's been around for a year-and-a-half, right? So it's not super experimental anymore and there are people in the react community, that are big advocates for using context in places. I have literally never set anything in context before. Like in all of my react apps that I've ever built, I have never had to write to context.
[00:02:48] The part where context is actually useful is for things like, React-router-dom, right? So when it instantiates itself, like here on app.jsx. What this component is going to do here, it's actually gonna set the router on context, right? And then when I go down into like, ShowCard. And I have a link right here, right?
[00:03:12] A link, this link is actually reads the router from contacts, right. So it's a great way for libraries to be able to connect out with the components that they render out. So for that particular use case I'm all for it. But if you're writing a library that uses this higher order components, makes a ton of sense.
[00:03:30] If you're writing stuff yourself, it's a really bad idea. If you're trying to set something on context, you really need to ask two questions of what am I doing and why is this a good idea? And can I do this differently? Can I achieve this with state? Can I achieve this with props?
[00:03:44] Can I avoid setting context? When you start using context in a lot of places, this is where you need to start saying to yourself, I probably need something like Redux, right? So, once you get to that point, you either go down the round of using context or you go down the route of using Redux.
[00:04:02] Usually, you don't do both. So, that's my spiel on context is, I don't use it. Once I get to the point where I want to use it, I use Redux. But there are people that disagree with me.
>> Speaker 3: More interested in Fiber, but as you mentioned, you're not going to cover it and it's suppose to keep the API the same so nothing in this workshop will change.
>> Brian Holt: Yeah. Nothing in this workshop will change except you won't be able to use perf tools. And the one thing that will change with Fiber that I don't really care about, but I will show you nonetheless. So you'll be able to have multiple top level returns.
>> Brian Holt: This does not work today.
[00:04:50] This will work with Fiber.
>> Brian Holt: But I think that that's really it.
>> Brian Holt: They're gonna do some other interesting things, something that they're talking about doing, which will not ship with 16. So if I have something like, let's see, like search. Well let's do the details. So here I have componentDidMount and I'm doing axios here.
[00:05:24] And I'm using a promise here. Eventually, when they want to get to the point where all of these life cycle methods are async methods, so that you can do async await. So I can do async componentDidMount, so instead of doing, I can say, const response = await. Await.axios.get and then rather than doing all this dot hen business down here it will do async away.
[00:06:00] If that doesn't look familiar with you then I invite you to go check out what async away does but that's kind of one of their goals and they're getting there but that's down the road.
>> Speaker 4: Follow up would be can you do that now? With a single wait and, like, a bad Poly field with the ES-2017.
>> Brian Holt: Not with the life cycle methods. No, because it has to be invoked like a new sync-method, right. And that doesn't work within the stock architecture.
>> Speaker 4: Thanks.
>> Brian Holt: Yep.