DEV Community: Nasidul Islam

Javascript Event Handling - Deep Dive

Nasidul Islam — Tue, 22 Jun 2021 14:00:26 +0000

An unopinionated research (white) paper on front end event handling under the hood.

Introduction
Overview
Deep Dive
- React
- Vue
- Angular JS
- Svelte
- jQuery - 1.6.4
Resources

Introduction

Objective

The article takes an impartial approach at researching event handling in various UI tools. The content is based on official documentation -- NOT on opinion.

Purpose

The purpose is to understand how the same "problem" was solved across these tools.

What this article is NOT

This article does not assess the pros and cons -- neither does it recommend one tool over another.

Overview

The world of Javascript evolves at a breakneck speed. For the longest time, a webpage would consist of a single, monolithic script file that handled everything - starting from enabling interactivity on the page to calling services and rendering content. The pattern has significant drawbacks. Monolithic architectures are difficult to scale and maintain in the long term. Especially at enterprise level where there are several engineers contributing code, a monolithic architecture tends become a spaghetti mess that is hard to debug.

The inherent nature of Javascript allows engineers to innovate over this pattern and come up with ingenious ways to tackle the drawbacks. There are many, many, front end libraries and frameworks out there these days, each with its own superpowers and opinionated ways of approaching the problem. As a result, modern day developers are spoilt for choices when it comes to picking a system to built their application.

Although the list of tools at the disposal of developers is exhaustive, not many have stood the test of time and battle. In this article, we will investigate the ones that have come out (fairly) unscathed, in an attempt to understand how they handle events.

Deep Dive

In this section, we will deep dive into several popular, publicly available UI libraries and frameworks to investigate how they handle events. Let’s start with arguably the most popular.

Handling events in React

Event handling in React centers around ReactBrowserEventEmitter. The very first comment in the source code does a decent job of explaining how it works.

Summary of ReactBrowserEventEmitter event handling:

Let's dive deep and break each of them down:

--> Top-level delegation is used to trap most native browser events. This may only occur in the main thread and is the responsibility of ReactDOMEventListener, which is injected and can therefore support pluggable event sources. This is the only work that occurs in the main thread.

React uses event delegation to handle most of the interactive events in an application. This means when a button with an onClick handler is rendered

<button onClick={() => console.log('button was clicked')}>Click here</button>

React does not attach an event listener to the button node. Instead, it gets a reference to the document root where the application is rendered and mounts an event listener there. React uses a single event listener per event type to invoke all submitted handlers within the virtual DOM. Whenever a DOM event is fired, those top-level listeners initiate the actual event dispatching through the React source code — it re-dispatched the event for each and every handler. This can be seen in the source code of EventPluginHub.

--> We normalize and de-duplicate events to account for browser quirks. This may be done in the worker thread.

React normalizes event-types so that so that each and every browser, regardless of its underlying engines or whether its old or modern, will have consistent event arguments. This means, across all browsers, devices and operating systems, a click event will have arguments like this

boolean altKey
boolean metaKey
boolean ctrlKey
boolean shiftKey
boolean getModifierState(key)
number button
number buttons
number clientX
number clientY
number pageX
number pageY
number screen
number screenX
DOMEventTarget relatedTarget

Further reading: events supported in React, read this.

--> Forward these native events (with the associated top-level type used to trap it) to EventPluginHub, which in turn will ask plugins if they want to extract any synthetic events.

React considers the nature of each event and categorizes them into buckets. It has dedicated plugins built to manage events in each bucket. Each of these plugins are then in turn responsible for extracting and handling the various event types in that bucket. For instance, the SimpleEventPlugin will handle events implemented in common browsers such as mouse and key press events (source) and ChangeEventPlugin will handle onChange events (source). The final piece that unifies all the plugins into a single place and re-directs events to each individual plugin is the EventPluginHub.

This opens the door for us to understand how React views events. React introduces the concept of SyntheticEvents, which React defines as "implementation of the DOM Level 3 Events API by normalizing browser quirks". Basically, it is a wrapper around the browser's native event object with the same interface — and that it works in identical fashion across all browsers.

For React v16 and earlier, synthetic events utilizes a polling mechanism. This mechanism ensures that the same object instance is used in multiple handlers, but it is being reset with new properties before each and every invocation and is then disposed.

--> The EventPluginHub will then process each event by annotating them with "dispatches", a sequence of listeners and IDs that care about that event.

In the React ecosystem, a single event listener is attached at the document root for any one event-type. Since each event type will most likely have multiple handlers, React will accumulate the events and their handlers (source). Then, it will do relevant dispatches, which consist of event handlers and their corresponding fiber nodes. The fiber nodes are nodes in the virtual DOM tree. Fiber nodes are calculated using React’s Reconciliation algorithm, which is its “diffing” algorithm to drive updates on the page.

Further reading: React Fiber Architecture

Further reading: React Reconciliation concept

--> The EventPluginHub then dispatches the events.

The final piece of the puzzle — the plugin hub goes through the accumulated information and dispatches the events, thus invoking the submitted event handlers (source).

Simple Demo

Here is a simple click handler demo implementation in React --> Link.

Handling events in Vue

In Vue, you create .vue file that contains a script tag to execute javascript and a template tag that wraps all markup (both DOM and custom elements). This is a self contained instance of a Vue component that could also contain a style tag to house the CSS.

--> Simple DOM events handling

Vue allows developers to bind events to elements using v-on:<event-name> or in short, @<event-name directive, and to store the state of application in a data prop. All the event handlers are stored similarly in a methods prop on the same object.

// App.vue

<template>
    <div id="app">
        <HelloWorld :msg="msg" />
        <button @click="greet('World', $event)">
            click here
        </button>
    </div>
</template>

<script>
    import HelloWorld from "./components/HelloWorld";

    export default {
        name: "App",
        components: { HelloWorld },
        data: function () {
            return { msg: "Vue" };
        },
        methods: {
            greet: function (message, $event) { this.msg = message; }
        }
    }
</script>

The application will load with a message of “Hello Vue”. When the button is clicked, the handler will set the message to World and display a “Hello World” message --> REPL. It is possible to access the original DOM event by passing in an object from the handler reference and accessing in the event handler.

--> Event Modifiers

Although it is possible to access the DOM event object in the handler by simply passing it in, Vue improves developer experience by allowing to extend event handling by attaching ‘modifiers’ to it. This way, Vue will handle the modifiers for you instead of the developer calling those modifiers explicitly in their handlers. Multiple modifiers can be attached by using a dot delimited pattern. The full list of supported modifiers is as follows:

