Moving Towards a React.js Ontology
What exactly is an ontology? Why do we need one? Wikipedia describes an ontology as:
the philosophical study of the nature of being, becoming,existence or reality as well as the basic categories of beingand their relations.
Uhhhhhhhh…..way too heady for me. I like to think of ontologies as:
a set of agreed upon vocabulary used for a given subject.
I believe JavaScript (and programming in general) could use a more rigorous ontological approach. This is easier said than done, as things move fast, and many terms spring up organically overnight from blog posts (and are deprecated just as fast). But, still, I think a more rigorous effort for an ontology would be a worthy goal.
This isn’t to say that the React community and Facebook aren’t documenting terminology already, or that they’re doing a poor job. I just wanted to express that the more effort and rigor put into creating an agreed upon ontology, the easier it will be to learn React, discuss React, and grow React.
The Juice
You didn’t come here to listen to me cry about ontologies and business models. You came here for the juice. So let’s get to it. Here is (I think) the complete list of the components terms I’ve come across:
“FORMAL” TERMS OR CONCEPTS
- ReactComponent
- Class Components
- Component instance
- React.createClass Components
“INFORMAL” TERMS OR CONCEPTS
- Stateless Components
- Functional Components
- Functional Stateless Components
- Presentational Components
- Presenter components
- Container Components
- Dumb Components
- Smart Components
- Controlled Components
- Uncontrolled Components
- Parent Components
- Child Components
- Provider Component (Redux)
- Pure Components
- Higher Order Components
- Owner Components
- Presentational Components
- Presenter Components
- Container Components
- Redux Containers
- React Containers
- Parent Scene Component
- Composable Components
- View Components
- Shared Components
- Standard Components
- Reusable Components
- Built-in Components
- Composite Components
I’m sure I missed some. If you know of another, please leave a comment and I’ll be sure to add it. If you do leave a comment, try to also mention some further reading links, or an explanation of the term. That’d be a big help!
Let’s start to break these down… where are the synonyms, what is the current most oft-used terminology, etc.
“FORMAL” TERMS OR CONCEPTS
What is “Formal”?
When I say Formal, I mean they are handed down to us from the Facebook gods/docs , code base , or from JavaScript itself — as oppose to springing up from the community on github or blogs (although these terms could become formal if they get more recognition from the gods).
Without further adieu, let’s get started parsing through all these component terms.
ReactComponent
ReactComponents (as described in React’s documentation) refer to an instance of a React component class. This is “official” terminology (as oppose to a informal pattern) that is referenced in the actual React documentation.
A ReactComponent encapsulates a tree of elements. For a React component, props are the input, and an element tree is the output. The returned element tree can contain both elements describing DOM nodes, and elements describing other components. This lets you compose independent parts of UI without relying on their internal DOM structure.
It can be helpful to learn about ReactComponent and its building blocks ReactElement. I Intend to write something on this.
Class Components or ReactComponent Class
Usually when people use the term “Class Component”, they are referring to a way of declaring your React components. Since a React component is just a javascript class, you can use the ES6/ES2015 class keyword to declare your components. At the time of writing this, this class syntax is the best practice for declaring a react component. Which looks like this:
class ExampleComponent extends React.Component { render() { return <div>Hello, world.</div>; }
}
as oppose to using React.createClass:
var ExampleComponent = React.createClass({ render: function() { return <div>Hello, world.</div>; }
});
Component Instance
Let’s say we have a page on our app with a component we’ll call “Component X”. Whenever a user hits a page on your app with Component X, an “instance” (or an occurrence of) Component X is created. If “Component X” disappears when your user leaves the page (as most components do), that instance of Component X has ended. Next time your user comes back to the page, another instance of “Component X” gets created.
So if “Component X” is a form, and the form’s initial state is empty, you may notice that you can type some text in the form, leave the page, and come back to an empty form again. This concept of an “instance” at play. You just interacted with two different instances of the Component X.
React takes care of creating an instance for every class component, so you can write components in an object-oriented way with methods and local state, but other than that, instances are not very important in the React’s programming model and are managed by React itself.
Functional components don’t have instances at all. Only components declared as classes have instances, and you never create them directly: React does that for you. Although I’m not 100% what that means, the rulers of our people say it is so.
React.createClass Components
This is just another way to declare a React component. Apparently this is going to be deprecated, or at least it isn’t recommended to use going forward. This style of declaring looks like this:
var ExampleComponent = React.createClass({ render: function() { return <div>Hello, world.</div>; }
});
INFORMAL TERMS OR CONCEPTS
Okay, the “formal” terms are a little easier to write about because, well, they’re handed down by the rulers of our people. So there isn’t as much confusion/contention/esoteric-ness about them.
The informal terms are a little harder to track down the etymology of. Some are widely used, others not so widely. It can take a little work to track down people mean. Hopefully this section can save people learning React a little bit of time and frustration.
FUNCTIONAL vs. STATELESS vs FUNCTIONAL STATELESS
These are a few different methodologies for composing react components. One thing they all have in common is they don’t use the Class or React.createClass syntax for declaring the component. Otherwise, while they are all related, there are some slight differences.
Note: I hate to re-invent the wheel because Tyler Mcginnis has a great post on this subject that you should read, but here is a quick breakdown of each type of component.
Stateless Components
A stateless component is one with no “state”. That means the component will have a render function (as always), but won’t initialize any state:
const ExampleComponent = React.createClass({
//normally getInitialState would go here
render(){ return ( <div> Look Mah, No State</div> ) }
});
nor will it have a constructor to initialize a state property:
class ExampleComponent extends React.Component {
// normally constructor goes here with initial state set in it
render(){ return ( <div> Look Mah, No State</div> ) }
}
Stateless components can still have data and functionality similar to stateful components, it just needs to be passed in from its parent via props.
Functional Stateless Components
Functional Stateless Components are just functions that return some jsx and don’t have any state:
const ExampleComponent = (props) => { return ( <div> Just a normy function that returns some jsx </div> ) }
Functional Components
Apparently these aren’t out yet. But they will be similar to functional stateless components in that they are just functions that return jsx — however they will be able to have state.
I hope they are going to be WAY more performant than the ES6 class declaration. I’ll be disappointed if we get yet another way to write a component when the performance is negligible. I get that Rome wasn’t built in a day, but I think the thirst for micro-optimizations is causing a lot of JavaScript fatigue for little-to-no business value (i.e. value to the end user)… but that’s another post.
Presentational Components (aka presenter component)
This is usually juxtaposed as a dichotomy of “Presentational vs Container” components, which was originally given to us by the holiest of the Prophets, noted in one of his scriptures found here.
Honestly, I think of the easiest way to describe Presentational Components that they don’t interact with the database/ajax/http/ or the store(s). They just take in the data and display it.
Containers on the other hand are like helpers that fetch the data. Then you stick your presentational component inside of the container’s render function:
// WordOfTheDayContainer.js // Container, obvi
class WordOfTheDayContainer extends React.Component {
constructor() { super(); this.state = { wordOfTheDay: '' } }
componentDidMount() { $.ajax({
// grab word from server, set it to the state.wordOfTheDay
}); }
render() { return <WordOfTheDay word={this.state.wordOfTheDay} />; } }
then
// WordOfTheDay.js // Presentational
class WordOfTheDay extends React.Component {
constructor(props) { super(props); }
render() { return <div> The word of the day is: {this.props.word} </div>; }
}
This seems like needless abstraction and a complete overkill with the above simple example, but it should pay dividends with larger apps.
Lastly, it is worth noting that Presentational and Container components are not technically different from one another (at all). They are just a pattern, andthe main difference is their purpose: one gets data, and the other displays it. If you’ve used ember/handlebars or meteor’s blaze templating, it’s kind of like setting up a template helper, but less idiomatic (IMO).
Container Components
See the above post on presentational components as it also explains container components.
Dumb Components
This is a synonym for presentational components
Smart Components
This is a synonym for Container components
View components
This is a synonym for presentational components (or dumb components)
Fat Components
This is a synonym for Container components
Skinny Components
This is a synonym for presentational components
Screens and Components
I saw “Screens and Components” mentioned in Dan Abramov’s famousPresentational and Container Components post, but wasn’t able to track down the terms mentioned elsewhere. One can assume that they’re synonyms referring to containers and presentational components.
If you have info on these two guys, please let me know in the comments so I can update this post.
Controlled Components and Uncontrolled Components
I’m not totally set on an elegant definition for these. Most of the research I did on this term pulled up controlled/uncontrolled in reference to forms — so i’ll go with that.
A regular form input that does not set the value is considered “uncontrolled”:
export default class App extends React.Component {
render() {
return ( <form> <ControlledInput name='email' /> </form> );
}
}
A controlled input/components has the value set, like in the below example:
export default class App extends React.Component {
render() {
return ( <form> <ControlledInput name='email' value={this.state.email} /> </form> );
}
}