DEV Community: Michael McShinsky

Simplifying Blockchain Communication with @hyperbitjs/rpc

Michael McShinsky — Mon, 27 Feb 2023 13:03:10 +0000

If you're looking for a way to interact with a remote blockchain node, @hyperbitjs/rpc is a straightforward package that can help. This package provides a convenient way to send requests to a blockchain node and handle the responses in your application.

One of the main benefits of using @hyperbitjs/rpc is that it's compatible with any blockchain that supports the JSON-RPC API. This means that you can use the same library to interact with different blockchains without having to learn new tools or languages.

Getting Started

To get started with @hyperbitjs/rpc, you will need to have a blockchain node set up and running. Additionally, you will need to enable the JSON-RPC API in your node's configuration file. Once you have your node set up and running, you can use @hyperbitjs/rpc to send requests to it. If you are unsure how to get a blockchain node setup with the JSON-RPC API enabled, take a look at this tutorial: How to setup an RPC API for a Blockchain Node

You’ll also want to make sure you have Node.js installed on your computer with your choice of IDE. Visual Studio Code is a great choice, but you can use any terminal or IDE to get started with your project.

Installation

Let's get started by installing @hyperbitjs/rpc into your current project.

Open your terminal or command prompt and navigate to your project directory.
Type the following command to install @hyperbitjs/rpc and save it as a dependency in your project:

npm install @hyperbitjs/rpc

This command will download and install the latest version of @hyperbitjs/rpc and add it to your package.json file.

Once the installation is complete, you can import the library into your project using the following code:

// CommonJS
const { Client } = require('@hyperbitjs/rpc');

// ES6
import { Client } from '@hyperbitjs/rpc';

This will give you access to the Client object, which contains all the methods you need to interact with a blockchain node. Let's use the Client to connect to our blockchain node and send commands.

const client = new Client({
  url: '<host:port>', // http://127.0.0.1:9050
  username: '<username>',
  password: '<password>',
});

Once we have our client setup, we will be able to make requests to our blockchain node using the request method and passing in two arguments.

The first is our RPC command which you can find in the documentation for any given blockchain.
The second is an array of options a given RPC command requires to return data based on your request.

Example 1: Get Blockchain Info

client.request('getblockchaininfo', []).then(response  => {
    console.log('response', response);
});
// Expected response: { chain: ..., blocks: ..., headers: ..., etc: ...}

Example 2: Get Block Hash

The getblockhash method returns the hash of a specific block in a blockchain. We're going to use the Bitcoin blockchain in this example and show using the client with additional arguments.

client.request('getblockhash', [778174]).then(response  => {
    console.log('response', response);
});
// Expected response: 00000000000000000003b80c61f014682e4cddc5cde562f9b358b542097c636b

You will notice that the second argument is passed as an array. Most RPC requests handle the payload in this configuration, although there are some exceptions to the rule. That's okay since @hyperbitjs/rpc is flexible enough to allow you to send any type (array, object, string) through as the second parameter so long as the API you are using accepts it.

Conclusion

Overall, @hyperbitjs/rpc is a powerful and flexible tool that can help you connect with any blockchain node that supports the JSON-RPC API. Whether you're building a decentralized application, analyzing blockchain data, or developing a new blockchain protocol, @hyperbitjs/rpc can help you communicate with the blockchain nodes you need to access.

We hope that this tutorial has been informative and helpful for you. If you have any questions or feedback about this article, please feel free to leave a comment below. We always appreciate hearing from our readers and are happy to help with any issues or concerns you may have.

Thanks again for reading, and happy coding!

If you found this helpful or useful, please share a 💓, 🦄, or 🔖. Thanks!

How to setup an RPC API for a Blockchain Node

Michael McShinsky — Wed, 22 Feb 2023 23:10:30 +0000

RPC (Remote Procedure Call) is a protocol that allows a program to execute code on a remote server. Many blockchain nodes include an RPC interface that allows you to interact with your node programmatically. In this tutorial, using Bitcoin, we will walk through the steps required to setup and interact with an RPC interface for your node.

Prerequisites:

Before we get started, you'll need to have a Bitcoin node installed on your computer or server. You should also have a basic understanding of how to use the command line. If you're not familiar with the command line, you may want to do some additional research before proceeding.

Step 1: Install Bitcoin Core