.stop
.prevent
.capture
.self
.once
.passive

Thus, a simple example would look like this

/* this will trigger the handler method only once */

<button v-on:click.stop.once="clickHandler">Click me</button>

Link --> REPL.

--> Key Modifiers

Vue has a feature to attach keyboard events in almost identical fashion as regular event handlers. It supports a list of aliases with commonly attached keyboard events such as the enter and tab keys. The full list of aliases is given below:

.enter
.tab
.delete (captures both the "Delete" and "Backspace" keys)
.esc
.up
.down
.left
.right
.space

A simple example would look like the following

<!-- only call `vm.submit()` when the `key` is `Enter` -->

<input v-on:keyup.enter="submit">

LInk --> REPL.

--> Custom Events

Vue handles publishing and subscribing to custom events. The caveat here is that every component that should listen for events should maintain an explicit list of those custom events. A simple example would look like this

// emit event
this.$emit('myEvent')

// bind to the event
<my-component v-on:myevent="doSomething"></my-component>

Unlike components and props, event names will never be used as variable or property names in JavaScript, so there’s no reason to use camelCase or PascalCase. Additionally, v-on event listeners inside DOM templates will be automatically transformed to lowercase (due to HTML’s case-insensitivity), so v-on:myEvent would become v-on:myevent -- making myEvent impossible to listen to. Vue JS as a framework recommends using kebab-casing for event names.

Link --> REPL.

Angular is one of the first generation, opinionated frameworks that focuses towards building Single Page Applications (SPAs). Although it has gone significant re-invention in recent times, it still falls short in a number of ways when compared to the more modern tools available to developers these days (some of which are discussed in this article). It is still, however, valuable to take a peek at how the framework binds and handles events.

Handling events in Angular (4.x and above)

Angular has a very specific syntax to bind and handle events. This syntax consists of a target event name within parentheses to the left of an equal sign, and a quoted template statement to the right (source).

A simple example of DOM event binding and handling looks like this

<button (click)="onSave()">Save</button>

When events are being bound, Angular configures an event handler for the target event — it can be used with custom events as well. When either the component or the directive raises the event, the handler executes the template statement. Then, the template statement performs an action in response to the event.

In Angular, it is possible to pass an $event object to the function handling the event. The shape of the $event object is determined by the target event. If the event is a native DOM element event, then the $event object is a DOM event object. Lets look at a simple example (source)

<input
    [value]="currentItem.name"
    (input)="currentItem.name=$event.target.val"
/>

There are a couple of things happening here:

The code binds to the input event of the <input> element, which allows the code to listen for changes.
When the user makes changes, the component raises the input event.
The binding executes the statement within a context that includes the DOM event object, $event.
Angular retrieves the changed text by following the path $event.target.vaue and updates the name property.

If the event belongs to a directive or component, $event has the shape that the directive or component produces.

Link --> REPL.

Handling events in Svelte

In Svelte, you create a .svelte file that is meant to self contain a component instance with its CSS, JS and HTML, along with any custom elements that are needed.

--> Simple DOM events handling

A simple demo for a click handler will look like the following:

<script>
    let name = 'world';
    function update() { name = 'Svelte'; }
</script>

<span on:click={update}>Hello { name }</span>

This will print Hello World on load, but will update and print Hello Svelte when user clicks on h1 -> REPL. This is the general pattern in which DOM events such as click, mousemove, etc are implemented in Svelte (it supports inline handlers as well).

--> Event Modifiers

The system allows developers to add pipe delimited modifiers to the event, such as preventDefault and stopPropagation. The handler function is able to accept an event argument that also has access to these modifiers, but Svelte offers an improvement in developer experience by offering these shorthands. An example would look like the following:

<script>
    function handleClick() { alert('This alert will trigger only once!'); }
</script>

<button on:click|once={ handleClick }>Click here</button>

Thus, the pattern looks like on:<event-name>|modifier1|modifier2|... -> REPL. The full list of modifiers is below (source):

preventDefault - calls event.preventDefault() before running the handler. Useful for client-side form handling
stopPropagation - calls event.stopPropagation(), preventing the event from reaching the next element
passive - improves scrolling performance on touch/wheel events (Svelte will add it automatically where its safe to do so)
nonpassive - explicitly set passive: false
capture - fires the handler during the capture phase instead of the bubbling phase (MDN docs)
once - remove the handler after the first time it runs
self - only trigger handler if event.target is the element itself

--> Dispatching events

In Svelte, a parent component can update state based on data dispatched from a child component using a function called createEventDispatcher. The function allows the child component to emit a data object at a user defined key. The parent component can then do as it pleases with it -> REPL (open console to see dispatched data object).

--> Event forwarding

The caveat to component events is that it does not bubble. Thus, if a parent component needs to listen on an event that is emitted by a deeply nested component, all the intermediate components will have to forward that event. Event forwarding is achieved by adding the custom data key on each wrapper component as we traverse up Svelte DOM. Finally, the parent component where the event needs to be handles implements a handler for it -> REPL (open console to see demo).

--> Actions

The final piece in Svelte event handling is the implementation of actions. Actions are element level functions that are useful for adding custom event handlers. Similar to transition functions, an action function receives a node and some optional parameters and returns an action object. That object can have a destroy function, which is called when the element is unmounted -> REPL (borrowed from Svelte official resources).

Further reading: Svelte official tutorials

Further reading: Compile Svelte in your head

Handling events in jQuery

The primary benefit of using jQuery is that it makes DOM traversal and manipulation quite convenient. Since most browser events initiated by users are meant to provide UI feedback, this feature handy. Under the hood, jQuery uses a powerful "selector" engine called Sizzle. Sizzle is a pure JS-CSS selector engine designed to be dropped in to any host library.

Let’s look at the programming model and categories of how jQuery binds and handles events. The “source” links provided is the official documentation of the APIs and has additional information of how they work:

--> Browser Events

Source: Browser Events

jQuery is able to handle the following browser events out of the box.

.error(): Bind an event handler to the "error" JS event (source)
.resize(): Bind an event handler to the "resize" JS event, or trigger the on an element (source)
.scroll(): Bind an event handler to the "scroll" JS event, or trigger the event on an element (source)

--> Document Loading

Source: Document Loading

jQuery provides a short list of out of the box APIs to handle events related to initial page load

jQuery.holdReady(): Holds or releases the execution of jQuery's ready event (source)
jQuery.ready(): A Promise-like object that resolves when the document is ready (source)
.load(): Bind an event handler to the "load" JS event (source)
.ready(): Specify a function to execute when the DOM is fully loaded (source)
.unload(): Bind an event handler to the "unload" JS event (source)

--> Form Events

Source: Form Events

jQuery provides a decent list of out of the box APIs to handle commonly occurring form events

.blur(): Bind an event handler to the “blur” JS event, or trigger that event on an element (source)
.change(): Bind an event handler to the “change” JS event, or trigger that event on an element (source)
.focus(): Bind an event handler to the “focus” JS event, or trigger that event on an element (source)
.focusin(): Bind an event handler to the “focusin” JS event (source)
.focusout(): Bind an event handler to the “focusout” JS event (source)
.select(): Bind an event handler to the “select” JS event, or trigger that event on an element (source)
.submit(): Bind an event handler to the “submit” JS event, or trigger that event on an element (source)

--> Keyboard Events

Source: Keyboard Events

The following are out of the box APIs provided by jQuery to handle keyboard events

.keydown(): Bind an event handler to the "keydown" JS event, or trigger that event on an an element (source)
.keypress(): Bind an event handler to the "keypress" JS event, or trigger that event on an an element (source)
.keyup(): Bind an event handler to the "keyup" JS event, or trigger that event on an an element (source)

--> Mouse Events

Source: Mouse Events

This is where jQuery begins to shine as far as event handling is concerned. It offers a large suite of mouse event binders out of the box for developers to use.

.click(): Bind an event handler to the "click" JS event, or trigger that event on an an element (source)
.dblclick(): Bind an event handler to the "dblclick" JS event, or trigger that event on an an element (source)
.contextmenu(): Bind an event handler to the "contextmenu" JS event, or trigger that event on an an element (source)
.mousemove(): Bind an event handler to the "mousemove" JS event, or trigger that event on an an element (source)
.mouseout(): Bind an event handler to the "mouseout" JS event, or trigger that event on an an element (source)
.mouseover(): Bind an event handler to the "mouseover" JS event, or trigger that event on an an element (source)
.mouseup(): Bind an event handler to the "mouseup" JS event, or trigger that event on an an element (source)
.toggle(): Bind an event handler to the "toggle" JS event, or trigger that event on an an element (source)
.hover(): Bind an event handler to the "hover" JS event, or trigger that event on an an element (source)
.mousedown(): Bind an event handler to the "mousedown" JS event, or trigger that event on an an element (source)
.mouseenter(): Bind an event handler to the "mouseenter" JS event, or trigger that event on an an element (source)
.mouseleave(): Bind an event handler to the "mouseleave" JS event, or trigger that event on an an element (source)

--> The Event Object

Souce: Event Object, Inside Event Handling Function

Event handlers in jQuery accepts the event object as the first argument. This object has access to various properties and modifiers. Here is a list of the more commonly occurring ones:

event.currentTarget(): The current DOM element within the event handling bubbling phase (source)
event.target(): The DOM element that initiated the event (source)
event.data(): Optional data object passed to the handler when the current executing handler is bound (source)
event.preventDefault(): If this method is called, the default action of the event will not be triggered (source)
event.stopPropagation(): Prevents the event from bubbling up the DOM tree, preventing any parent handlers from being notified of the event (source)

Note: Information below this point is related to jQuery versions later than 1.6.4

--> The .on() Event Handler Attachment API

Source: The .on() Event Handler Attachment API

Modern versions of jQuery provides an all-encompassing API to handle events -- the .on(). This API is designed to bind almost all of the events listed above with one single stroke. It is the recommended way to bind events (according to official documentation) from jQuery - 1.7 version and onwards. A few syntax examples can be seen below:

// Markup to be used for all examples that follow
<div class='outer'>
    <span class='inner'>Any content</span>
</div>

// Exhibit A: the simple click handler, targeting the inner span
$('.outer .inner').on('click', function(event) {
    console.log(event);
    alert( 'inner span was clicked!!' );
});

// Exhibit B: attaching separate handlers to different event types
$('.outer .inner').on({
    mouseenter: function() {
        console.log( 'hovered over a span' );
    },
    mouseleave: function() {
        console.log( 'mouse left a span' ); 
    },
    click: function() {
        console.log( 'clicked a span' );    
    }
});

// Exhibit C: attaching the same handler to different event types
$('.outer .inner').on('click', function() {
    console.log( 'The span was either clicked or hovered on' );
});

// Exhibit D: Event delegation --> binding events to elements that don't exist yet
$('.outer .inner').on('click', '<selector-of-element-that-dont-exist-yet>', function() {
    console.log( 'The element was clicked' );
});

--> Other Event Handler Attachment APIs

Source: Event Handler Attachment

The .on() API is arguably the most popular API offered by jQuery. Apart from it, there are other interfaces jQuery has out of the box that provides a useful suite of functionality. The following is a list of the most commonly occurring ones:

one(): Attach a handler to an event for the elements. The handler is executed at most once per element per event type (source)
off(): Remove an event handler (source)
trigger(): Execute all handlers and behaviors attached to the matched elements for the given event type (source)

Resources

List of front end JS frameworks
React
Svelte
- Svelte official tutorials
- Compile Svelte in your head
Vue
Angular
- Event handling
- Event binding concepts
jQuery

Advanced React + Webpack 4 + Babel 7 Application Setup

Nasidul Islam — Mon, 13 Apr 2020 19:53:29 +0000

The world of building user interfaces can be a complex landscape to navigate. The sheer number of tools that are at the disposal of a developer is overwhelming. In my last tutorial , we discussed a few of those tools (React, Webpack and Babel) and went over the basics of what they are and how they work. More over, we also learnt how we can stitch them together to build an application code base from scratch that is suitable for development.

The application that was pieced together has minimal features. It does not allow us to test the code we're writing, among other things, and it's certainly not suitable for deploying to production. In this guide, we will build on top of the setup we have and take it further

Learn Dev + Production environment configs
Add test frameworks
Sass
ESLint
Static assets (images, SVG icons, font icons, font families)

The introduction segments can be skipped. Click here to jump straight to the step by step guide .

Environment configuration

An application consists of features and every feature has a life cycle --- from it being developed, then going through testing and finally being deployed to production, it lives on different environments (envs). The environments serve different purposes and therefore, their needs vary accordingly.

For instance, we don't care about performance or optimization in dev env, neither do we care about minifying the code. Often, we enable tools in dev env that helps us write code and debug it, like source maps, linters, etc. On the other hand, on prod env, we absolutely care about stuff like application performance and security, caching, etc. The tools we are going to use while walking through this guide is not going to play with all the items we discussed here, however, we will go through basics (and some more) of how environment configuration works and why it is useful.

