I’ve gotten lost somewhere in the middle of the React module. In this challenge, for example, there is an App component and a Welcome component. They are both classes, as opposed to stateless functions(??? what is that? If it’s defined earlier, I’ve missed it).
Anyway, so according to the instructions, App is the parent class, and Welcome is the child. But how it that possible? Welcome is nested in App in line 10, but Welcome doesn’t extendApp. Does this create the parent/child relationship?
They seem to be two separate components. That’s why these last few challenges aren’t very clear to me - where is the parent/ child relationship here?
So, in Welcome, if I use the this keyword, wouldn’t I be referring to an instance of Welcome? How come it gives me access to a prop defined in App?
Please help!
class App extends React.Component {
constructor(props) {
super(props);
}
render() {
return (
<div>
{ /* Change code below this line */ }
<Welcome />
{ /* Change code above this line */ }
</div>
);
}
};
class Welcome extends React.Component {
constructor(props) {
super(props);
}
render() {
return (
<div>
{ /* Change code below this line */ }
<p>Hello, <strong></strong>!</p>
{ /* Change code above this line */ }
</div>
);
}
};
In React, terms “parent” & “child” refer to the structure of how components were used in the layout. You can think of it as HTML elements and their relationships, because in the end you’re creating HTML elements with React.
Take a look at the provided example below: component that wraps other components has a parent relationship over the wrapped ones (App). Inner components are called children because they depend on their parent component.
<App> /* Parent, because it has 3 children. Could be class or function */
<Navigation /> /* child, functional or class component */
<Content /> /* child, functional or class component */
<Footer /> /* child, functional or class component */
</App>
Well, because they are and that’s the beauty of component based development. You can develop these components in isolation and they could be reused anywhere. I don’t even want to imagine what it would mean if we had to extend from a parent class for every child component. Madness!
You wouldn’t - this in Welcome would refer to Welcome instance. And you’re not accessing a prop defined in App, you’re asked to pass one from the App, to Welcome.
When React first started, all components were classes. Classes can have state, memory that persists from render to render. At some point, functional components were created. These were smaller and lighter but could not have state (or lifecycle methods). These were sometimes called “dumb” components or “stateless functional components” or “SFCs”. This is when the FCC curriculum was written.
Since then, functional components have gotten the ability to have state (through hooks) and can have the equivalent of lifecycle methods. Basically, a functional component can do anything a class component can do. So, most modern React developers don’t even bother with class components. It’s still important to learn - I have to work on old class components all the time.
We don’t really say “SFC” any more because that could also mean “stateful functional component”. We just have FCs and you can can add state to them if you want.
I hope that clears up some of the terminology/history.
Thank you both, first of all, for clarifying. I think a lot of my confusion here comes from having studied Java, which is all about OOP, and so terms like parent, child, extends, and this each have their own very particular meanings.
For example, in Java, a child extends the parent (one parent per child, no multiple inheritance).
I don’t even want to imagine what it would mean if we had to extend from a parent class for every child component. Madness!
That’s exactly what happens in Java, no?
So, the React library or language (can we call it a language?) seems to be a mixture of OOP principles and HTML. Is that a good way to think about it? It has classes and instances (and this) like Java, but parent/child relationships, as well as basic syntax, is like HTML?
At some point, functional components were created. These were smaller and lighter but could not have state (or lifecycle methods). These were sometimes called “dumb” components or “stateless functional components” or “SFCs”
Doesn’t that just mean “functions” in a procedural way (like in good old C)? No states (aka properties) because they are not objects? Or are they objects in the sense that every function in JavaScript is an object (even if it’s purely “procedural” in essence, like just taking an input and doing some math on it)?
I might be making a bit a mess here in terms of the terminology, but it is important to understand. I’ve had some training in C (hardcore procedural), Java (hardcore OOP), and now am learning JavaScript and FrontEnd (which is more along the lines of functional programming, right)? React seems to be combining a lot of the latter two approaches.
In JS, functions are objects. Normally (at least with typical usage) a JS function does not have state, but there are ways to add state to an FC, most commonly with the useState hook. In a sense and FC is just a JS function, but specifically it is a function that returns a JSX node. It normally will not have state unless you add it.
So, the React library or language (can we call it a language?) seems to be a mixture of OOP principles and HTML
I’d call it a library. And anything OOP in React is just coming from JS - JS has classes, too. But keep in mind that JS is not true OOP, but is rather “OOP-ish”. You can read about it.
Thanks @kevinSmith for explaining. It’s a bit confusing still, and I suspect it’s one of these things that will clarify with “hours spent” actually coding. I understand from this that a functional component (FC) is a function that may or may not have a state - most importantly it needs to return a JSX node.
What is a JSX node, exactly? Aren’t JSX components just objects, or rather variables that encapsulate a function, like in “regular” JavaScript?
JSX isn’t an object because it isn’t JavaScript. It will be converted into the complex JavaScript and HTML it needs to be by the babel transform. When you have JSX, you’re kind of leaving JavaScript and temporarily entering a world of pseudo HTML and CSS where you can inject JS. How that works is a complicated subject. How a car works is an interesting subject but will be a distraction if your goal is to learn to drive. I would focus more on what React does than how.
A FC is a function that returns a node of JSX. You can use the use state hook to give it state
By node of JSX I mean that it has to have one parent node. You can’t two parents that are siblings at the top level. If you try that React will complain. If that happens, you wrap them in a div or a Fragment and the problem is solved.
JSX is a syntax for writing functions [though technically could be anything I guess, not necessarily functions], using XML, such as that it looks like the thing you’re going to render.
Components are a function that returns a function. The function that gets returned is the thing used to tell the library to render {something}. So for browsers, that {something} is going to be an HTML node.
So you don’t need to use JSX, you can directly write what it’s going to compile to, like this:
Those are exactly the same, intent is just a lot clearer when using JSX.
Yep, most popular previous UI frameworks were/are very explicitly OO, work as you describe.
I’d not get too hung up on the fact it uses classes, that’s just an implementation detail – it uses them because that was the easiest mechanism to have the little bundles of stateful code that make up components. But then most newer code written against React doesn’t use classes, it uses functions, and it works in the same way.
parent/child, yes, like HTML. But further to that it’s as descibed above – graphs/trees. So parent/child is more just [visually, conceptually] “what’s above/below this node in the tree”, not parent/child as in “class extends/inherits from other class”.
Very much taking ideas from functional rather than OO. Some elements of the latter, but not many.
So going back to the example where I replaced the JSX with the actual function calls, it’s that all the way down. So it’s gonna create a model which has a reference id to each of those component functions.
As a simplification: say your app runs for the first time, goes through executing all those functions in the components in turn – they’re going to do something like (in the browser) translate to window.document.createElement and other DOM API functions – and that builds up the HTML.
Then, when you send an event from the browser, click on a button or whatever, that’s going to get passed back in to the React runtime with the reference id. Then React can call the component function the id refers to, which in turn will trigger all the “children” of that component to be executed, which will cause that part of your app to rerender in the browser.
It is a relatively simple solution to UI programming (in comparison to what OO UI programming can turn into). It’s just running a given function + all its “child” functions over and over and over again.
You take some data, you pass it into some functions (the defined components), that creates a model of the UI (handled by React), that model gets passed to a library that can convert it to HTML (react-dom is that library for React browser apps). You do something in the browser that alters the data, you passes the updated data into some functions, that returns a model of the UI, that model gets passed to a library that can convert it to HTML. And so on, ad infinitum.
So it is a functional approach rather than an OO approach; the UI is a function of the [current] state. That has some downsides, but the general principle is pretty good.
In a purely functional language, the OO approach just doesn’t really work, because a. there’s no state and b. everything is immutable. You have to pass data to functions, you can’t attach functions to data. JS isn’t a purely functional language, and you can have mutable state, no problem. But functional approaches tend to suit the language.
Hey @DanCouper and @kevinSmith , thanks very much for your detailed responses. It’s holiday time here so I’ve been away for a bit, so I’ll dive down in to the replies as soon as I get to back to working on React. It’s quite a new thing compared to the C (Linux terminal) and Java (Eclipse) work that I’m used to, so it would take me sometime to get comfortable with React and UI frameworks, I imagine. Just now struggling with the D3 projects
Really appreciate the time and effort, important for me to say.