The first step is to download and install Bitcoin Core on your computer. You can download Bitcoin Core from the official website (https://bitcoincore.org/en/download/). Once you've downloaded the software, follow the installation instructions for your operating system.

Note: It can take a variable amount of time (hours or days) to sync your node to the blockchain network before you can use all the methods the RPC interface provides.

It is recommended to use the testnet environment for experimenting with the blockchain in development before creating a production node for real world use. If you need Bitcoin to test transactions with, you can make use of this or similar faucets: https://kuttler.eu/en/bitcoin/btc/faucet/.

Step 2: Configure Bitcoin Core

Once you've installed Bitcoin Core, you need to configure it to enable the RPC interface. To do this, you'll need to create a bitcoin.conf file in the Bitcoin data directory.

On Linux/MacOS, you can create the file by running the following command:

nano ~/.bitcoin/bitcoin.conf

On Windows, you can create the file by navigating to the Bitcoin data directory (usually located in %APPDATA%\Bitcoin) and creating a new file called bitcoin.conf.

Step 3: Configure the RPC interface

In the bitcoin.conf file, add the following lines to enable the RPC interface:

server=1
rpcuser=<username>
rpcpassword=<password>
rpcallowip=<IP address or subnet>

Replace and with your own username and password, respectively. These will be used to authenticate the RPC connection.

If you want to use testnet instead of a production node, you can add the following line:

testnet=1

Replace with the IP address or subnet that you want to allow to access the RPC interface. You can specify a single IP address or a subnet in CIDR notation (e.g. 192.168.0.0/16). This is more important when you want to access the RPC interface between a client and server. If you are doing this locally, you may be able to skip this step or set it to:

rpcallowip=127.0.0.1
rpcport=8332

Step 4: Test the RPC interface

Now that the RPC interface is set up, you can use it to interact with your Bitcoin node programmatically. You will need to restart Bitcoin Core for the changes you have made to take effect. Once restarted, you can test it by running the following command in the terminal:

bitcoin-cli getblockcount

If you run into issues using bitcoin-cli in the terminal, see the documentation here, or you can run a curl command as follows:

curl --user <username>:<password> --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getblockcount", "params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/

If everything is set up correctly, you should see the current block count of your Bitcoin node.

Conclusion:

That's it! You now have an RPC interface set up for your Bitcoin node. You can use the RPC interface to interact with your node programmatically and build Bitcoin applications.

For a full RPC API reference, see: RPC API Reference — Bitcoin

You can use a generator like Bitcoin Core Config Generator to create a bitcoin.conf for yourself.

If you found this helpful or useful, please share a 💓, 🦄, or 🔖. Thanks!

Migrate from AngularJS to React

Michael McShinsky — Mon, 17 Jan 2022 11:55:44 +0000

The Angular team recently announced the end of long-term support for AngularJS. Long term support (LTS) was originally planned for July of 2021, but was delayed to December 31, 2021 due to the effects of COVID-19. You can see their announcement in their blog post both discontinuing LTS and providing a transitionary path to later Angular versions for those whose teams and develop plans focus completely on the Angular ecosystem.

If you have been part of teams like mine whose expertise lies in React but are tasked with developing and maintaining an AngularJS, this post is for you. Together we’ll go over migratory steps to transition your code base from AngularJS to React.

The migration of your code base isn’t necessarily a hard one but may take time and dedication depending on the size and complexity of your current solution. Generally speaking, there are three main approaches you can take to transition away from AngularJS. These are:

Single-SPA
Iframes
Micro Apps

Single-SPA

This library takes reconfiguring your current solution to load in multiple apps as front-end microservices. I’m not terribly familiar with the solution as the implementation to do so with an AngularJS app proved to be too tedious at the time of migration. Most examples given are when starting apps from scratch. If there are those that can speak to a legacy migration solution, please let me know your insights in the comments below.

Iframes

Iframes apps are standalone apps that we want to run in conjunction to the parent app as sub-features, or child apps, throughout the parent app. This requires creating a new app with its’ own repository, pipeline, deployment strategies, testing environments, and domains where the app will reside. It also requires server and client-side security protocols if you only want the iframe to be accessible from the parent app.

This can be a great way to move off of legacy code and constraints while enabling your engineering team to use modern technologies and standards without having to worry about conflicts with your parent app. This can also allow you to move into a new CSS framework without conflicting styles between the parent and child apps. In order to merge the two apps together, you’ll need to:

Parent app creating iframes for child apps into a given page, feature, etc…
Create communication functions for the apps to send data back and forth if this is desired.
- Auth tokens are a good example of cross communication functionality where you don’t want your users to have to log in a second time in order to use your child app.
Create shared utility and component libraries that standardize the usage and experience between all parent and child apps. This can be done through public or privately published NPM packages.
Implement a $location.path wrapper to share routing between the two frameworks.

Eventually if architected with replacement in mind, you could replace the legacy app with your iframe app completely once every view and component has been transferred.

Micro Apps

This solution allows you to continue with a monolithic build but restricts you from implementing modern build techniques if your current app is too complex to rewrite every portion of the app at once without creating more tech debt and unexpected failures (e.g., Moving from Webpack 3 to Webpack 5). My favorite tool for this approach is react2angular, an NPM package that embeds React apps in your AngularJS project without getting in the way of the main app maintenance or feature development.

This tool allows you to send your AngularJS services and any prop you define to your React app without having to rewrite the AngularJS components. Your React app consumes incoming services and data as props and your team is already productive from the start with little overhead. As a result of AngularJS rending React micro apps throughout your parent app, React doesn’t have the convenience of the apps sharing a single global state management solution like Redux or Context. This can slowly change as you migrate and merge more and more of the app components into your new React codebase. Another advantage in using react2angular is creating wrap smaller React components in an Angular component by name only in order to mass replace a particular feature as you are making the transition over time.

A few things to consider with this approach.

Although the package itself hasn’t been updated in a few years, it still works as intended with modern versions of React.
This package works best with AngularJS v1.5 and up. If you are on v1.2, you may have some work to do to get your AngularJS version up to 1.5.
This shouldn’t be your final solution since AngularJS support is now discontinued and you should aim to eventually completely remove your AngularJS codebase in favor of the React replacement.
Implement a $location.path wrapper to share routing between the two frameworks.

Solution

If you are looking at only new feature development, the Iframe approach may be good for you. If you want to replace current functionality of a legacy app, the Micro App approach may be the approach to best transition your app. Personally, I favor the two of them in unison. By doing so you can transition older features to a newer codebase while developing newer features in a new iframe codebase. Eventually, you can even move the react2angular Micro app code straight into the iframe app if you stay strict to both using the same shared libraries and utilities.

Possible migration flow:

Install react2angular and start testing small feature transitions.
Begin moving the service layer into a shared public/private NPM package.
Being replacing AngularJS npm packages with their React equivalent if needed.
Create child React app that will replace parent app.
- Create parent and child communication functions.
  - Send parent auth tokens to child app.
- Create server security rules for where and which child apps can exist as an iframe.
- Setup child routing to match parent routing.
  - As features are iframed into the parent, both routes will match for later full transition.
Setup $location.path wrapper to sync AngularJS and React routing for both Micro Apps and Iframe.
Depending on flow, move react2angular components to iframe app.
Once AngularJS views and components are replaced, replace for final transition:
- Routing
  - Root files (e.g., index.js, index.html, etc…)
- Update Webpack settings to React based build
- Replace all middleware services (e.g., restangular with axios.)
- OR replace parent app with Iframe app.
Congratulations, your AngularJS app is gone!

There may be more or less steps depending on the complexity of your current solution and you should cater your migration strategies as such to what works best for your project or company goals.

In conclusion, as a result of starting or completing this migration, your company should see benefits both in engineering moral and empowerment to implement new technologies and staying up to date with the developer ecosystem. You can rest with peace of mind that security maintenance doesn’t fall on your shoulders without support from the official Angular development teams. As well, migrating your app will also allow you to expand your hiring base as you are no longer stuck hiring candidates in a niche and discontinued framework.

Thanks for the read and I wish you the best of luck on your migration!

Resources

If you found this helpful or useful, please share a 💓, 🦄, or 🔖. Thanks!

Build a Fullstack app with Adonis and React

Michael McShinsky — Wed, 17 Feb 2021 19:07:12 +0000

Inspired by Amir Hosein Samili's post on managing Adonis and Vue as a monorepo, I want to show you how we can replicate this approach with React. As a bonus, we'll add in Tailwind as our CSS framework, but you can choose whatever styling methodology or framework that floats your boat. The goal is to let both our apps live together and allow the server pass the routing and styles down to the client.

Please note we'll be following the same flow as the referenced article, but making some changes and additions to meet our React/Tailwind needs. Please share your thanks and follow there as well!

Create Initial Project

We'll start with creating our Adonis project using the latest version (v5). If you are unfamiliar with Adonis, take some time and look over the docs at preview.adonisjs.com. When running the starting command below, make sure to select "Web Application" since we will be making use of both backend and frontend routing in a single environment. I also say yes to eslint and prettier during the cli instructions and then customize them to my own personal preferences.

yarn create adonis-ts-app <app-name>;

cd <app-name>;

Setup Asset Bundler

With our project compiler ready, we now need to configure the server to be aware of and compile our React assets that we'll be using for the frontend.

yarn add adonis-mix-asset && yarn add -D laravel-mix laravel-mix-tailwind;

The invoke command will setup the providers, commands and webpack.mix.js we need to resolve and build the relationship between our backend and frontend.

node ace invoke adonis-mix-asset;

Since we are having Adonis and React in the same monorepo and will be letting this repo manage our React app through adonis-mix-asset (Laravel Mix), we need to have some extra webpack configurations for hot reloading. As of this article, there is a minor bug that prevents hot refreshing in the browser so you'll need to do a manual refresh when working in the React portion of the codebase. If you happen upon the fix for this, I would love to hear more about it! We're going to add a couple more dependencies that our webpack file will need. As well, since mix is managing our webpack, the file will be called webpack.mix.js.

yarn add -D @babel/preset-react babel-loader @pmmmwh/react-refresh-webpack-plugin react-refresh;

webpack.mix.js

const ReactRefreshWebpackPlugin = require('@pmmmwh/react-refresh-webpack-plugin')
const webpack = require('webpack')
const mix = require('laravel-mix')

require('laravel-mix-tailwind')

const isDevelopment = process.env.NODE_ENV !== 'production'

mix
  .setPublicPath('public')
  .js('resources/client/index.js', 'public/js/')
  .react()
  .sass('resources/assets/scss/index.scss', 'public/css/')
  .tailwind()
  .options({
    processCssUrls: false
  })

if (isDevelopment) {
  mix.sourceMaps()
}

mix.webpackConfig({
  mode: isDevelopment ? 'development' : 'production',
  context: __dirname,
  node: {
    __filename: true,
    __dirname: true,
  },
  module: {
    rules: [
      {
        test: /\.(js|mjs|jsx|ts|tsx)$/,
        exclude: /node_modules/,
        use: [
          {
            loader: require.resolve('babel-loader'),
            options: {
              presets: ['@babel/preset-react'],
              plugins: [isDevelopment && require.resolve('react-refresh/babel')].filter(Boolean),
            },
          },
        ],
      },
    ],
  },
  plugins: [
    isDevelopment && new webpack.HotModuleReplacementPlugin(),
    isDevelopment && new ReactRefreshWebpackPlugin(),
    new webpack.ProvidePlugin({
      React: 'react',
    }),
  ].filter(Boolean),
})

We'll also add additional fields to the .gitignore and let the deployment built handle them.

.gitignore

# other settings...

mix-manifest.json 
hot 
public/js/* 
public/css/*
public/**/*_js*

Configure Tailwind

Let's go ahead and add tailwind configurations to our app.

yarn add -D tailwindcss@npm:@tailwindcss/postcss7-compat @tailwindcss/postcss7-compat postcss@^7 autoprefixer@^9 sass-loader@8.* sass postcss@^8.1;

mkdir -p resources/assets/scss && touch resources/assets/scss/index.scss;

npx tailwindcss init

tailwind.config.js

module.exports = {
  purge: ['./resources/client/**/*.{js,jsx,ts,tsx}', './resources/views/**/*.edge'],
  darkMode: false, // or 'media' or 'class'
  theme: {
    extend: {},
  },
  variants: {
    extend: {},
  },
  plugins: [],
}

resources/assets/scss/index.scss

@import "tailwindcss/base"; 
@import "tailwindcss/components"; 
@import "tailwindcss/utilities";

Create Client React App

Next we'll need to bring in the needed React packages and create our starter React entry files.

yarn add react react-dom;

mkdir -p resources/client && touch resources/client/index.js resources/client/App.js;

resources/client/index.js

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

ReactDOM.render(
  <React.StrictMode>
    <App /> 
  </React.StrictMode>,
  document.getElementById('root')
);

resources/client/App.js

import React from 'react'

export default function App() {
  return (
    <div>
      Hello World!
    </div>
  )
}

Since the server is handling the initial serve of our React app, we'll need to create an edge templating file that React will mount from. We'll do this in the resources/views folder. Our edge file for now will use direct references to our mix files instead of the mix templating syntax {{ mix('scripts/index.js') }} due to deployment issues in Heroku (if that is what you decide to use).

touch resources/views/index.edge;

resources/views/index.edge

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <link rel="stylesheet" href="/css/index.css">
    <title>React App</title>
  </head>
  <body>
    <noscript>You need to enable JavaScript to run this app.</noscript>
    <div id="root"></div>
    <script src="/js/index.js"></script>
  </body>
</html>

Server Routing

Our server is hosting the React app so we now need let our routing know how to handle frontend routing. We'll "start" our route from the server and then from there, the React app will take over all client routing. You can manage client side routing using the popular routing library react-router.

start/routes.ts

import Route from '@ioc:Adonis/Core/Route' 
import { HttpContextContract } from '@ioc:Adonis/Core/HttpContext' 

// Other Routes...

Route.get('*', async ({ view }: HttpContextContract) => { 
  return view.render('app') 
}).as('not_found')

Development & Deployment

I've deployed my app to Heroku so you may find this linked article helpful in setting that up. As a result the package scripts referenced that reflect that flow but you may want or need to change them for deployment to suite your server environment.

yarn add -D concurrently;

package.json

"start": "node build/server.js",
"server": "node ace serve --watch",
"client": "node ace mix:watch",
"build": "yarn client:build && yarn server:build",
"server:build": "node ace build --production",
"client:build": "node ace mix:build --production",
"dev": "concurrently \"yarn server\" \"yarn client\"",

Procfile (For Heroku deployment)

release: node ./build/ace migration:run --force && node ./build/ace db:seed
api: node build/server.js
web: node build/server.js

Minor notes:

dev runs both the server and the client for active development.
start and build are reserved for deployment in my use case

Closing Thoughts

Currently, Adonis combined with React as a monorepo come with a couple minor inconveniences that should be solved either through library fixes or maybe there is something that I didn't notice. Hopefully these minor adjustments are resolved soon, but that that hasn't stopped me from continuing to use this setup in current projects.

Overall, running both your server and your client in the same environment bring some unique advantages that come with monorepos. You keep all the code together and CORS & APIs are easier to manage in regards to security & convenience. Also all stylesheets, tooling, and project wide changes are easy to distribute without having to adding in third party distributable libraries to multiple apps.

On the flip side, if you want or need separate projects for the server and client, this approach probably isn't for you. You'll most likely spin up a separate create-react-app (or custom) and deploy it elsewhere while calling the API endpoints of your Adonis server. There is nothing wrong with either approach. It all comes down to company and development objectives that best align with the future scalability your are looking for.

Here is a link to the github source code for reference.

If you found this helpful or useful, please share a 💓, 🦄, or 🔖. Thanks!

Implementing Soft Delete in AdonisJS v5

Michael McShinsky — Wed, 10 Feb 2021 16:15:39 +0000

If you want to soft delete data in Adonis v5, unfortunately it is not built into the core architecture. If you aren't familiar with the concept of soft deletes, it is the concept that when you delete data from the database, you aren't actually deleting it, but rather setting a flag to indicate that it is in a deleted state. These rows shouldn't return in database queries, but still exist if needed in the future.

Soft deletes bring a few advantages to the table depending on your business requirements.

You may legally be required to keep the data either in the database or in a backup, but you need a transition time for your backup implementation.
Related data depends on the deleted data to exist even if it won't be used by the user or other services anymore.
It can create a "trash can view" for users making data recovery faster and easier.
Creates trackable history for either in-house or customer auditing.

There are a lot of advantages, but know that you are making a decision to keep a lot of data and must understand the implications of doing such in the long run.

Getting Started

The flag we'll be making use of in this tutorial is a column added to the tables we want called deleted_at. This column will help us know which database rows are active vs deleted for future queries and updates. To start off, we should already have an Adonis project created with our choice of database. We'll use MySql as our baseline. We'll also be assuming those two steps for this tutorial are already complete. Once a project and database schema are set up, we'll need to create our first migration.

node ace make:migration posts

This will create a posts migration that we'll use to create and soft delete posts within our database. For soft deletes, we'll use deleted_at with a column type of datetime. This way we can track both the post being soft deleted and when it was soft deleted. Soft deletes can also be accomplished alternatively by using a column is_deleted with a type of boolean and tracking changes generally with the updated_at column.

// <app-name>/database/migrations/012345678987654321_posts.ts

import BaseSchema from '@ioc:Adonis/Lucid/Schema'

export default class Posts extends BaseSchema { 
  protected tableName = 'posts' 

  public async up () {
    this.schema.createTable(this.tableName, (table) => {
      table.increments('id').primary()
      table.string("name", 254).notNullable();
      table.text("description");
      table.dateTime("deleted_at").defaultTo(null);
      table.timestamps(true)
    })
  }

  public async down () {
    this.schema.dropTable(this.tableName)
  }
}

With our migration in place, we can now migrate our database and setup our posts table.

node ace migration:run

Connecting the ORM

We need to create our model to define our column fields for Adonis' ORM. This will be critical to implementing soft deletes on the fly and programmatically within various functions and controllers. Without the model, doing soft deletes would require not only more lines of duplicated code, but more manually labor anywhere and everywhere we need to manage the soft delete paradigm.

The following command will initiate our Post model:

node ace make:model Post

// <app-name>/app/Models/Post.ts

import { DateTime } from 'luxon'
import { column, BaseModel } from '@ioc:Adonis/Lucid/Orm' 

export default class Post extends BaseModel {    
  @column({ isPrimary: true })
  public id: string

  @column()
  public name: string

  @column()
  public body: string 

  @column.dateTime({ serializeAs: null})
  public deletedAt: DateTime

  @column.dateTime({ autoCreate: true })
  public createdAt: DateTime

  @column.dateTime({ autoCreate: true, autoUpdate: true })
  public updatedAt: DateTime
}

Implementing Soft Delete

Since we want soft deletes to happen for any possible number of models, we're going to extract the implementation as an Adonis service. Since Adonis doesn't actively come with an ace command to create a service, we'll manually create our services folder inside the app folder and create a SoftDelete.ts service file.

// <my-app>/app/Services/SoftDelete.ts

import { LucidRow } from '@ioc:Adonis/Lucid/Model'
import { DateTime } from 'luxon';

// Optional null check query
export const softDeleteQuery = (query: ModelQueryBuilderContract<typeof BaseModel>) => {
  query.whereNull('deleted_at')
}

export const softDelete = async (row: LucidRow, column: string = 'deletedAt') => {
  if(row[column]) {
    if(row[column].isLuxonDateTime) {
      // Deleted represented by a datetime 
      row[column] = DateTime.local();
    } else {
      // Deleted represented by a boolean 
      row[column] = true;
    }
    await row.save();
  }
}

The softDelete function is the most important part and is the engine to distributing the soft delete functionality at scale to any number of models. The softDeleteQuery is optional that we'll be adding to our Post model queries next. Both functions need to be updated based on how you implement your soft delete column. Update both functions as needed to check against a column of boolean or datetime as well as update the column name the functions check against. As a reminder, the column name we're using in the examples in this tutorial is deleted_at.

Adding Services to Models

We're going to add the service we just created to the Post model. Adonis comes with hooks built in that allow us to intercept or override the model lifecycle. In our case, we'll be overriding the delete functionality and updating fetch and find to not include rows that have been soft deleted.

Required Imports:

import { beforeFind,  beforeFetch } from '@ioc:Adonis/Lucid/Orm'
import { softDelete, softDeleteQuery } from '../Services/SoftDelete'

Below is a summarized Post model showing the imports and function implementations we have just created.

// Summarized Post.ts

import {
  beforeFind, 
  beforeFetch
} from '@ioc:Adonis/Lucid/Orm'
import { softDelete, softDeleteQuery } from '../Services/SoftDelete';

export default class Post extends BaseModel { 

  // ... Additional model details here

  @beforeFind()
  public static softDeletesFind = softDeleteQuery;

  @beforeFetch()
  public static softDeletesFetch = softDeleteQuery;

  public async softDelete(column?: string) {
    await softDelete(this, column);
  }
}

In the code above you have two choices. You can add in an additional method to the model like we did. This allows us to keep the native delete and also add in a soft delete. The danger here is if you implement soft delete, without proper documentation and code review, a different developer may use the main delete method without knowing that soft delete is the go to method. If this is something you want to avoid, then instead of adding a new method, you can override the delete method by reassignment.

public async delete = softDelete;

Delete All The Things

Let's go ahead and test this new soft delete method. We'll be skipping over route and controller creation and demonstrating controller functions that will call get and delete.

This first example shows a simple delete implementing our soft delete method.

public async delete ({ request, response, auth }: HttpContextContract) {
  try {
    const postId = request.input('id')
    const post = await Post.findOrFail(postId)

    await post.softDelete()

    return response.json({})
  } catch (error) {
    return response.json(error)
  }
}

The next example demonstrates implementing the beforeFetch and the beforeFind hooks. As a result, our queries will return all rows that have not been soft deleted.

public async getAll({ response }: HttpContextContract) {
    try {
      const posts = await Post.all()
      return response.json(posts) 
    } catch (error) {
      return response.json(error)
    }
  }

There you have it! We've not create a soft delete paradigm that can easily be scaled to any model in our system.

Final Thoughts

Implementing soft delete is a power feature that allows you to retain and control all the data in your database. It has both the advantages of data persistence and long term management, but also comes with the warning of data maintenance and exponential growth in the long run. As long as you are aware of all the options and consequences, implementing soft deletes can become a unique and powerful tool as your app or product expands.

If you found this helpful or useful, please share a 💓, 🦄, or 🔖. Thanks!

A Simple Approach to Managing API Calls

Michael McShinsky — Mon, 13 Jul 2020 18:52:52 +0000

In my article, "Architecting Frontend Projects To Scale", we took a look at organizing our frontend code base in a way to make scaling and succeeding as a team much easier. In this article we're going to take a small dive into the services layer of our code organization. Specifically, we will look at a simple solution for managing 3rd party APIs or our own data sources in such a way that will help us avoid some of the frustrations with managing our code base as APIs change over time.

When we first start building out features, most of us tend to dump all feature logic into a single component. The database calls, state management, and all the child components that are managed or display the data which we are presenting to the end user are located here. As a result of doing this, we begin to create a very bloated set of files that consume, manage, and present all the logic as it becomes more complex with the increase in business logic. What may have started out as simple CRUD (Create, Read, Update, Delete) actions will inevitably grow into a multitude of specialized functions and intertwined business logic. If we are not careful in our code architecture design process, we may find ourselves locked into function dependencies that are so messy that we even fear the refactoring process because we do not want to create a single bug that may have us working over the weekend to fix.

Avoiding The Mess

One part of this business logic mess that we can avoid is to not hard code our API calls into our components directly. Our goal is to abstract everything related to API logic into our services layer in order to make our components a little more lean and maintainable. This concept directly aligns itself with Dan Abramov's article "Presentational and Container Components" as well as creating a Model/Service layer in our frontend framework to abstract most business logic away from our reusable components.

Here is a simple example of what you may start out with:

import React, { useEffect } from 'react';
import axios from 'axios';

let API_URL_TASKS = 'https://url.com/api/v1/tasks';

export function Tasks() {
  const [tasks, setTasks] = useState([]);

  useEffect(() => {
    _getTasks();
  }, []);

  function _getTasks() {
    axios
      .get(API_URL_TASKS)
      .then((res) => {
        let arr = _parseTasks(res.results.data);
        setTasks(arr);
      })
      .catch((err) => {
        _handleError(err, type);
      });
  }

  function _parseTasks(tasks) {
    return tasks.map((task) => {
      // Parse task information
      return task;
    });
  }

  function _createTask(task) {
    axios
      .post(url, task)
      .then((res) => {
        _handleSuccess(res, 'post');
        // etc...
      })
      .catch((err) => {
        _handleError(err, 'post');
      });
  }

  function _updateTask(task) {
    let url = `${API_URL_TASKS}/${id}`;
    axios
      .patch(url, task)
      .then((res) => {
        _handleSuccess(res, 'patch');
        // etc...
      })
      .catch((err) => {
        _handleError(err, 'patch');
      });
  }

  function _removeTask(id) {
    let url = `${API_URL_TASKS}/${id}`;
    axios
      .delete(url)
      .then((res) => {
        _handleSuccess(res, 'delete');
        // etc...
      })
      .catch((err) => {
        _handleError(err, 'delete');
      });
  }

  function _handleSuccess(response, type) {
    // success message
    // actions against state with type
  }

  function _handleError(error, type) {
    // error message
    // actions based on type
    // etc...
  }

  return (
    <ul>
      {tasks.map((task) => (
        <li key={task.id}>{task.name}</li>
      ))}
    </ul>
  );
}

As you can see, our component's data flow is directly related and hardcoded to one or many API endpoints that it may require. If you start to do this with many components over time, and your API requirements change from the server or 3rd party API, you have now cornered yourself into the painful process of finding all instances that need to be changed in order to avoid code and interface failure for your end user. Instead, we're going to create a few file structures in our service layer in order to make it easier to maintain changes over time.

my-app 
└── src
    ├── components
    ├── views
    |   └── tasks
    └── services
        ├── api
        |   ├── tasks
        |   └── utilities
        ├── model
        |   └── task
        └── etc...

Service Utilities

In the services folder, we're going to create a few utilities to make our APIs reusable and standardized for all components and team members. We'll be making use of the JavaScript axios library and JavaScript classes in this example to create our API utilities.

services
└── api
    └── utilities
        ├── core.js
        ├── index.js
        ├── provider.js
        └── response.js

We're going to focus on three main files here:

provider.js - Defines how axios or any api library should connect with the database and connect our response data back to any connected file or component.
core.js - Defines the reusable class that makes use of our provider.js with options we can define per api endpoint collection. As a result of being a constructor function, we can extend it's functionality on individual API collections as needed while still keeping a consistent base for the majority of our code.
response.js - Middleware to handle response parsing, error handling, logging, etc...

Provider.js

// provider.js

import axios from 'axios'; 
import { handleResponse, handleError } from './response'; 

// Define your api url from any source.
// Pulling from your .env file when on the server or from localhost when locally
const BASE_URL = 'http://127.0.0.1:3333/api/v1'; 

/** @param {string} resource */ 
const getAll = (resource) => { 
  return axios 
    .get(`${BASE_URL}/${resource}`) 
    .then(handleResponse) 
    .catch(handleError); 
}; 

/** @param {string} resource */ 
/** @param {string} id */ 
const getSingle = (resource, id) => { 
  return axios 
    .get(`${BASE_URL}/${resource}/${id}`) 
    .then(handleResponse) 
    .catch(handleError); 
}; 

/** @param {string} resource */ 
/** @param {object} model */ 
const post = (resource, model) => { 
  return axios 
    .post(`${BASE_URL}/${resource}`, model) 
    .then(handleResponse) 
    .catch(handleError); 
}; 

/** @param {string} resource */ 
/** @param {object} model */ 
const put = (resource, model) => { 
  return axios 
    .put(`${BASE_URL}/${resource}`, model) 
    .then(handleResponse) 
    .catch(handleError); 
}; 

/** @param {string} resource */ 
/** @param {object} model */ 
const patch = (resource, model) => { 
  return axios 
    .patch(`${BASE_URL}/${resource}`, model) 
    .then(handleResponse) 
    .catch(handleError); 
}; 

/** @param {string} resource */ 
/** @param {string} id */ 
const remove = (resource, id) => { 
  return axios 
    .delete(`${BASE_URL}/${resource}`, id) 
    .then(handleResponse) 
    .catch(handleError); 
}; 

export const apiProvider = { 
  getAll, 
  getSingle, 
  post, 
  put, 
  patch, 
  remove, 
};

Core.js

In this constructor class, we can define which base API resources will be consumed. We can also extend the class in each API utility to include custom endpoints unique to the API table(s) without created accidental one-off solutions littered in our code base away from this file.

// core.js

import apiProvider from './provider';

export class ApiCore {
  constructor(options) {
    if (options.getAll) {
      this.getAll = () => {
        return apiProvider.getAll(options.url);
      };
    }

    if (options.getSingle) {
      this.getSingle = (id) => {
        return apiProvider.getSingle(options.url, id);
      };
    }

    if (options.post) {
      this.post = (model) => {
        return apiProvider.post(options.url, model);
      };
    }

    if (options.put) {
      this.put = (model) => {
        return apiProvider.put(options.url, model);
      };
    }

    if (options.patch) {
      this.patch = (model) => {
        return apiProvider.patch(options.url, model);
      };
    }

    if (options.remove) {
      this.remove = (id) => {
        return apiProvider.remove(options.url, id);
      };
    }
  }
}

Response.js

This is kept separate to keep our files lean and allow a clean separation for any response and error logic you may want to handle here for all API calls. Maybe you want to log an error here or create custom actions for authorization based on the response header.

// response.js

export function handleResponse(response) {
  if (response.results) {
    return response.results;
  }

  if (response.data) {
    return response.data;
  }

  return response;
}

export function handleError(error) {
  if (error.data) {
    return error.data;
  }
  return error;
}

Individual APIs

We can now extend our base api class to make use of all the api configurations that will be used for any api collection.

// Task API

const url = 'tasks';
const plural = 'tasks';
const single = 'task';

// plural and single may be used for message logic if needed in the ApiCore class.

const apiTasks = new ApiCore({
  getAll: true,
  getSingle: true,
  post: true,
  put: false,
  patch: true,
  delete: false,
  url: url,
  plural: plural,
  single: single
});

apiTasks.massUpdate = () => {
  // Add custom api call logic here
}

export apiTasks;

Implementing Our Changes

Now that we have our setup complete, we can import and integrate our api calls into multiple components as needed. Here is an updated Task component with our changes.

import React, { useEffect } from 'react';

import { apiTasks } from '@/services/api';

export function Tasks() {
  const [tasks, setTasks] = useState([]);

  useEffect(() => {
    _getTasks();
  }, []);

  function _getTasks() {
    apiTasks.getAll().then((res) => {
      let arr = _parseTasks(res.results.data);
      setTasks(arr);
    });
  }

  function _parseTasks(tasks) {
    return tasks.map((task) => {
      // Parse task information
      return task;
    });
  }

  function _createTask(task) {
    apiTasks.post(task).then((res) => {
      // state logic
    });
  }

  function _updateTask(task) {
    apiTasks.patch(task).then((res) => {
      // state logic
    });
  }

  function _removeTask(id) {
    apiTasks.remove(id).then((res) => {
      // state logic
    });
  }

  return (
    <ul>
      {tasks.map((task) => (
        <li key={task.id}>{task.name}</li>
      ))}
    </ul>
  );
}

Conclusion

With a little extraction of code into reusable service utilities, our app can now manage API changes much easier. A failed API call can now be addressed in one location, it's implementation can easily tracking, and our component dependencies can be quickly updated to reflect the change in data flow and manipulation. I hope this helps you manage your API structure in such a way as to make your code not only sustainable in the long run but easily managed and understood as your code base and team grows!

Here is a link to the collection of files discussed in this article: Gist Link

If you found this helpful or useful, please share a 💓, 🦄, or 🔖. Thanks!

Architecting Frontend Projects To Scale

Michael McShinsky — Mon, 06 Jul 2020 21:12:07 +0000

I, like any other web developers and engineers, prefer to make my work life as sane as possible. Having structure not only keeps life a little more pleasant, but is critical to scaling and even allows creativity to flourish! Having a clear structure and consistent plan in my code keeps me performant, allows me to better plan for scaling, avoid unnecessary refactoring code sessions, and understand the app hierarchy without having to re-learn each component or service every time I need to change or upgrade features.

Pretty much most developers who start out with most JavaScript frameworks use a built-in CLI (command line interface) that another team has built for the said framework in order to jumpstart the development process with minimal effort. Nothing is inherently wrong with this approach and this saves developers a lot of time from the first wave of configuration bugs. The next step after setup is to build out your code structure. Everyone, without a doubt, has opinions on this and will strongly defend their approach. I too have molded my own architecture that fits my projects as they grow.

In this article we'll use the create-react-app starter structure as a base configuration that anyone can start with when following along with this article and not get lost.

What this is and isn't

This is a dive into project structure and package opinions. This is not a comprehensive study into the "musts" and "must nots" of what libraries and packages to use and avoid. Your project is a living structure! My views and opinions apply to the issues you face may or may not have merit depending on the needs of your end users or development team. Hopefully, this article will provide another valuable perspective into keeping yourself and teams organized when working on small and large projects.

Basic Configuration

So you don't have to dig through links and websites, here is the create-react-app document structure you will see when starting out.

my-app
├── node_modules
├── public
│   ├── favicon.ico
│   ├── index.html
│   ├── manifest.json
│   └── robots.txt
├── src
│   ├── App.css
│   ├── App.js
│   ├── App.test.js
│   ├── index.css
│   ├── index.js
│   ├── logo.svg
│   ├── serviceWorker.js
│   └── setupTests.js
├── .gitignore
├── package.json
├── README.md
└── yarn.lock

I have a decently strong opinion about the src and components folder. Do not use the src or components folder for everything! This doesn't scale for larger applications and it is super annoying to dig through giant flat lists of .js files when you want to find a particular piece of code.

Uppercase versus Lowercase

Let's get this one out of the way quickly. React developers likes to define component specific files as uppercase based on said conventions from popular developers in this space. If you are on someone else's project that is uppercase, don't go changing all the file names. A standard has been set and there is a right time and a wrong time to approach changing an individual project's standards.

On the other hand, if you are going to be working on my project, lowercase file names is the standard we'll be living by. It makes sense, easy to read, and pretty much all other project types and frameworks use this approach. Also, hyphens between words is a must even if it makes it a tad bit longer than you are normally comfortable looking at.

Google's File Naming Standard

New Frontend Architecture

If you are just looking for an example for this article of how to structure your next project, I will link a simplified version of it to you right here. If you want to keep reading about why it is structured this way and understand the purpose of this architecture is, please, continue reading. We are going to adopt a MVVM architecture to manage our project.

Most of your projects starting out are probably going to be 100% frontend based working with an internal or external api or a separate data source that isn't bound tightly to the frontend code. Our architecture may alter, for example, if we were to structure our project with server side rending in mind. Let's take a birds eye view of what we have in our new app's folder.

my-app
├── assets
│   ├── images
│   ├── scripts
│   └── styles
└── src
    ├── components
    ├── constants
    ├── models
    ├── routes
    ├── services
    ├── views
    ├── utilities
    ├── index.css
    ├── index.js
    └── serviceWorker.js

index.js

In the provided example, index.js is used heavily to export multiple components or represent the parent components (container) of a view or shared element.

Assets

Let's break assets down a bit and understand what is going on:

assets
├── images
├── scripts
    └── vendors
└── styles
    └── vendors

The assets folder within the src folder is usually located here to represent internal only resources that should not be readily available to the public as a stand alone, linkable, or downloadable resource. Pdfs, downloads, blog post images, etc... could be stored instead in the public folder for mass distribution.

I'm not going to recommend a specific sub structure for images. I don't even have an defined opinion except probably keeping images grouped by pages, features, layouts, and specific use cases. Scripts will usually be third party libraries that don't have natural integration (import/require) into your project and you are okay with them living in the start or end of the body of your html document. The same goes for the styles folder.

The reason there is a vendors folder is because it is much easier to handle internally written files that live in the scripts and styles folders in the base folder while external/third party libraries will live in the vendors folder. This will make it much easier to reference visually for team members and even add associated overrides (if your can't modify the main libraries file due to possible future updates), e.g. bootstrap.min.css, bootstrap-overrides.min.css. Not ideal for some... but it is organized and easy to refer to. Remember, scripts and styles are primarily meant for third party libraries that will not be living within your main projects JavaScript documents and stylesheets.

Components

We are going to keep the components folder because I still believe that it is important. It's use should not be to hold your project but rather to hold components that will be shared throughout your project. This includes: layouts, private, public, templates, sidebar, header, etc... What ever you want that will be used more than once by multiple modules or views.

components
├── buttons
├── forms
├── layouts
├── partials
├── private
│   ├── header
│   ├── sidebar
│   ├── card
│   └── modal
├── public
│   ├── header
│   ├── pricing-tables
│   └── footer
└── shared

Note that I like to divide components that whose sole purpose belongs to the customer facing website or the user facing app by public and private. They could also be names website and app or you could keep all components folders on the same level under components. All that matters is giving a home or primary location to reusable components for your project. When it comes to the plurality of folder names, I am still undecided due to the high variable use cases of component naming.

Models and Services

Let's bundle these together. Using a MVVM approach as inspiration, models will hold constructors that will mold incoming and outgoing server data into repeatable and scalable objects. Services will hold the generalized and specialized functions that send this data back and forth between the client and the server. Services will also hold state based solutions like redux configurations or global context.

├── models
│   ├── client.js
│   ├── product.js
│   └── task.js
└── services
    ├── context
    ├── redux
    └── api
        ├── clients.js
        ├── products.js
        └── tasks.js

Constants

Anything that will be referenced globally in the app should be stored here. This can include:

Unique IDs from a database (id or guid).
Config values for difference api services that aren't part of an .env file.

Note that this folder could be substituted for .env file(s) holding all information if it is considered dynamic based on how your hosting is configured or company policy is enforced.

Utilities

Utilities can be one or many files that define small utility functions that your app will utilize. This may be things like specialized dates, formatters, or one use functions that are needed often but don't belong to any one component or module in your project.

Routes and Views

Most likely, most of your day will live between here and components, putting together the finalized code passed from designers to you for implementation. You have already written models and services to consume the data from the server, and now you need to utilize it. A basic view structure may look like the example below.

Putting routes into their own folder has been something newer for myself. Keeping routes together and importing the views for the routes has made it easier to manage how my more recent apps change as business requirements evolve. This is more of a personal preference than an insisted pattern for others to use.

routes
├── components
│   ├── private.js
│   ├── public.js
│   └── index.js
├── index.js
views
├── private
│   ├── clients
│   ├── dashboard
│   ├── products
│   ├── tasks
│   └── index.js
├── public
│   ├── about
│   ├── auth
│   ├── home
│   └── index.js
└── shared

Once again, I like to make sense of how my projects is structured visually by separating the public facing website and customer facing internal app. Each of these view component folders is where the view for a route is defined.

client
├── index.js
├── client-redux.js
├── client.scss
├── client-styles.js
├── tests
├── components
│   ├── modal 
│   └── // unique components for view
clients
├── clients-redux.js
├── clients.scss
├── clients-styles.js
├── index.js
├── tests
└── components
    ├── modal
    ├── list-item
    |   ├── list-item.scss
    |   ├── list-item-styles.js
    |   └── index.js
    └── // unique components for view

This example contains a range of possible files you may be using in your project. We also break out unique child components to the view that wouldn't make sense to have in our shared component folder by keeping them inside the view's component folder. By adopting a heavy view approach that contains just about everything related to the view, we can utilize maintaining new and old code as it is implemented and deprecated. This allows us to be lean and agile in our development cycle. We also avoid developer code and pull request overlap as different developers work on different features.

Conclusion

With that, we have defined the general outline of a more scalable and maintainable architecture. To an extent, this architecture is agnostic to your frontend libraries and is meant to be modified to the needs of your team. As projects are living and ever changing organisms, and I am fallible, please let me know if I am missing anything. What are your favorite or preferred approaches to frontend structure? Let me know in the comments below. I would love to hear from you!

If you want a starter version of this, a link has been provided here: React-Starter

If you found this helpful or useful, please share a 💓, 🦄, or 🔖. Thanks!

A React Hook You Don’t Need

Michael McShinsky — Mon, 29 Jun 2020 18:25:21 +0000

Since the release of React Hooks in version 16.8.0, developers have found countless ways to use them to their advantage. These advantages come in the form of easily managed theme states to wrappers that makes dealing with the React lifecycle a little bit easier. Most of these are glorified utility functions that have been upgraded to work seemlessly in the React environment. They (these hooks) usually handle their scope of work closely with the component that is implementing their functionality.

I as well, made a hook… that no one needs. This hook is called useHandleChange. A hook that manages the state of your form and the functional logic of all input changes and clicks. This allows you to manage the diverse components and HTML elements you may want to use in your app. You also keep the freedom of implementing your own validators and callbacks after each change if you so desire.

Why do I think this is a hook you don’t need? Let’s take a look at how this hook came to be. In order to do so, we’ll have to address the first problem useHandleChange solved before hooks and functional React components were the new kid on the block.

Class Based Form Components

When handling form data in React, you have two choices. Controlled and uncontrolled components. Simply put, controlled components are HTML elements in which you directly control what the value of an element is and how to change it when a user interacts with it. Uncontrolled components are these same HTML (JSX) elements which have default values from React with no managed value, change, or click functionality. They act in their natural state without being managed or controlled by the React lifecycle or React event listeners. When using uncontrolled components, you typically grab their values from the DOM by hand and store them in your state or function variables upon form submission, rather than during every click of the mouse or clack of the keyboard.

Here is a basic example of controlled components in React.

    import React from 'react';

    export class SignUpForm extends React.Component {
      constructor(props) {
        super(props);
        this.state = {
          name: '',
          email: '',
        };
      }

    _handleChange = (event) => {
        this.setState({ [event.target.name]: event.target.value });
      };

    _handleSubmit = (event) => {
        event.preventDefault();
      };

    render() {
        return (
          <form onSubmit={this._handleSubmit}>
            <fieldset>
              <div>
                <label htmlFor='formName'>Name:</label>
                <input
                  id='formName'
                  name='name'
                  type='text'
                  value={this.state.name}
                  onChange={this._handleChange}
                />
              </div>
              <div>
                <label htmlFor='formEmail'>Email:</label>
                <input
                  id='formEmail'
                  name='email'
                  type='text'
                  value={this.state.email}
                  onChange={this._handleChange}
                />
              </div>
            </fieldset>
            <button type='submit'>Submit</button>
          </form>
        );
      }
    }

In this last example, we note that there is a state to manage the form’s inputs and functions that directly control the data manipulation of the inputs. These are then saved back to the React state until we need them for submission. We’re using bracket notation in the object to shortcut and avoid writing extra variables. This is seen in the setState function. Also note that we have one function, _handleChange. This function is managing all data flow between the inputs and the state.

    _handleChange = (event) => {
      this.setState({ [event.target.name]: event.target.value });
    };

Complicated Inputs

What were to happen if we started to add in multiple types of form inputs and elements? We’d have to start adding functions to manage their unique properties. HTML inputs allow for the following type attributes:

button
checkbox
color
date
datetime-local
email
file
hidden
image
month
number
password
radio
range
reset
search
submit
tel
time
url
week

Each of these type attribute values have a slight difference in how to handle their value, display the value, and handling the value in different UI states. Some may have to use the attribute onClick to capture data change instead of the attribute onChange. Luckily for us, most use the same convention for managing their Event object in React which are received as event.target.name and event.target.value. So by having our first example function, you’ve already covered most of your input types. The inputs in question that we will focus on right now are: text, checkbox, radio, and file. These are the most common types used in the majority of forms.

Here are some of the functions we would have to write just to manage these inputs.

    function _handleChange(event) {
      this.setState({ [event.target.name]: event.target.checked });
    }

    function _handleCheckboxChange(event) {
      this.setState({ [event.target.name]: event.target.checked });
    }

    function _handleRadioChange(event) {
      this.setState({ [event.target.name]: event.target.checked });
    }

    // single file
    function _handleFileChange(event) {
      let file = event.target.files[0];
      this.setState({ [event.target.name]: file });
    }

    // multiple files
    function _handleFileChange(event) {
      this.setState({ [event.target.name]: event.target.files });
    }

That is a lot of functions to handle your form data! If we have a lot of forms across our app, we start to bloat our app with unneeded code! We can refactor these into a single function to handle all value types dynamically.

    function _handleChange(event) {
      let name = event.target.name ? event.target.name : event.target.type;

      let value =
        e.target.type === 'checkbox' || e.target.type === 'radio'
          ? e.target.checked
          : e.target.value;

      if (event.target.type === 'file') {
        value = event.target.files[0];
      }

      this.setState({ [name]: value });
    }

We know have a function that updates state for a lot of scenarios. What if we updated this to be used as a utility instead of writing this in every React component in our app.

    export function handleChange(event, state, callback) {
      let obj = { ...state } || {};
      let name = event.target.name ? event.target.name : event.target.type;
      let value =
        e.target.type === 'checkbox' || e.target.type === 'radio'
          ? e.target.checked
          : e.target.value;

      if (event.target.type === 'file') {
        value = event.target.files[0];
      }

      obj[name] = value;

      if (callback && typeof callback === 'function') {
        callback(obj);
      } else {
        return obj;
      }
    }

    // Usage Example

    let newState = handleChange(event, state, (obj) => {
      //... OR - Do something with the new state object if you want to set state here instead of from the returned variable.
    });

    this.setState(newState);

Our functions have now been wrapped up into a nice utility function that you can import into every component and combine it with your state and event handling logic. Once React hooks came out, we did shortcut some of this by updating state right on the input element, but if you needed extra functionality like validation or chained reactions, sending your event object to a function like this still becomes valuable.

Born From The Ashes

Since, generally, the functions described above have become semi-obsolete for very simple state updates on forms, I found less of a need to write them out like we have above. As mentioned earlier, for extra validation and error catches, passing the event object to a controlling function still is useful for our needs. One (opinionated) issue with React hooks, generally, is the pattern of one value/function combination for every input value. This is one of the reasons the classic Class approach was so appealing for managing state as an object. While it can be done with object copying — state setting functions, or custom reducers. Hint: you could even put our utility function inside your reducer! These generally feel like extra bloat that make my code feel a little bit messy, but still effective.

Example of a React hook approach refactored from the first example:

    import React, { useState } from 'react';

    export default function SignUpForm() {
      const [name, setName] = useState('');
      const [email, setEmail] = useState('');

    _handleSubmit = (event) => {
        event.preventDefault();
      };

    return (
        <form onSubmit={_handleSubmit}>
          <fieldset>
            <div>
              <label for='formName'>Name:</label>
              <input
                id='formName'
                name='name'
                type='text'
                value={name}
                onChange={(e) => setName(e.target.value)}
              />
            </div>
            <div>
              <label for='formEmail'>Email:</label>
              <input
                id='formEmail'
                name='email'
                type='text'
                value={email}
                onChange={(e) => setEmail(e.target.value)}
              />
            </div>
          </fieldset>
          <button type='submit'>Submit</button>
        </form>
      );
    }

Now that we have React hooks and everything is a hook, what if I could take the functions created above and write a hook? I could add some more utilities like deep object key/value changes, constructor functions, and integrate state management onto the hook instead of the React components we are writing. What more, what if it is published to npm as a package that can be used in every project and catch all the newest updates and bug fixes that may come up without having to fix each project individually with handle written functions. Hence, the birth of useHandleChange, a npm package that serves a React hook to manage your form state using the situations above while still giving you the freedom of integrating the state change with your favorite framework of choice.

Conclusion

The reason I call it a React hook you don’t need is because most of the functionality can be captured by calling the new hooks setState functionality directly on the input element. If you find yourself with the same bloat code with minimal external requirements for managing event data against your state, this may be useful to you. I hope that you have found this exercise in form state change to be useful and beneficial in leveling up your code!

If you found this helpful or useful, please share a 💓, 🦄, or 🔖. Thanks!

Webpack Aliases Keep My Code Sane

Michael McShinsky — Mon, 22 Jun 2020 13:04:23 +0000

Reference Mistakes Make Developers Look Bad

If you were to ask me what are one of the most common mistakes are in basic web development, I would, without hesitation, tell you that reference errors are one of the big ones out there. Whether they are with variables or package imports, I encounter and solve many problems for myself and other developers that make these mistakes constantly. Specifically with package imports, I wanted to stop dealing with changing all the path locations every time files were refactoring and improved.

You are probably familiar with what this looks like with some example code below.

    import { UserCard } from '../../../components';

    import { apiServices, themeServices } from '../../../services';

    import { objUtil, dateUtil } from '../../../utils';

What happens when you move a file or do a mass update to references throughout your app? You have to painfully go through and make sure every reference is correct. Next, you have to confirm that none of your pages crash or fail if your compiler is misconfigured and doesn’t recognize it as an error. Even worse… you reference another file on accident that has the same named export. As a result, you don’t notice until the code is pushed to production and now customers are calling in complaining that features have stopped working.

Aliases to the Rescue

Webpack solves these problems by giving us the ability to use “aliases”. Aliases are a way to let webpack know where to find our code by providing a word or character that represents a partial reference to where the code is located. Once webpack knows this, the code can be properly resolved while it is compiling during development or building the final package. This is especially useful, not only for JavaScript and TypeScript, but CSS as well.

In order to add this feature to our code, we need to start out by setting up our “resolve” inside webpack. Your code will probably end up looking similar to this:

    const path = require('path');

    module.exports = {
      //...
      resolve: {
        extensions: ['js', 'jsx', 'ts', 'tsx'],
        alias: {
          '@': path.resolve(__dirname, 'src'),
          '@components': path.resolve(__dirname, 'src/components'),
          '@utilities': path.resolve(__dirname, 'src/utilities')
        }
      }
      //...
    };

You can use as many aliases as you want if you have the use case for it. Overall, it ends up being pretty easy to use only the ‘@’ character as an alias to reference the ‘src’ folder, but you can create any name for any alias path that you want to. Once we have modified our webpack configuration to be similar to the code above, our old imports could now look something similar to this:

    import { UserCard } from '@/components';

    import { apiServices, themeServices } from '@/services';

    import { objUtil, dateUtil } from '@/utils';

So much better! Now when you refactor your code, you will always be referencing the same packages you intended to.

Working with Babel and TypeScript

If you are resolving your code in combination with webpack inside of Babel, ESLint or TypeScript, you may need to update their config files. These file could be: .babelrc, .babel.json, .eslintrc.js, tsconfig.json, config.ts, etc… depending on how you are set up. There are a couple differences in these files you may have to make as opposed to the webpack.config.js when resolving aliases.

Babel

    // .babelrc
    // npm i babel-plugin-module-resolver -D

    {
      "plugins": [
        "module-resolver",
        {
          root: ["./src"],
          alias: {
            @: "./src",
          }
        }
      ]
    }

ESLint

    // .eslintrc.js
    // npm i eslint-import-resolver-alias -D

    const path = require('path');

    module.exports = {
      //...
      settings: {
        'import/resolver': {
          alias: {
            map: [['@', path.resolve(__dirname, 'src')]],
          },
        },
      },
    };

TypeScript

    // tsconfig.json
    // npm i tsconfig-paths-webpack-plugin -D

    {
      //...
      "compilerOptions": {
        "baseUrl": "src",
        "paths": {
          "@/*": ["*"]
        }
      }
    }

If you don’t want to resolve your aliases in TypeScript and webpack, here is an example where we use both our TypeScript and webpack configuration files, but using a package install, keep the aliases inside our tsconfig.json. Also note that you usually only need the alias configuration in your .babelrc file if you are using webpack and defining the aliases in webpack. The overall goal for moving our aliases into TypeScript and Babel config files in the following example can be to keep our code DRY and in one location. This can avoid updating one configuration and then accidentally forgetting to update it elsewhere.

    // webpack.config.js
    // npm i tsconfig-paths-webpack-plugin -D

    const path = require('path');
    const TsconfigPathsPlugin = require('tsconfig-paths-webpack-plugin')

    module.exports = { 
      //... 
      resolve: {
        extensions: ['js', 'jsx', 'ts', 'tsx'],
        plugins: [
          new TsconfigPathsPlugin()
        ],
      } 
    };

Combine this code with your TypeScript “tsconfig.json” alias setup are you are up and ready to go!

Summary

Aliases taking over major references for variable and file imports make developers look good. Your code will look cleaner and you are much less likely to make mistakes with file refactoring and consolidation. After I had discovered aliases, I make sure that they exist in just about every project I work on. I would encourage you as well to consider if aliases are the right answer for you in saving yourself from one more bug to take care of or worry about before shipping code anywhere.

If you found this helpful or useful, please share a 💓, 🦄, or 🔖. Thanks!

Benchmarking JavaScript Loops and Methods (Part 2)

Michael McShinsky — Wed, 17 Jun 2020 18:16:18 +0000

If you are starting with part 2, be sure to check out part 1 by clicking here!

Non-Primitive Values

In part 1, we took a look at how different loops and methods are used to find the index or value from an array of primitive values, and what the performance implications were when using each one of them. In part 2, we will do the same thing, but target non-primitive values. In particular, we will make use of the non-primitive: Object. Since most of a developer’s data handling revolves more frequently around arrays of objects served from an API or any given data source, this should be fairly relevant to those who want to measure performance of the loops and methods that JavaScript offers and how to pick which one to use in a given situation.

We’ll make use of the same loops and methods in part 1. These are:

Let’s start with defining how these loops and methods work with some starter code examples. We’ll begin with defining what a non-primitive array looks like and some starter code that we will use for each of the examples in our performance test. Once again, we will be overly verbose than “one liner” snippets of code in order to expand upon a few more options available when using these loops and methods. We’ll remove includes, lastIndexOf and indexOf from this list (which were used in part 1 for primitive values) since when used with objects in an array, it is usually combined with another method like map.

Note: Due to the simplicity of the examples, error handling and validation (which could be layered in) are not part of and are not relevant to this discussion currently.

Example of Non-Primitive Array Using Objects

    let nonPrimitiveArray = [
      {name: 'Alpha', letter: 'A'},
      {name: 'Bravo', letter: 'B'},
      {name: 'Charlie', letter: 'C'}
    ];

Starter Code

    // Objectives:
    // 1. Find the value Bravo
    // 2. Find the index of 1

    const OBJECTIVE_STRING = 'Bravo';

    let arr = [
      {name: 'Alpha', letter: 'A'},  
      {name: 'Bravo', letter: 'B'},
      {name: 'Charlie', letter: 'C'},
      {name: 'Delta', letter: 'D'},
      {name: 'Echo', letter: 'E'},
      {name: 'Foxtrot', letter: 'F'},
      {name: 'Golf', letter: 'G'}
    ];

    let foundObject = null;
    let foundIndex = -1;

Example Loop

    // Using array and variables from base code block above…

    for (let index = 0; index < arr.length; index++) {
      const value = arr[index];

      if(value.name === OBJECTIVE_STRING){
        foundObject = value;
        foundIndex = index;
        break;
      }
    };

    console.log(foundObject);
    // expected output: {name: ‘Bravo’, letter: ‘B’};

    console.log(foundIndex);
    // expected output: 1;

For a full list of the loops and methods referenced in this article, click here.

Benchmarking the Code

We now have the basis to benchmark the loops and methods created and can now properly assess how each performs under various array sizes containing objects. Once again, we’ll include map, filter and reduce. Filter is still an anti-pattern like map and reduce because we want to find the value or index instead of returning a new value from the array by manipulating or creating something from the original array. This doesn’t mean you can’t. This only means that we are using them against their generalized intended functionality to show how they perform.

Arrays we will be using:

Array 1: 100 non-primitive values;
Array 2: 1,000 non-primitive values;
Array 3: 10,000 non-primitive values;

Finalized Results

Please remember that results may differ between hardware and software that various devices come with. Take that into account when planning on developing your code base that may have to be run on a full range of devices that are both on the high end and low end of the spectrum of both quality and speed. The following graphs represent the operations per second (op/s) that each loop or method can run in a give timeframe. This means that they will loops over our various array sizes as many times as possible with the goal each time to find the non-primitive value defined in the tests.

Chrome

Edge

Firefox

What Does This Mean?

Now that we have the performance measurements for our browsers (Chrome, Firefox, and Edge), we can make some comparisons and conclusions. Let’s take a look at how each of their engines (Chakra, V8, and SpiderMonkey) are handling finding objects by their value within the near beginning and near end of an array.

Small Sized Arrays

Generally, the performance of all loops and methods across all browsers are high. Firefox, just like our part 1 primitive counterpart, achieves the highest performance in operations when dealing with small arrays.

Chrome: forEach, map, and reduce perform quite well, far outpacing the remaining loops and methods.
Edge: We see the same result here as we did with Chrome. findIndex seems to be slightly more performant than the others as well, but the difference is too small to be very important.
Firefox: It’s safe to say that the use of just about any loop or method when dealing ONLY with small arrays would be acceptable here.
Overall Performers: forEach, map, and reduce

Medium Sized Arrays

Performance impacts are more greatly seen here than with primitive arrays and earlier too. We are starting to be able to make more educated decisions on the kind of array manipulation techniques to use for the client side code.

Chrome: for, while and do…while separate themselves from everyone else fairly easily. At this point, most other loops and methods fail to perform at the same level.
Edge: The same trend as Chrome is once again seen here. for…of is our only other alternative that has a somewhat positive performance.
Firefox: The JavaScript engine, SpiderMonkey, follows the same optimization path as it’s competitors with for, while and do…while performing the best as well.
Overall Performers: for, while and do…while

Large Sized Arrays

Looking at the graphs above, it’s safe to say that with all browsers, for, while and do…while are our top performers once again. Once our data sets start to get really large, for…of is the only other loop that performs decently while the rest of our loops and methods have a dramatic loss in performance.

Overall Performers: for, while and do…while

Conclusion

Just like part 1, it is interesting to see the effect of iterating over different sized data sets with the various loops and methods JavaScript provides us with. The performance changes dramatically as our data grows. This kind of information should play at least a small part in helping look for optimizations when dealing with large amounts of data in order to best plan for performance for all users and devices. I would encourage you to take a look at the user experience you are providing to users and determine if you can do better by them by improving the way you handle the data.

If you found this helpful or useful, please share a 💓, 🦄, or 🔖. Thanks!

Benchmarking JavaScript Loops and Methods (Part 1)

Michael McShinsky — Mon, 15 Jun 2020 12:04:49 +0000

Part 2 is now available here!

Introducing Loops and Methods

We’re going to take a look at the various loops and methods provided in JavaScript to find out which ones are more efficient for the data you are iterating over. The reason I’ve taken the time to put this together comes from watching the evolution of developers and how they use and form opinions about these various loops and methods.

Everyone starts with your basic for loop. Once a new developers learns this, their minds are blown and life becomes easier. This mind blown experience happens over and over as new methods are introduced. What is interesting, is that as soon as new loop and methods are introduced (while, forEach, map, filter, etc…), the basic for loop is left behind in the dust for a long time. This happens anywhere from the first few weeks to the next few months. It will either take a long time or a specific experience in data manipulation for a developer to comes back and consider the basic for loop again in order to meet their objectives.

For this reason, we are going to see if there is any justification to only using methods such as forEach and map, or if there is any merit in sticking with the tried and true for loop.

Data Types

We’re going to tackle each of these loops and methods to discover their advantages and disadvantages against Primitive and Non-primitive data types. If you need a refresher on these data types, here is a list you generally work with.

Primitives

Non-Primitive

Finding a Value in an Array

Our benchmarks will show us how efficient our loops are at retrieving, depending on the return value, the value or the index of the value from the array. The loops we will use are:

Let’s start with a small example that displays each of these loops finding a primitive value a from sample array. Note, we’re going to be a little more verbose than some of the "one liner" functions out there in order to capture more values.

Examples of Primitive Arrays:

let namesArray = ['Abe', 'Beth', 'Cody', 'Daniel'];
let textArray = ['Dog', 'Cat', 'Horse', 'Cow'];
let numbersArray = [1, 2, 3, 4];

Starter Code

// Objectives:
// 1. Find the value 7
// 2. Find the index of 7

const OBJECTIVE_NUMBER = 7;

let arr = [1, 2, 3, 4, 5, 6, 7, 8, 9];
let foundValue;
let foundIndex = -1;

Let’s give ourselves an example of the kind of code we’ll be using for benchmarking. For a full list of loop and method examples, click here!

"for loop" example

// Using array and variables from base code block above…

for (let index = 0; index < arr.length; index++) {
  const value = arr[index];

  if(value === OBJECTIVE_NUMBER) {
    foundValue = value;
    foundIndex = index;
    break;
  }
};

console.log(foundValue); // expected output: 7;
console.log(foundIndex); // expected output: 6;

Benchmarking the Code

Now that we have a base understanding of each of the loops and the possibilities they bring to the table, we can see how they perform against small and large data sets. We’re going to include map, filter, and reduce, even though they are being used in an anti-pattern fashion in order to demonstrate performance across the board. We’ll also benchmark our iterations at finding the value near the start and end of the array for every loop and method. We’ll also test them on different browsers to measure the performance of each browser’s JavaScript engines (Chakra, V8, and SpiderMonkey) which are iterating and optimizing our loops in the background.

Arrays we will be using:

Array 1: 100 primitive values;
Array 2: 1,000 primitive values;
Array 3: 10,000 primitive values;

Note: In Part 2, we’ll look at the same loops but against non-primitives (objects, arrays, functions) and measure performance against them.

Finalized Results

Before we talk about the following results, please remember that there will be variances on performance depending on the hardware and software per user. As a result of this, we as developers should plan for the worst case scenarios in order to provide an optimized experience to users across all platforms and devices. With that in mind, let’s take a look at how our loops performed when searching for a primitive value inside an array.

Note: The graphs represent each loop or method and how many operations per second (op/s) are ran within a given timeframe.

Chrome

Edge

Firefox

Breaking Down the Results

After looking at the charts, we can make a few general conclusions:

As data sets get larger, map, reduce, and filter perform the worst when used against their intended purpose or definition.
Against small arrays, Firefox’s engine (SpiderMonkey) is optimized across all methods to iterate over arrays and find values both at the start and end of said arrays.
lastIndexOf performs as expected. It is worse when searching the start of an array and the best when searching for end values. Since this is expected, we will remove this method when comparing for overall performance.

Small Sized Arrays

Let’s start with small arrays for some overall takeaways.

Edge: forEach, map, and reduce perform the best.
Chrome: forEach, map, and reduce perform the best.
Firefox: all methods except map, filter and reduce perform well, but not by much.
Overall Performer: forEach

Medium Sized Arrays

We notice next, that with medium sized arrays and especially when looking for values near the end of the array, performance starts to shift a lot across all the loops and methods.

Edge: indexOf and includes perform better followed by while, do…while, for, and for…of.
Chrome: indexOf and includes take the cake for performance followed by for, while and do…while.
Firefox: A higher performance is recorded here than in Edge and Chrome. for, while, indexOf, and includes are all high performers.
Overall Performers: indexOf and while, since we’re are generally looking from the front to back for our value.

Large Sized Arrays

Finally, we see a much higher drop off in performance as our array grows in size.

Edge: for, while, and indexOf perform the best. Most other loops and methods end up doing poorly.
Chrome: for, while, indexOf and includes stay on top while yet again, we see most other methods failing to perform at the same level.
Firefox: for, while, and indexOf once again are top contenders with the same drop off seen with most of the remaining loops and methods.
Overall Performers: for and while.

Conclusion

Hopefully, as a result of seeing the data, we can all make better decisions on the methods we want to use against various data sets. If we are working with data that may grow over time and we have to iterate over all that data, it may be appropriate to come back to the reliant for loop that has always been there for us. Especially since you can take advantage of it's inherit ability to stop to loop with break and return once you have finished your intended action. While it may not look pretty, it will always be handy.

In Part 2, we will show similar data, but introduce searching non-primitives to see how the results change. This should be even more relevant to daily tasks since a lot of the data we work with comes back as JSON arrays full of objects from a database.

If you found this helpful or useful, please share a 💓, 🦄, or 🔖. Thanks!

Merging JavaScript Objects

Michael McShinsky — Wed, 10 Jun 2020 23:12:32 +0000

This article will show you how to merge two or more JavaScript objects into a new object. The new object will contain the properties of all the objects that were merged together. JavaScript provides multiple ways to accomplish this task with a lot of different methods. Here, we will take a look at three of the more popular approaches. These are:

Spread - The spread (…) operator
Assign - The Object.assign() method
Loop - Object loop method (for…in)

Spread Operator

The spread operator was introduced with ES6 and allows us to merge multiple arguments or objects and returns a new combined value anywhere defined in your code.

If any of the objects or values added to the spread operation share the same property or name (e.g. firstName), the last one passed into your operation will be the value taken and overwrites any earlier values with the same key when creating your new object. This can be seen in our example above.

One important factor in using this approach is that the shape of your final value is defined by the wrapping characters. That is, we use the opening and closing braces ("{ }") to determine the resulting shape of our action, in this case, an object. Another result shape we can use are brackets ("[ ]") when combining arrays to create a new array.

Object.assign()

The object prototype method assign is a tried and true method introduced with ES5. The spread operator has since taken over to do the same thing, but if you don’t have browser support for the latest and greatest, or you have to support older browsers, the assign method may be your go to in these niche situations.

In the code shown above, the assign method takes one or many arguments just like the spread operator. Just like the spread operator, if we need to define and default or ending shape of our variable, we add in an empty object {} that the following objects will fill into.

Object Loops (for…in)

Our final method for merging objects are loops. This is an older method and is not nearly as popular as spread and assign, but it does come with some convenient customizations if you need more granular control over how your objects will be merged. We’ll upgrade it slightly to use some ES6 flavoring (for…in, and reduce) while we’re at it. No need to stay old school in everything, right?

We can see in the code above that we first loop over the passed in object(s). In this case we are making use of the rest parameter syntax in our function parameters. Then we loop over each object and it’s keys in order to create our final object.

One important note to remember is that when JavaScript merges your objects and values into a new object, this is considered a shallow copy. This means that top level values contain no reference to the old objects values, whereas deeper or nested values may contain a reference to the original object. If you update our newly created object, old object references may update as well!

There are some verbose examples of what are called “deep copying” functions provided by different libraries and individuals (e.g. jQuery.extend(), lodash, underscore, JSON.parse(JSON.stringify), etc…). Be warned that these are expensive operations. Doing deep copies over large lists of data could highly impact user experience and performance on the device running your code! If you find yourself doing this a lot or wanting to do this a lot, take a step back and think about the architecture of your code and decide if there is a more DRY or maintainable way to break apart and manage your code’s state.

Conclusion

Whichever is best for your project is the best approach for you! Which browsers you need support will be one of the main factors in the choice you make between these and other solutions. If you are only supporting the latest and greatest browsers, you will probably end up using the spread operator a lot more than the others. On the other hand, if you have to want that granularity or old browser support, you may fall back to manual loops. Sometimes, it’s about what your team decides to use to be consistent with each other. In the end, it’s all up to you!

If you found this helpful or useful, please share a 💓, 🦄, or 🔖. Thanks!