Test Frameworks

A test framework provides us with a platform and a set of rules that allows us to test the code we're writing. Any application that is intended to be deployed for users must be tested. Here is why:

It helps reduce the number of bugs --- and if we write new tests for the ones that do come up, we greatly minimize the chance of that particular bug re-appearing.
It gives us confidence when attempting to refactor code. A failing test would mean the refactored code did not satisfy that particular scenario.
Improves code quality, because developers are bound to write code that is testable, although writing good tests is an entirely different (and extremely valuable) skill of its own
All the reasons above reduce overall cost of development in the long run (fewer bugs, better code quality, etc.)
Well written tests becomes a form of documentation in itself of the code for which the test is being written.

The frameworks come in various different flavors --- and they all have their pros and cons. For our purposes, we will use two of the more popular frameworks, Jest to test functional JS and Enzyme to test our React components.

Sass

As the application grows in size, it starts to present maintainability and scalability concerns for developers. CSS is one such area where the code can get real messy real fast. Sass is a tool that helps us in this regard:

Compiles to CSS, so the end result is familiar code.
It allows nesting selectors. This enables developers to write cleaner and fewer lines of code and opens the door for more maintainable stylesheets.
It allows for creating variables, mixins, further promoting maintainability.
Conditional CSS, exciting stuff !!
It is industry approved --- performant and formidable community support.

No reason to not use a tool that will surely improve our development workflow, right?

ESLint

Another point of concern as the code base begins to grow is ensuring high standards of code quality. This is especially more important when there are multiple teams or developers working on the same code base. ESLint saves the day here --- it enforces common coding standards, or style guides, for all devs to follow. There are many industry approved style guides out there, for instance Google and AirBnB. For our purposes, we will use the AirBnB style guide.

Static Assets

This encompasses all the pretty stuff that will be used in the application --- custom fonts, font icons, SVGs and images. They are placed in a public folder, although an argument can be made for a different setup.

Please note: The rest of the guide builds on top of the last piece I wrote. You can either follow that first before proceeding here, or do the following:

Ensure that that you have node version 10.15.3 or above. Open up your terminal and type in node -v to check. If the version does not match the requirements, grab the latest from here .
Once you're good with the above, grab the repo and follow the installation instructions in the README.
After installing the dependencies using npm install, run npm start to compile the code and spin up the dev server. At this point, you should see a new browser tab open, rendering a hello world component. Make sure you're inside the repository directory that you just "git cloned" before trying out the command.

After having gone through the basics of the tools we're about to use and setting up our base repo, we can finally move forward to the guide.

Step 1

Assuming repo has been successfully downloaded, open it up in a text-editor of your choice. You should see a file called webpack.config.js. This is where webpack configs currently live in its entirety.

In order to separate production and development builds, we will create separate files to host their configs, and another file will contain settings that are common between them, in the interest of keeping our code DRY.

Since there will be at least 3 config files involved, they will need to merge with each other at compile time to render the application. To do this, we need to install a utility package called webpack-merge to our dev dependencies.

npm install webpack-merge --save-dev

Then rename webpack.config.js to webpack.common.js. As the name implies, this will contain the common configs. We will create two more files

webpack.production.js --- to contain production env settings
webpack.development.js --- to contain development env settings

While we're on the subject of configuring webpack builds, we will take the opportunity to install a couple of npm packages that will help with our tooling and optimize our builds.

First, we will install a package called CleanWebpackPlugin .

npm install clean-webpack-plugin --save-dev

Webpack puts the output bundles and files in the /dist folder, because that is what we've configured it to do. Over time, this folder tends to become cluttered as we do a build every time (through hot reloading) we make a code change and save. Webpack struggles to keep track of all those files, so It is good practice to clean up the /dist folder before each build in order to ensure the proper output files are being used. CleanWebpackPlugin takes care of that.

We will install another package called path. It will allow us to programmatically set entry and output paths inside webpack.

npm install path --save

Now that we have the necessary packages in place to configure a clean, optimized webpack build, lets change webpack.common.js to contain the following code,

const path = require('path');
const { CleanWebpackPlugin } = require('clean-webpack-plugin');
const HtmlWebPackPlugin = require("html-webpack-plugin");

module.exports = {
    output: {
        filename: '[name].bundle.js',
        path: path.resolve(__dirname, 'dist')
    },
    module: {
        rules: [
            {
                test: /\.(js|jsx)$/,
                exclude: /node_modules/,
                use: {
                    loader: "babel-loader"
                }
            },
            {
                test: /\.html$/,
                use: [
                    {
                        loader: "html-loader"
                    }
                ]
            }
        ]
    },
    plugins: [
        new CleanWebpackPlugin(),
        new HtmlWebPackPlugin({
            template: "./src/index.html",
            filename: "./index.html",
        })
    ]
};

Add the following lines to webpack.development.js

const merge = require('webpack-merge');
const common = require('./webpack.common');

module.exports = merge(common, {
    mode: 'development',
    devtool: 'inline-source-map',
    devServer: {
        contentBase: './dist',
        hot: true
    }
});

... and these lines to webpack.production.js

const merge = require('webpack-merge');
const common = require('./webpack.common');

module.exports = merge(common, {
    mode: 'production'
});

There are a few changes here from its previous iteration that requires explanation:

webpack.common.js
- Note that we've added an output property. It renames the bundle file and defines the path to where it can be found.
- We no longer have the dev server definition in here.
- We are making use of CleanWebpackPlugin to clean up dist folder
webpack.development.js
- The dev server definition has been moved to this file, naturally
- We have enabled source maps
webpack.production.js
- It only contains mode definition at the moment, but opens up the door to add additional tinkering later on.

That was a lot of information! We have accomplished a significant step towards setting up the project. Although I have tried my best to explain the concepts and code changes, I would advise additional reading into each of these topics to get a complete grasp. Webpack is a beast --- it might be a stretch even for the smartest developer to completely understand everything in the first read through.

Let's move on to the next step.

Step 2

We will add test frameworks to our code base in this step! There are two frameworks we need to add, one to test functional JS and the other to test React components. They are called Jest and Enzyme, respectively. Once we configure that, we will write a small, uncomplicated JS module and React component to try them out.

We will set them up and work with them in separate steps. Let's get started!

We will install Jest first as a dev dependency, since it is a test framework and it has no use in the production bundle. To install,

npm install jest --save-dev

Next, we will add a file called jest.config.js to the root directory of our codebase that will dictate how we want to configure our tests. This is the official documentation page for Jest that contains details of every piece of configuration --- it is worth giving a read.

