Why components?

Jieren Chen
coderblurbs
Published in
3 min readDec 3, 2017

The best way to think about programming frameworks and the design decisions behind them is by thinking about the problems that they are used to solve.

Frontend programming is entirely dominated by the holy trinity of HTML, CSS, and Javascript. Thus, these languages are molded to be very effective at solving the problems inherent in frontend programming.

HTML and CSS are built to be declarative. “Here is what this thing should look like.” This makes sense because their purpose is to render visual elements.

Javascript is built to handle events. The code on a webpage is driven almost entirely by user initiated events. A user does something and then that triggers something else. For example: ele.on('click', () => {}).

Webpages used to be very simple. In fact there was a time when they were all just server-rendered HTML. Javascript started as a simple way to add a bit of fanciness to a webpage (click here to change this color etc.) but as it became more advanced, it started to get used to fetch data from the server (AJAX,) render large amounts of HTML (templating,) and modify HTML.

As webpages became more and more dynamic, Javascript grew to become the majority of the code for a website and we started to see a serious disconnect. Javascript was great at handling events, but now it was being used to generate and modify visual components. Javascript is not great at expressing this and this is where you would see spaghetti code with callbacks going all over the place. You could no longer get a clear picture of what something looks like by just looking at the code.

React.js is an attempt to make Javascript more declarative. So that you can write code that you can look at and immediately understand what it will look like. To accomplish this, the designers of React.js created the idea of a component. It’s all in this one sentence: components are functions with state and a lifecycle.

Components are functions of props => html.

In fact, you can write a component as a function:

function Title (props) {
return (<h1>{props.text}</h1>);
}

So even we use <h1>, we’re actually calling a React.Component that generates the <h1> HTML tag. These base level components are standardized so that they accept props similar to the attributes of the corresponding HTML tags.

Components can also have children that can be accessed through props.children. This is how you can nest components within each other.

function Content (props) {
return (<div>{props.children}</div>);
}
<Content>
<Title text="Hello"/>
</Content>

Since components are functions, they can be passed around like functions. You can create other functions/components that take components as arguments. You can map over them. The possibilities are endless.

Unfortunately, not all frontend code can be represented as pure functions (although Redux tries really hard to get there.) It’s often necessary to have some amount of local state in a component. Props are passed into the component and cannot be modified by the component. They are the arguments of the function. State, however, is within the control of the component.

Components also have a lifecycle. It can be mounted (added to the DOM,) updated, unmounted, etc. It is often useful to do things like load AJAX data when a component is mounted or reload data when it is updated. AReact.Component will have many callback functions like componentDidMount that are fired in these cases.

This is why React components are often written as a class instead of functions: to express state and lifecycle.

You will find that advanced React is just playing around with these concepts, especially the notion that components are functions.

Compound components mess around with props.children.

Higher order components wrap a component in another component, sort of like function currying.

Flux and Redux lift state out of all the components into a global store and all state flows into individual components as props.

We will specifically discuss these 3 techniques in lecture over the next two weeks, but always keep in mind that they are simply applications of the fundamental idea of components: components are functions with state and a lifecycle.

--

--

Jieren Chen
coderblurbs

Merging high brow and low brow into some kind of uni-brow.