Front-end Development

22 May 2020 View Comments
#programming #react #javascript #js #front-end

I vaguely remember my very first website done using Dreamweaver in the year 1999. Back in the year, my focus was on making the site appear prettier using static images. I spent a lot of time trying to make these images look more attractive by working on Photoshop on those “CRT” MAC.

Since then, the internet evolved rapidly, and we started to have standard ways of displaying the website. All browsers were all adapting to these standards. It was when most of us dived into the world of building HTML-based websites. As we found ourselves require to manipulate sites, we started to mangle HTML blocks using JavaScript and CSS.

Customers desired faster loads (immediate feedbacks) on actions they do. Therefore, various approaches attempted to mitigate this burden. That’s when we found ways to manipulate HTML through a tree structure called Document Object Model (DOM); this eventually opened a whole new world.

React.js allows us to manipulate DOM easily through what’s we call components. This concept is powerful, not only because we can manipulate and manage the DOM but also because we can easily create reusable UI through “components” and dynamic states. This concept truly segregated back-end and front-end components. As some of you may know, we dealt with most of the back-end actions using some kind of templates. With the DOM manipulation approach, we do not depend on the back-end to prepare the JS/HTML/CSS for us. We do most of the display work in the front-end, and leave back-end for some critical updates/analytics work/submissions (CRUD) the data obtained.


When Facebook first open-sourced React.js, it wasn’t all that popular. Most of us probably remember it as a solution to “Facebook’s Timeline.”

Without a strong community, it wasn’t all that useful. As popularity gained around React 16, React’s fundamental behaviours were specified, and the design was becoming more concrete and useful. Specifically, focusing on components and their states, keeping its uni-directional data flow, which preserved the tree-like structure. The users started to realize the real value.

Nevertheless, it was still somewhat challenging to use React, like how you need to understand how JSX components and steps to how it renders the page into the plain vanilla JavaScript, how dependencies resolved, etc. The proper design was challenging, mounting, unmounting and states sharing concepts confused us a lot.

A lot of those things eventually got standardized; ECMAScript2015 standardized most of the code written in JavaScript, which was more intuitive and formalized.

Basic component/design

Managing different components and different states were becoming vital pieces in React.js world, there were myriad discussions of the component design and proper use of the “states.” Having a concrete component design and defining “states” are the keys to building a successful React application.

From my experience, Here is my general rule of thumb when making a good React design. First, we need to create components reusable by decomposing it to smaller-sized and generic components and decide the required state and where they should live. Note, “states” are not a requirement in React, but they are the building blocks in making dynamic websites.

Eventually, wrapping your head with the components/states design, we should picture ourselves, when we make an action (event), what state(s) are we changing? And how that change is going to have an impact on our view (DOM, mobile, device, etc.).

Personal React Projects

Share this post


I am a passionate programmer working in Vancouver. I strongly believe in art of algorithms and together with it to write clean and efficient software to build awesome products. If you would like to connect with me, choose one from below options :) You can also send me an email at