We will not need all the pieces, thus I have condensed the necessary pieces to write our own custom config file. It contains detailed comments on what each piece is doing. This is what jest.config.js file will look like for the project we're configuring

// For a detailed explanation regarding each configuration property, visit:
// https://jestjs.io/docs/en/configuration.html

module.exports = {
    // All imported modules in your tests should be mocked automatically
    // automock: false,

    // Stop running tests after the first failure
    // bail: false,

    // Respect "browser" field in package.json when resolving modules
    // browser: false,

    // The directory where Jest should store its cached dependency information
    // cacheDirectory: "C:\\Users\\VenD\\AppData\\Local\\Temp\\jest",

    // Automatically clear mock calls and instances between every test
    clearMocks: true,

    // Indicates whether the coverage information should be collected while executing the test
    // collectCoverage: false,

    // An array of glob patterns indicating a set of files for which coverage information should be collected
    collectCoverageFrom: ['src/tests/*.test.js'],

    // The directory where Jest should output its coverage files
    coverageDirectory: 'src/tests/coverage',

    // An array of regexp pattern strings used to skip coverage collection
    coveragePathIgnorePatterns: [
      "\\\\node_modules\\\\"
    ],

    // A list of reporter names that Jest uses when writing coverage reports
    coverageReporters: [
      "json",
      "text",
      "lcov",
      "clover"
    ],

    // An object that configures minimum threshold enforcement for coverage results
    coverageThreshold: {
        "global": {
            "branches": 80,
            "functions": 80,
            "lines": 80
        }
    },

    // Make calling deprecated APIs throw helpful error messages
    errorOnDeprecated: false,

    // Force coverage collection from ignored files using an array of glob patterns
    // forceCoverageMatch: [],

    // A path to a module which exports an async function that is triggered once before all test suites
    // globalSetup: null,

    // A path to a module which exports an async function that is triggered once after all test suites
    // globalTeardown: null,

    // A set of global variables that need to be available in all test environments
    // globals: {},

    // An array of directory names to be searched recursively up from the requiring module's location
    // moduleDirectories: [
    //   "node_modules"
    // ],

    // An array of file extensions your modules use
    moduleFileExtensions: ['js', 'json', 'jsx'],

    // A map from regular expressions to module names that allow to stub out resources with a single module
    // moduleNameMapper: {},

    // An array of regexp pattern strings, matched against all module paths before considered 'visible' to the module loader
    // modulePathIgnorePatterns: [],

    // Activates notifications for test results
    // notify: false,

    // An enum that specifies notification mode. Requires { notify: true }
    // notifyMode: "always",

    // A preset that is used as a base for Jest's configuration
    // preset: null,

    // Run tests from one or more projects
    // projects: null,

    // Use this configuration option to add custom reporters to Jest
    // reporters: undefined,

    // Automatically reset mock state between every test
    resetMocks: false,

    // Reset the module registry before running each individual test
    // resetModules: false,

    // A path to a custom resolver
    // resolver: null,

    // Automatically restore mock state between every test
    restoreMocks: true,

    // The root directory that Jest should scan for tests and modules within
    // rootDir: null,

    // A list of paths to directories that Jest should use to search for files in
    // roots: [
    //   "<rootDir>"
    // ],

    // Allows you to use a custom runner instead of Jest's default test runner
    // runner: "jest-runner",

    // The paths to modules that run some code to configure or set up the testing environment before each test
    // setupFiles: ['<rootDir>/enzyme.config.js'],

    // The path to a module that runs some code to configure or set up the testing framework before each test
    // setupTestFrameworkScriptFile: '',

    // A list of paths to snapshot serializer modules Jest should use for snapshot testing
    // snapshotSerializers: [],

    // The test environment that will be used for testing
    testEnvironment: 'jsdom',

    // Options that will be passed to the testEnvironment
    // testEnvironmentOptions: {},

    // Adds a location field to test results
    // testLocationInResults: false,

    // The glob patterns Jest uses to detect test files
    testMatch: ['**/__tests__/**/*.js?(x)', '**/?(*.)+(spec|test).js?(x)'],

    // An array of regexp pattern strings that are matched against all test paths, matched tests are skipped
    testPathIgnorePatterns: ['\\\\node_modules\\\\'],

    // The regexp pattern Jest uses to detect test files
    // testRegex: "",

    // This option allows the use of a custom results processor
    // testResultsProcessor: null,

    // This option allows use of a custom test runner
    // testRunner: "jasmine2",

    // This option sets the URL for the jsdom environment. It is reflected in properties such as location.href
    testURL: 'http://localhost:3030',

    // Setting this value to "fake" allows the use of fake timers for functions such as "setTimeout"
    // timers: "real",

    // A map from regular expressions to paths to transformers
    // transform: {},

    // An array of regexp pattern strings that are matched against all source file paths, matched files will skip transformation
    transformIgnorePatterns: ['<rootDir>/node_modules/'],

    // An array of regexp pattern strings that are matched against all modules before the module loader will automatically return a mock for them
    // unmockedModulePathPatterns: undefined,

    // Indicates whether each individual test should be reported during the run
    verbose: false,

    // An array of regexp patterns that are matched against all source file paths before re-running tests in watch mode
    // watchPathIgnorePatterns: [],

    // Whether to use watchman for file crawling
    watchman: true,
};

According to our configuration, our tests should live inside a directory called tests inside /src. Let's go ahead and create that --- and while we're on the subject of creating directories, lets create three in total that will allow us to set ourselves up for future steps of the guide

tests - directory that will contain our tests
core/js - we will place our functional JS files here, the likes of helper, utils, services, etc.
core/scss - this will contain browser resets, global variable declarations. We will add these in a future piece.

Alright, we are making progress !! Now that we have a sweet test setup, let's create a simple JS module called multiply.js inside core/js

const multiply = (a, b) => {
    return a* b;
};

export default multiply;

... and write tests for it, by creating a file called multiply.spec.js inside tests directory.

import multiply from '../core/js/multiply';

describe('The Multiply module test suite', () => {
    it('is a public function', () => {
        expect(multiply).toBeDefined();
    });

    it('should correctly multiply two numbers', () => {
        const expected = 6;
        const actual1 = multiply(2, 3);
        const actual2 = multiply(1, 6);

        expect(actual1).toEqual(expected);
        expect(actual2).toEqual(expected);
    });

    it('should not multiply incorrectly', () => {
        const notExpected = 10;
        const actual = multiply(3, 5);

        expect(notExpected).not.toEqual(actual);
    });
});

