2/28/2023 0 Comments React constructor![]() ![]() ![]() This is the simplest illustration of a function's "life-cycle". So let's first look at a dead-simple example of logic that runs in the body of a function: This will best be illustrated with some examples. ( NOTE: If you want to see a live example of all the subsequent code, you can check it out here: ) Tracing the "Life-Cycle" of Functions/Hooks But when we're talking about React functional components, how exactly do we do that? Or, more to the point, where do we put that logic so it doesn't get called repeatedly on each render? That's why I often find it incredibly useful to know that I can create some bit of logic that will run once, and only once, before any other processing takes place in the component. But once you've created a functional component in React, you've handed over control of exactly how and when it gets called. Sure, you may have that comforting function keyword at the top of your code (or, even better, the arrow syntax). So from that perspective, it's understandable that there's no easy, out-of-the-box equivalent for a constructor in a functional component.īut despite the Holy Praise that JS fanboys heap upon the idea of functional programming, the simple fact is that a functional component doesn't really "run" like a true function. The biggest "problem" with life-cycles in functions/Hooks is that. The Challenge of Functional/Hooks Life-Cycles So despite the Hooks team's bold assertions, the fact is that there are times when I do need a constructor (or some equivalent). Nevertheless, there are certain times when I absolutely need logic to run before anything else in the life-cycle of this component, and I absolutely need to ensure that it will run once, and only once, for the entire life-cycle of this component. In fact, I'd say that the need for constructor-type logic is the exception, not the rule. To be clear, is a constructor usually needed in most components? No. Specifically, when I think of a constructor, I think of these characteristics.Ĭode that runs before anything else in the life-cycle of this component.Ĭode that runs once, and only once, for the entire life-cycle of this component. The massive oversimplification in their dismissive FAQ overlooks the basic fact that there are other, perfectly-valid use-cases for a constructor (or, constructor-like functionality) that have nothing to do with initializing state variables. He just pats you on the head and says, "There, there. It's like going to the dentist for a toothache - but the dentist doesn't fix the problem. This "answer" is arrogant because, based on its faulty assumptions, it boldly states that you don't need a constructor. This "answer" is ignorant because it assumes that the only reason for a constructor is to initialize state. ![]() It's similar to some of the other documentation I've seen around Hooks that makes all sorts of misguided assumptions for you. I don't know if this "answer" is ignorant. If computing the initial state is expensive, you can pass a function to useState. You can initialize the state in the useState call. Because when you look at the FAQ for Hooks, it has a section dedicated to answering, "How do lifecycle methods correspond to Hooks?" The first bullet point in this section says:Ĭonstructor: Function components don’t need (emphasis: mine) a constructor. If we transition into the functional/Hooks side of things, it would seem that the Hooks team had the same idea. If this isn't necessary, you can declare initial state directly inside the class. Enter fullscreen mode Exit fullscreen modeĪs you see, there's no need for a constructor simply to initialize your state variables, unless you have to initialize the state variables based upon the props.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |