With JavaScript frameworks taking over our front end world, it’s important to understand a few key principles that the major three frameworks push. When building a web-based application you’ll be tasked with structuring how everything communicates.

Most people will be aware that you should use different components to adhere to S.O.L.I.D principles, avoiding repetition in your application, making changes and additional features quicker and easier to integrate into the current solution. The actual creation and interaction between those components can be seperated in a number of ways but the simplest for me is considering them as Smart or Dumb.

SMART

Contains dependencies that are application-specific. Services are injected in the constructor of these containers.

Also known as Controller components or Container components that can:

• Manipulate Data
• Call out to external resources (libraries, APIs)
• Manage State

In essence, these can be thought about as a container, page or section implementing a specific task of the user.

DUMB

Recieves data and displays the information.

Also, know as Presentation components or Pure components that can:

• Allow for data to be passed in
• Display that data in a specific format and style

These can be thought of as where you create the final HTML and CSS for what something will look like on the screen. This is where you style your application and interact with the user.

Interaction

A smart component will contain one or more dumb components within them. The smart components will pass the data they receive down into these presentation components which then render the data as required.

If there is any interaction required between a smart and dumb component then a event will be fired back up to the smart component to deal with.

Purpose

So why do we need to separate our application this way? Well as in any form of programming, following specific paradigms or approaches is not strictly enforced or required to allow and application to function, but will usually have a number of benefits down the line.

Reusability is always heralded as a major benefit to most programming approaches. Following the D.R.Y principle of (Do)Not Repeating Yourself means that you can add the same functionality to different areas quickly and effectively.

Refactoring a part or whole of an application only requires changes in a smaller number of places.

Readability It’s easier to read component names to figure out what something does rather than having to dissect reams of HTML!

Running Tests Last but not least, testing smaller self-contained components makes creating and managing your suite of tests easier.

Separating the concerns of your application across these two types of components, in whichever way you want to describe them should make the task of creating a web app in React, Vue or Angular a much nicer and easier process for all those involved.

If you feel differently, as Dan Abramov has recently done then please feel free with sharing your opinions below.