The final piece of configuration is to add a script in our package.json that will run all our tests. It will live inside the scripts property

"scripts": {
    "test": "jest",
    "build": "webpack --config webpack.production.js",
    "start": "webpack-dev-server --open --config webpack.development.js"
  },

Now, if we run npm run test in our terminal (inside the root directory of the project), it will run all our tests and produce and output like this.

You can keep adding more modules and test suites in similar manner.

Let's move on to the next step !

Step 3

It's time to install Enzyme and test our React components! We need to install a version of Enzyme that corresponds to the version of React we're using, which is 16. In order to do that, we need to do the following, keeping in mind that this tool will also be installed as a dev dependency because like Jest, the test framework does not need to be compiled to production bundle

npm install enzyme enzyme-adapter-react-16 --save dev

Next, we will create enzyme.config.js at the root directory of the project, similar to what we did for Jest. This is what that file should look like

import { configure } from 'enzyme';
import Adapter from 'enzyme-adapter-react-16';

configure({ adapter: new Adapter() });

Now, if you go take a look at line 119 in jest.config.js, you will see that we have done ourselves a favor by preparing for this moment where we setup Enzyme to work with Jest. All that needs to be done is uncomment line 119 and our setup will be complete!

Let's write a test for the <App /> component to see if what we've set up is working. Create a directory called components inside tests --- this will hold all the tests for the components you will write in the future. The separate directory is created to keep functional and component tests separate. This segregation can be done in any way, as long as all the tests live inside the src/tests directory. It will help in the future when the app starts to grow.

Inside src/tests/components directory, create a file called App.spec.js and add the following lines

import React from 'react';
import { shallow} from 'enzyme';

import App from '../../components/App';

describe('The App component test suite', () => {
    it('should render component', () => {
        expect(shallow(<App />).contains(<div>Hello World</div>)).toBe(true);
    });
});

Now if we run our test script in the terminal, you will see this test is running and passing !

Please note: In step 2 and 3, we have simply set up Jest and Enzyme to work together in our code base. To demonstrate that the setup is working, we have written two overly simple tests. The art of writing good tests is an entirely different ball game and these tests should not be taken as any form of guide/direction.

Step 4

In this part of the guide, we will configure our code base to lend .scss support. However, before we can learn to run, we need to learn to walk --- that means we will have to get css to load first.

Let's go grab the necessary npm packages

npm install css-loader style-loader --save-dev

npm install node-sass sass-loader --save

In the explanation block below, you can click the names of the tools that appear like this to visit their official documentation.

css-loader is a webpack plugin that interprets and resolves syntax like @import or url() that are used to include .scss files in components.
style-loader is a webpack plugin that injects the compiled css file in the DOM.
node-sass is a Node.js library that binds to a popular stylesheet pre-processor called LibSass . It lets us natively compile .scss files to css in a node environment.
sass-loader is a webpack plugin that will allow us to use Sass in our project.

Now that we have installed the necessary npm packages, we need to tell webpack to make use of them. Inside webpack.common.js, add the following lines in the rules array just below where we're using babel-loader and html-loader

{
    test: /\.s[ac]ss$/i,
    use: [
        // Creates `style` nodes from JS strings
        'style-loader',
        // Translates CSS into CommonJS
        'css-loader',
        // Compiles Sass to CSS
        'sass-loader',
    ]
}

The setup is complete ! Let's write some sass !!

In src/components directory, create a file called App.scss and add the following lines

#app-container {
    letter-spacing: 1px;
    padding-top: 40px;

    & > div {
        display: flex;
        font-size: 25px;
        font-weight: bold;
        justify-content: center;
        margin: 0 auto;
    }
}

The explanation of sass syntax is beyond the scope of this article. This is an excellent resource for beginners to learn more in depth.

Now, save the file and boot up the project by running npm run start. The application should load with the style rules we just wrote.

Step 5

It's time to install ESLint. Similar to what we've been doing so far, we need to install a few npm packages and then add a config file to our code base. This is a tool that is needed purely for development purpose, so we will install it as a dev dependency.

Let's get started !

npm install eslint eslint-config-airbnb-base eslint-plugin-jest --save-dev

eslint-config-airbnb-base is the airbnb style guide we're asking eslint to apply on our project.
eslint-plugin-jest is the eslint plugin for jest test framework.

The airbnb style guide has peer dependencies that needs to be installed as well. You can input

npm info "eslint-config-airbnb@latest" peerDependencies

in your terminal and list them, however, to install, do the following

npx install-peerdeps --dev eslint-config-airbnb

