Introduction to Components

Before we can dive into how many front-end frameworks work, we need to set a baseline of information. If you're already familiar with how the DOM represents a tree and how the browser takes that information and uses it, great; You're ready to read ahead! Otherwise, it's strongly suggested that you look at our post introducing the concepts required to understand some baselines of this post.

You may have heard about various frameworks and libraries that modern front-end developers use to build large-scale applications. Among these frameworks are Angular, React, and Vue. While each of these libraries brings its own strengths and weaknesses, many of the core concepts are shared between them.

With this book, we will outline core concepts shared between them and how you can implement them in code in all three of the frameworks. This should provide a good reference when trying to learn one of these frameworks without pre-requisite knowledge or even trying to learn another framework with some pre-requisite of a different one.

First, let's explain why frameworks like Angular, React, or Vue differ from other libraries that may have come before them, like jQuery.

It all comes down to a single core concept at the heart of each: Componentization.

What's an App, Anyway?

Before we dive into the technical aspects, let's think about what an app consists of at a high level.

Take the following application into consideration.

A mockup of a file management application. Contains two sidebars on the left and right and a file list

Our app has many parts to it. For example, a sidebar containing navigation links, a list of files for a user to navigate, and a details pane about the user's selected file.

What's more, each part of the app needs different things.

The sidebar may not require complex programming logic, but we may want to style it with nice colors and highlight effects when the user hovers. Likewise, the file list may contain complex logic to handle a user right-clicking, dragging, and dropping files.

When you break it down, each part of the app has three primary concerns:

Logic — What does the app do?
Styling — How does the app look visually?
Structure — How is the app laid out?

While the mockup above does a decent job of displaying things visually, let's look at what the app looks like structurally:

The same mockup of the file list but with everything greyed out and showing just blocks

Here, each section is laid out without any additional styling: Simply a wireframe of what the page will look like, with each section containing blocks laid out in pretty straightforward ways. This is what HTML will help us build.

Now that we understand the structure, let's add some functionality. First, we'll include a small snippet of text in each section to outline our goals. We'd then use these as "acceptance" criteria in the future. This is what our logic will provide to the app.

The same wireframe mockup but with pointers to each section outlining what logic should be added to each section

Great! Now, let's go back and add the styling to recreate the mockup we had before!

We can think of each step of the process like we're adding in a new programming language.

HTML is used for adding the structure of an application. The side nav might be a <nav> tag, for example.
JavaScript adds the logic of the application on top of the structure.
CSS makes everything look nice and potentially adds some minor UX improvements.

The way I typically think about these three pieces of tech is:

HTML is like building blueprints. It allows you to see the overarching pictures of what the result will look like. They define the walls, doors, and flow of a home.

JavaScript is like the electrical, plumbing, and appliances of the house. They allow you to interact with the building in a meaningful way.

CSS is like the paint and other decors that go into a home. They're what makes the house feel lived in and inviting. Of course, this decor does little without the rest of the home, but without the decor, it's a miserable experience.

Parts of the App

Now that we've introduced what an app looks like, let's go back for a moment. Remember how I said each app is made of parts? Let's explode the app's mockup into smaller pieces and look at them more in-depth.

A top-down 3d view of the stylized mockup

Here, we can more distinctly see how each part of the app has its own structure, styling, and logic.

The file list, for example, contains the structure of each file being its own item, logic about what buttons do which actions, and some CSS to make it look engaging.

While the code for this section might look something like this:

<section>	<button id="addButton"><span class="icon">plus</span></button>	<!-- ... --></section><ul>	<li>		<a href="/file/file_one">File one<span>12/03/21</span></a>	</li>	<!-- ... -->	<ul>		<script>			var addButton = document.querySelector("#addButton");			addButton.addEventListener("click", () => {				// ...			});		</script>	</ul></ul>

We might have a mental model to break down each section into smaller ones. If we use pseudocode to represent our mental model of the actual codebase, it might look something like this:

<files-buttons>	<add-button /></files-buttons><files-list>	<file name="File one" /></files-list>

Luckily, by using frameworks, this mental model can be reflected in real code!

Let's look at what <file> might look like in each framework:

React
Angular
Vue

const File = () => {	return (		<div>			<a href="/file/file_one">				File one<span>12/03/21</span>			</a>		</div>	);};

Here, we're defining a component that we call File, which contains a set of instructions for how React is to create the associated HTML when the component is used.

These HTML creation instructions are defined using a syntax very similar to HTML — but in JavaScript instead. This syntax is called "JSX" and powers the show for every React application.

While JSX looks closer to HTML than standard JS, it is not supported in the language itself. Instead, a compiler (or transpiler) like Babel must compile down to regular JS. Under the hood, this JSX compiles down to function calls.

For example, the above would be turned into:

var spanTag = React.createElement("span", null, "12/03/21");var aTag = React.createElement(	"a",	{		href: "/file/file_one",	},	"File one",	spanTag,);React.createElement("div", null, aTag);

While the above seems intimidating, it's worth mentioning that you'll likely never need to fall back on using createElement in an actual production application. Instead, this demonstrates why you need Babel in React applications.

You also likely do not need to set up Babel yourself from scratch. Most tools that integrate with React handle it out-of-the-box for you invisibly.

import { Component, ChangeDetectionStrategy } from "@angular/core";@Component({  selector: "file-item",  changeDetection: ChangeDetectionStrategy.OnPush,  template: `		<div>			<a href="/file/file_one">File one<span>12/03/21</span></a>		</div>	`,})class FileComponent {}

Here, we're using the @Component decorator to define a class component in Angular.

This decorator has a few properties passed to it. Going from the bottom-up:

template: The HTML associated with this component.
changeDetection: A flag we're using to tell Angular to use the non-default OnPush method of detecting changes, which provides better performance.
- All of the code examples in this book would work with OnPush or without it, but we opted to make it the default for our components to enforce the additional rules required to make OnPush works. This will set you up better for production apps in your future.
selector: The name of the component that can be referenced inside the template of another component
- You may have noticed that this component is called file-item rather than file. Unlike the other frameworks in this book, Angular requires you to have a dash (-) in your selector name to avoid confusion with native HTML tags.

It's important to note that decorators (anything starting with @) are not supported in JavaScript itself. Instead, Angular uses TypeScript to add types and other features to the language. From there, TypeScript compiles down to JavaScript.

<!-- File.vue --><template>	<div>		<a href="/file/file_one">File one<span>12/03/21</span></a>	</div></template>

This is a specially named .vue file, which defines a Vue component called "File" and has a template for which HTML should be displayed when this component is used.

Unlike the other frameworks, which require you to explicitly name your components, Vue uses the name of your .vue file to define the component's name.

Each Vue component uses an individual .vue file to contain its layout, styling, and logic. As such, these .vue files are often called "Single File Components," or SFCs for short.

While this SFC looks precisely like standard HTML with nothing special added, that will quickly change as we learn more about Vue.

These are called "components." Components have various aspects to them, which we'll learn about throughout the course of this book.

We can see that each framework has its own syntax to display these components, but they often share more similarities than you might think.

Now that we've defined our components, there's a question: how do you use these components in HTML?

Rendering the App

While these components might look like simple HTML, they're capable of much more advanced usage. Because of this, each framework actually uses JavaScript under the hood to "draw" these components on-screen.

This process of "drawing" is called "rendering". This is not a one-and-done, however. A component may render at various times throughout its usage on-screen, particularly when it needs to update data shown on-screen; we'll learn more about this later in the chapter.

Traditionally, when you build out a website with just HTML, you'd define an index.html file like so:

<!-- index.html --><html>	<body>		<!-- Your HTML here -->	</body></html>

Similarly, all apps built with React, Angular, and Vue start with an index.html file.

React
Angular
Vue

<!-- index.html --><html>	<body>		<div id="root"></div>	</body></html>

Then, in JavaScript, you "render" a component into an element that acts as the "root" injection site for your framework to build your UI around.

React
Angular
Vue

import { createRoot } from "react-dom/client";const File = () => {	return (		<div>			<a href="/file/file_one">				File one<span>12/03/21</span>			</a>		</div>	);};createRoot(document.getElementById("root")).render(<File />);

An embedded webpage:React Rendering - StackBlitz

https://stackblitz.com/github/playfulprogramming/playfulprogramming/tree/main/content/crutchcorn/collections/framework-field-guide-fundamentals/posts/ffg-fundamentals-intro-to-components/ffg-fundamentals-react-rendering-1?template=node&embed=1&file=src%2Fmain.jsx&terminal=dev

Introduction to Components

This article is part of a series: The Framework Field Guide - Fundamentals

Post contents

What's an App, Anyway?

Parts of the App

Rendering the App

Children, Siblings, and More, Oh My!

Logic

Intro to Side Effects

Display

Live Updating

Rules of React Hooks

Attribute Binding

Inputs

Multiple Properties

Object Passing

Props Rules

Event Binding

Outputs

Challenge

Creating Our First Components

Making Our Components Functional