Next, we need to create a file called .eslintrc.json (note the . at the beginning, indicating it's a hidden file)at the root directory of the project, similar to how the other config files (webpack, jest, enzyme, babel) have been added,

... and add these lines

{
    "extends": "airbnb",
    "plugins": ["jest"],
    "env": {
      "browser": true,
      "jest": true
    },
    "rules": {
      "arrow-body-style": [2, "always"],
      "react/jsx-filename-extension": [1, { "extensions": [".js", ".jsx"] }],
      "no-unused-expressions": "off",
      "max-len": "off",
      "import/no-extraneous-dependencies": "off",
      "react/destructuring-assignment": "off",
      "react/prop-types": "off"
    }
}

The official documentation is a good read if you're looking to understand in details how configuring ESLint works. The most pertinent lines of code in that file is the rules object --- here we're basically overriding some of the rules from the style guide to suit the specific needs of our project. These are not set in stone, so please feel free to play with them to best suit your needs, but it's probably not a good idea to override too many of the rules --- that defeats the purpose of using a style guide in the first place.

Let's add a script to package.json that will apply the airbnb style guide to our code base. We need to tell Eslint what files and/or directories we would like it to scan --- so we will tell it to scan all JS files

"lint": "eslint '**/*.js' --ignore-pattern node_modules"

Now, if you run npm run lint in your terminal, eslint will scan the file types and patterns specified in the script and display a list of issues. Fair warning, the project will have quite a few errors, but if you're using popular code editors like IDEA products, Visual Studio Code, Sublime, etc, they provide out of the box support to fix most of these issues in one quick stroke (format document).

*If the large number of errors is proving to be a hindrance to your learning, please feel free to uninstall ESLint by running npm uninstall eslint eslint-config-airbnb-base eslint-plugin-jest --save-dev *

Step 6

We're almost done with setting up our project --- the finish line is within our sights !! In this last step, we will configure our project to make use of various static assets like images, SVGs, icons and custom typefaces.

Custom Typefaces

Any respectable front end setup should have varying fonts displaying information on the page. The weight of the font, along with its size, is an indicator of the context of the text being displayed --- for instance, page or section headers tend to be larger and bolder, while helper texts are often smaller, lighter and may even be in italics.

There are multiple ways of pulling in custom fonts into an application. Large enterprise code bases usually buy licenses to fonts and have its static assets as part of the the server that hosts the application. The process to do that is slightly complicated --- we need a dedicated piece to walk through that.

The most convenient way of using custom fonts is to use a public domain library that has a large collection and hosted on a CDN (Content Delivery Network), like Google Fonts. It is convenient because all we need to do is, select a couple of fonts we like and then simply embed their url in our static markup index.html

...and we're good to go !! So let's get started. For our purposes, we shall use Roboto Mono font family.

Open up index.html and paste the following stylesheet link in the head

<link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Roboto+Mono">

We're done. Now we can use font-family: 'Roboto Mono' in any of our .scss files. We can use any number of fonts in this way.

Images

Images, like fonts, are an essential part of a front end setup. In order to enable our project to utilize images in the application, we need to install a loader for webpack. This step is identical to what we've done multiple times in this guide --- install the loader and add a few lines to webpack config to make use of it

npm install url-loader --save-dev

... then add the following lines to the rules array in webpack.common.js

...
{
  test: /\.(jpg|png)$/,
  use: {
    loader: 'url-loader',
  },
},
...

The project is now ready to use images of type .jpg and .png . To demonstrate, create a public/images folder at the root directory of the project. Then add any image to the subdirectory images. For our purposes, I downloaded a free image from Unsplash and named it coffee.png

Next, we will create a directory inside src/components called Image --- then create the Image component.

Image.js

import React from 'react';

const Image = (props) => {
  return (
    <img
      src={props.src}
      alt={props.alt}
      height={props.height}
      wdth={props.wdth}
    />
  );
};

export default Image;

Then, import both the Image component and the actual image coffee.png in App.js. At this point, we will have to make minor edits to the App.js to use the image

import React from 'react';
import './App.scss';

// component imports
import Image from './Image/Image';

// other imports
import coffee from '../../public/images/coffee.png';

const App = () => {
  return (
    <div>
      <span>Hello World</span>
      <Image
        src={coffee}
        alt="hero"
        height="400"
        width="400"
      />
    </div>
  );
};

export default App;

Now, if you start the application, you will see the image is being loaded on the page.

Conclusion

That concludes our step by step guide to setting up a modern React project from scratch. There was a lot of information to digest here, but to think of it, we have also come a long way from the minimal setup we did earlier. I hope the guide has been helpful in learning some key concepts in the area of modern front end setup tooling.

The future pieces I have planned for this series are

Learn the basics of containerization and how to deploy this project in a container.
Add bonus features to our project, like JS docs, comprehensive test runner outputs (with colors and coverage percentages !), more package.json scripts and global scss stylesheets like resets and variables.

Please feel free to leave a comment and share among your friends. I will see you in the next piece !

The repo for the advanced setup can be found here .

References

Beginners Guide to Minimal React + Webpack 4 + Babel 7 Project Setup

Nasidul Islam — Fri, 13 Mar 2020 15:48:15 +0000

React has become the leading frontend library of choice among developers in recent years. The best way to learn and practice any programming language tool is to build stuff with it --- in order to so we need to setup a coding playground. The fastest way to get started with such a project is to bootstrap it with create-react-app (CRA) . The reason why such a thing exists is because modern Javascript tooling has become an incredibly vast space (hilariously explained here ). Starter kits such as CRA helps us avoid navigating that landscape and focus on coding the fun stuff. However, it is still essential as developers to know what are some of the key pieces of configuring a project. We will learn just that in this step-by-step guide for a minimal React project setup.

We will learn the following in this tutorial:

basic concepts of Webpack and leverage that to setup our project
what is Babel, what does it do and why do we need it
how to integrate React into our project
how to enable hot module reload

Let's get started by learning the basics of the tools we will use today to configure our first project.

React JS

React is a javascript library that has brought about a paradigm shift when it comes to building user interfaces. Developed and maintained by Facebook, it views the world through the lens of small, reusable components. Imagine a Lego set, where we put together blocks to create a structure. Similarly, React components don't mean a whole lot on their own, but when assembled in a systematic way through the hands of an experienced developer, it can become a powerful tool to build beautiful and complex user experiences.

Key Features

Simple, reusable components
Declarative. Code is more readable and easier to debug.
One way data binding. Data strictly flows from parent component to children component(s)
Virtual DOM. Algorithms calculate the "diff" between current and updated DOM (through user interaction, data received from API calls, etc) to only re-render portions of the view that needs to be updated.
Performance

Webpack

The official site for Webpack describes itself to be a static module bundler --- but I believe it is selling itself short. Yes, it is that in the simplest sense, but it can do so much more. Webpack is an incredibly configurable tool that packages all the front end code (js, css, templating engines, static assets) and creates bundles that the browser can download to give your application functionality.

Key Features

Module bundler. Packages front end code into bundles for browser to download.
Code splitting. The bundles can be broken down further based on the page, functionality etc, so that the browser downloads as less code as possible to run the application.
Tree shaking. If configured to do so, it will not package dead/unreachable code in the bundle.
Loaders and plugins. Allows us to extend on the out of the box functionality provided by Webpack.
Hot Module Replacement (HMR). During development, Webpack can swap out JS or CSS modules on the fly to update the UI without refreshing the page.
Environment specific configurations. For instance, we don't want to minify code in development environment but we absolutely want to do so in production.

Babel

Babel is a javascript transpiler --- it compiles modern JS code into older versions so that older browsers can execute them. The latest versions of most browsers can parse through newer JS features, but legacy browsers can't. We don't want our application to fail to run on those browsers, and that is where Babel saves the day.

Key Features

Compiles modern JS code into older versions of JS that older browsers can execute.
Allows plugins presets to extend on top of its out of the box functionality.

Alright, now that we've learned the core concepts of the tools we're about to use, let's write some code!

Please note: It's worth mentioning here that the node version in your machine must be 10.15.3 or higher. Check by typing node -v in your terminal. If you need an update, or don't have node installed at all, you can get the installer here

Step 1:

Open up your terminal and navigate to a directory where you would like to create your repository.

cd ~/Desktop/projects
mkdir minimal-react-webpack-babel && cd $_
mkdir -p src

This will create a directory named "minimal-react-webpack-babel" where our code will live and a "src" subdirectory inside it.

Step 2:

We need to initialize package.json at this point

npm init -y

This will create the file in one go, with most fields being empty (like description and author) and other set to default (like version set to 1.0.0). You can come back later to fill them out appropriately.

The package.json should look like this now

{
  "name": "minimal-react-webpack-babel",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC"
}

Step 3:

Let's install webpack and webpack-cli in our project.

npm install webpack webpack-cli --save-dev

Pre v4.0.0 of Webpack used to look for a configuration file to run, but since version 4.0.0, Webpack is able to bundle packages out of the box.

In a later tutorial, I plan to demonstrate a more advanced setup for Webpack (environment specific configs, linters, test runners, etc) that will build on top of what we're learning today. We will leave it in its bare bones state for now.

Step 4:

Time to install react and react-dom.

npm install react react-dom

React should be installed as a regular dependency and not as devDependencies because we need react available at application runtime and packaged into the production bundle of the application.

Alright, that was quick and easy! Let's move on.

Step 5:

We have to install Babel here, along with other necessary presets.

npm install @babel/core babel-loader @babel/preset-env @babel/preset-react --save-dev

Explanation: React is written using modern ES6 features that older browsers cannot execute. Therefore, we need to somehow convert the modern syntax into ES5. Webpack cannot perform this action --- this is where Babel steps in to bridge the gap. This process is called transpiling.

We installed three dependencies using the command above:

babel/core babel-loader : the interface between babel and webpack. It allows them to work with each other to produce the final bundle.
babel/preset-env: a preset responsible for transpiling ES6 (or above) to ES5.
babel/preset-react: a present responsible for compiling JSX to regular JS. It is possible to forego installing this dependency, but then we will not be able to write our React components using JSX.

Great, now that we understand that, let's configure babel to use the presets we just installed. First, we will need to create a file called .babelrc at the root of the project --- this will contain the config rules.

touch .babelrc

This is going to be a hidden file. Open up the file using:

open -e .babelrc

... and add the following lines and hit save:

{
  "presets": ["@babel/preset-env", "@babel/preset-react"]
}

Step 6:

Let's install a dev-server now. Technically, it is possible move forward without the dev-server, but that would mean we will have to build our project every time we make code changes to it. That is not the world we want to live in --- we want our application to update as soon as we save our code changes. This process is called Hot Module Replacement. In addition to installing the dev-server, slight tweak to the webpack config will enable this feature for us.

npm install webpack-dev-server --save-dev

Now, in order to have webpack build our code, we will need to add a script inside the scripts property of package.json. This will compile our code in production mode.

We will also add a start script that will spin up our dev server and enable seamless development environment.

  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "build": "webpack --mode production",
    "start": "webpack-dev-server --open --mode development"
  },

Step 7:

The last dependencies we need to install in our project are html-webpack-plugin and html-loader.

npm install html-webpack-plugin html-loader --save-dev

html-webpack-plugin will generate the HTML from the React components we're about to write.
html-loader exports the HTML as string and can minimize it if we ask it to.

Step 8:

We're done with installing dependencies!! What we need to do now is create an HTML file where React will mount our application. Let's call it index.html and put it inside the src directory we created earlier.

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="utf-8">
    <title>Minimal React + Webpack 4 + Babel 7 project setup</title>
</head>
<body>
<div id="app-container"></div>
</body>
</html>

Step 9:

At this point in time, we will add minimal config rules to webpack. We will do so by creating a file called webpack.config.js and put all our rules there. In a future tutorial, we will build on top of what we are learning today and create separate config files for development and production environments. This will allow us to segregate environment specific rules, promoting scalability and maintainability.

Let's create that file at project root

touch webpack.config.js

... and add the following lines to it:

const HtmlWebPackPlugin = require("html-webpack-plugin");

module.exports = {
    devServer: {
        contentBase: './dist',
        hot: true
    },
    module: {
        rules: [
            {
                test: /\.(js|jsx)$/,
                exclude: /node_modules/,
                use: {
                    loader: "babel-loader"
                }
            },
            {
                test: /\.html$/,
                use: [
                    {
                        loader: "html-loader"
                    }
                ]
            }
        ]
    },
    plugins: [
        new HtmlWebPackPlugin({
            template: "./src/index.html",
            filename: "./index.html"
        })
    ]
};

Explanation: These lines are telling webpack to do the following:

devServer contains config rules for the server instance we will run to host our application using dev-server. hot: true enables hot module replacement.
pipe all files with an extension of .js or .jsx through babel-loader, with the exception of files inside node_modules directory.
use the html plugin and loader we installed in the previous step to generate HTML from React components and the front end packaged code bundle and inject the bundle in a <script/> tag in the HTML.

Step 10:

We've reached the end of our setup process -- we're now ready to write some React !!

Let's create a components directory inside src, and write a simple App.js component that prints "Hello World".

import React from 'react';
import ReactDOM from 'react-dom';

const App = () => {
    return (
        <div>Hello World</div>
    )
};

export default App;

We also need to create index.js inside src directory --- and import the component we just wrote.

import React from 'react';
import ReactDOM from "react-dom";
import App from './components/App.js';

const $container = document.getElementById("app-container");
$container ? ReactDOM.render(<App />, $container) : false;

The process is complete --- we've a React project using babel and webpack all on our own!! Now, if we run npm run start, webpack will spin up the dev server and open up our application in a browser window. Additionally, since we've enabled hot module replacement, if we make code changes to our application (edit existing "hello world" component, add new components, etc), we will immediately see our application update in the browser!

The finished repo is here.

Conclusion

There is little doubt that create-react-app is the quickest and most convenient way to setup a react project (at the moment). However, it is an incredibly valuable skill to know how modern javascript tooling works --- and how we can piece these tools together to setup a front end project from scratch.

I hope this step by step guide has helped you understand some of that. Thank you for reading and stay tuned for more !!

DEV Community: Nasidul Islam

Javascript Event Handling - Deep Dive

Table of Contents

Introduction

Overview

Deep Dive

Handling events in React

Let's dive deep and break each of them down:

Handling events in Vue

Handling events in Angular (4.x and above)

Handling events in Svelte

Handling events in jQuery

Resources

Advanced React + Webpack 4 + Babel 7 Application Setup

Environment configuration

Test Frameworks

Sass

ESLint

Static Assets

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Custom Typefaces

Images

Conclusion

References

Beginners Guide to Minimal React + Webpack 4 + Babel 7 Project Setup

We will learn the following in this tutorial:

React JS

Key Features

Webpack

Key Features

Babel

Key Features

Step 1:

Step 2:

Step 3:

Step 4:

Step 5:

Step 6:

Step 7:

Step 8:

Step 9:

Step 10:

Conclusion