DEV Community: Will Preble

Socket.io Namespaces and Rooms

Will Preble — Tue, 21 Jul 2020 03:28:47 +0000

Getting Started with Socket.io

Socket.io is an easy-to-use JavaScript library for enabling WebSocket connections. WebSocket is a computer communications protocol that provides two-way, or full-duplex, communication channels over a single TCP connection.

Once a connection between the server and client is established, the server can push information to a client without a request. This is opposed to the standard HTTP request-response cycle in which the server returns information to a client in a response only after receiving a request from the client.

Once multiple clients are connected, the server can facilitate low-latency, peer-to-peer connections between these clients. Common applications of P2P networks include text chat, video chat, and file sharing. Networks of clients can be connected for group applications. Socket.io was exciting to learn because it greatly expanded my range as a developer.

Dependencies

The Socket.io library is split into two modules, one for server and one for client. Before starting any Socket.io project, make sure to install both of these dependencies. If you’re using TypeScript, there are useful type libraries for each.



# server library
npm i socket.io 
# client library
npm i socket.io-client
# server types library
npm i @types/socket.io
# client types library
@types/socket.io-client

Server Setup

Here’s a bare minimum server setup in Express.



const app = express();
const server = http.createServer(app);
const io = socketConnect(server);

io.on('connection', socket => {
  socket.on('any event you want', () => {
    /* Code to run upon hearing an emit from the client */
  });
  socket.on('another event', () => {
    /* Code to run upon hearing an emit from the client */
  });
  socket.on('disconnect', () => {
    console.log(`user ${socket.id} disconnected`);
  });
});

server.listen(process.env.PORT || 8000, () => console.log('server is running on port 8000'));

All of the .on listeners should correspond to an .emit method on the client side, except the disconnect listener will run anytime a client disconnects from the server. This emit signal is sent automatically by the client.

Next I’ll discuss the similarities and differences between Namespaces and Rooms, two different server logic compartmentalization strategies. If you feel a little lost at this point, check out (this tutorial)[https://socket.io/get-started/chat/] for setting up a simple chat application with socket-io.

Socket.io Namespaces

Once you have a basic server setup, and a socket connection initialized and assigned to a variable, typically io, it’s time to start thinking about namespaces. By default, if a namespace is not specified, they will be attached to the default namespace /.

Namespaces are used to separate server logic over a single shared connection. A common use may be to separate admin concerns from those of regular users.

I recently built a video chat application that also had a text chat. In order to modularize the code I used two different namespaces.



const chatNsp = io.of('/chat');
chatNsp.on('connection', socket => {
  console.log(`${socket.it} connected to chat namespace`);
  /* chat namespace listeners here */
});

const videoNsp = io.of(‘/video’);
videoNsp.on('connection', socket => {
  console.log(`${socket.it} connected to video namespace`);
  /* video namespace listeners here */
})

On the client-side, I can tell the Socket.io client to connect to my custom namespaces:



const videoSocket = io('/chat');
const chatSocket = io('/video');’

Although it is possible to dynamically create namespaces, it is not common practice. Rooms are usually better suited for this purpose.

Socket.io Rooms

Rooms are subdivisions of namespaces that can be created by the server. This allows you to broadcast data to a subset of related sockets.

Two useful methods are provided for joining and leaving rooms, .join(room, callback) and .leave(room, callback) respectively. Both take two parameters, the room name and a callback.

My video chat application had several rooms and users were free to switch between them. Each time a user would switch, the client would emit the previous room and the new room.

The listener on the server would start by leaving the previous room with socket.leave(). Then, within the callback, the server connects the client to the new room with socket.join().



socket.on('switch room', (previousRoom, newRoom) => {
  socket.leave(previousRoom, () => {
    // use socket.to() to target users within a specific room
    socket.to(previousRoom).emit('user left room', socket.id);
    socket.join(newRoom, () => {
      socket.to(newRoom).emit('user joined room', socket.id);
    });
  });
});

The great thing about rooms is that there is no need to create them before they are needed. Socket.io handles room creation automatically if the room doesn’t exist yet and tears them down automatically if all users leave.

Conclusion

Socket.io is a great library to learn WebSocket communication technology. Namespaces and rooms provide quick ways to modularize code and communicate between different networks of clients. For more useful server methods, I recommend this cheatsheet from the Socket.io docs. Thanks for reading.

TypeScript with React Functional Components

Will Preble — Thu, 16 Jul 2020 15:33:31 +0000

TypeScript has become a very popular enhancement for JavaScript applications. TypeScript is a superset of JavaScript that forces static typing and compiles into plain JavaScript. Similar to other statically-typed languages like C# or Java, it forces you to be deliberate with variable types by declaring them upon creation.

In this blog, I’ll cover the basics of incorporating TypeScript into the popular front-end framework (er… library) React with a focus on functional components and hooks.

If you’re completely new to TypeScript, check out my introduction.

Getting Started

To get up and running, let’s create a new React-TypeScript project directory with the popular generator, Create React App. The following command will install the basic type libraries for React, give us a few scripts for testing and building, and give us a default tsconfig file.

npx create-react-app my-app --template typescript

Next, let’s run the start script to see the default React App.

npm run start

This should automatically open up a browser window. A spinning React logo is cool, but let’s get rid of this bloat so that we can focus on our changes.

Replace the div in the return statement with a simple Hello World message.

<div className="App">
  <h1>Hello World</h1>
</div>

If you leave your left your start script running, you should see this change reflected in your browser.

Functional Component with Properties

Create a file called Child.tsx with the following starter code. This will create a simple component with three properties: name, id, and bio. Bio should be set to a default value.

import React from 'react';

const Child = ({ name, id, bio = 'Bio empty' }) => {
  return (
    <div>
      <h2>Name: {name}, Id: {id}</h2>
      <p>{bio}</p>
    </div>
  )
};

export default Child;

Import the Child module into your app component, and add the following element below the h1 tag.

<Child name="Billy" id={123} />

Even this simple rendering will cause compiling errors. This is because we haven’t typed our properties. If you look closely, we haven’t typed our Child component function either. Thankfully, we can make use of the React types library by simply importing the FC type. This is an alias for FunctionalComponent which is also acceptable. We’ll also import ReactElement which will be the return signature of the function

import React, { FC, ReactElement } from 'react';

Next, type the properties for the Child component. In order to use a default parameter for bio, we will make it optional with the ? character.

type ChildProps = {
  name: string,
  id: number,
  bio?: string,
}

Finally, define the function type and the return type, ReactElement.

const Child: FC<ChildProps> = ({/* destructured props */}): ReactElement => { 
  /* function body */ 
};

If you are using an IDE that is compatible with TypeScript such as VSCode, you can hover over the property to confirm the type has been defined correctly.

If you try to change the type of the attribute in the parent component, such as passing a string for an id, TypeScript will throw a compile error.

Your child component should now be rendering correctly.

React Hooks

useState()

When using the useState hook, make sure to set the initial value to the correct type, and TypeScript will use type inference to determine the proper typing. A common pattern would be to establish the initial value as a prop.

const Child: FC<{ initialClick?: number }> = ({ initialClick = 0 }): ReactElement => {
  const [click, setClick] = useState(initialClick);
  return (
    <div>
      <p>Click: {click}</p>
      <button onClick={() => setClick(click + 1)}>Click Me!</button>
    </div>
  )
};

TypeScript can also infer type from a hard-coded initial state.

// click will be inferred to be a number
const [click, setClick] = useState(0);

useEffect()

useEffect, the swiss army hook that replaced component lifecycle methods, accepts two parameters. The first must be a function, and a second optional parameter for specific states. As long as these two parameters are the correct type, TypeScript will compile correctly without any extra code. Here is a simple example to highlight the useEffect hook. This useEffect will only trigger when the component is loaded and when Button A is clicked.

const Child: FC<ChildProps> = (): ReactElement => {
  const [clickA, setClickA] = useState(0);
  const [clickB, setClickB] = useState(0);

  useEffect(() => {
    if (clickA === 0) {
      console.log('Component loaded!')
    } else {
      console.log('Button A was clicked!');
    }
  }, [clickA]);

  return (
    <div>
      <p>A Clicks: {clickA}</p>
      <p>B Clicks: {clickB}</p>
      <button onClick={() => setClickA(clickA + 1)}>Button A</button>
      <button onClick={() => setClickB(clickB + 1)}>Button B</button>
      <p id="click-a"></p>
    </div>
  )
};

useRef()

useRef is an interesting hook because it can give a parent element information about a child element. Here is a typical assignment that can occur inside of the function body of a functional component.

const buttonElement = useRef<HTMLButtonElement>(null);

Assign the constant to the ref attribute of the child component.

<button onClick={() => handleClick()} ref={buttonElement}>Button A</button>

Once you assign a reference, you can use any element property or method on that reference by accessing the .current property. Below, I’m using the getBoundingClientRect method to access position info about the button. However, TypeScript won’t be happy with this code.

const handleClick = () => {
  // this will throw an error because buttonElement.current could be null
  setButtonInfo(buttonElement.current.getBoundingClientRect());
}

A simple workaround is to wrap your reference in a conditional.

const handleClick = () => {
  if (buttonElement.current !== null) {
    setButtonInfo(buttonElement.current.getBoundingClientRect());
  }
}

When putting it all together, make sure to assign the type of ref you are assigning, in this case an HTMLButtonElement. Notice I also assigned the type of the buttonInfo state to a ClientRect.

const Child: FC<{initialInfo?: ClientRect}> = ({ initialInfo }): ReactElement => {
  const [buttonInfo, setButtonInfo] = useState(initialInfo);

  const buttonElement = useRef<HTMLButtonElement>(null);

  const handleClick = () => {
    if (buttonElement.current !== null) {
      setButtonInfo(buttonElement.current.getBoundingClientRect());
    }
  }

  return (
    <div>
      <button onClick={() => handleClick()} ref={buttonElement}>Button A</button>
      <p>Top: {buttonInfo?.height}</p>
      <p>Bottom: {buttonInfo?.width}</p>
    </div>
  )
};

Conclusion

In the beginning, TypeScript can feel like an encumbrance to JavaScript programmers who are not used to thinking much about type. However, these habits can lead to tricky bugs and waste lots of time in development, especially in large or complicated applications. TypeScript forces you to adopt better habits and has great support from the React community.

Hope this blog was helpful. For more information about TypeScript and React including integration with class components, I recommend this blog.

Deploy a Full-Stack App on GCP with a Cloud SQL Connection: Part 2

Will Preble — Wed, 08 Jul 2020 02:38:08 +0000

This is Part 2 of a two part series focused on deployment of a full-stack, JavaScript application on Google Cloud Platform.

In Part 1, I covered setting up a GCP account, creating an App Engine, using the Cloud Shell terminal to clone a Github repo into the cloud, and configuring the app.yaml.

In Part 2, we’ll create a Cloud SQL instance, make additional configurations, and deploy the app!

Make a Cloud SQL Instance

From the Google Cloud Platform dashboard, navigate to the SQL product page by searching in the Search products and resources bar. Then, click Create Instance.

On the following screen, select Choose MySQL.

Select an Instance ID and a Root password. Make sure to write the password down somewhere. I usually have a text file open while I’m deploying where I can temporarily write down credentials which will eventually end up in the app.yaml.

We can use the default values for the remaining options. Click Create.

This will take a minute or two to spin up. Make a note of the Instance connection name from the instances table. It should have the following form: instance-id:zone:instance-name.

Enable Cloud SQL and Cloud SQL Admin APIs

Before we forget, let’s enable the Cloud SQL and Cloud SQL Admin APIs. Search for them in the Search product and resources bar. In my case, the Cloud SQL API was already enabled, but I had to manually enable the Cloud SQL Admin.

Simply click Enable. This is the only step here because you won’t need credentials for connecting via the App Engine.

Development Configuration

With the exception of the app.yaml file which should only exist in the cloud repo, all of these changes should be made in your local development environment. After making these configuration changes, you should be able to seamlessly pull them into the cloud repo.

Server Configuration

The Google Cloud Platform App Engine expects there to be an npm start script inside your package.json to start the server upon deployment. If for some reason this doesn’t exist, create it inside the scripts of your package.json. Make sure your file path matches the location of your server index file.

{
  "scripts": {
    “start”: “node server/index.js”
  }
}

Front-End Configuration

All you really need here is an index.html file somewhere inside the client side of the repository to bootstrap the front-end. Obviously this should exist. Since, I’m usually using Webpack or a similar bundler, this index file simply runs the bundle script.

A sample index.html for a React front-end built with Webpack:

<!DOCTYPE html>
  <html>
  <head>
    <title>Project Title</title>
  </head>
  <body>
    <div id="app"></div>
    <script type="text/javascript" src="bundle.js"></script>
  </body>
</html>

Database Configuration

Now let’s get the database configuration correct. In my experience, this is where most projects run into issues. I’ll show two options here, one database configured with the (mysql node package)[https://www.npmjs.com/package/mysql] and another with (Sequelize)[https://sequelize.org/].

mysql:

const mysql = require('mysql');

const DB_HOST = process.env.DB_HOST;
const DB_USER = process.env.DB_USER;
const DB_PASS = process.env.DB_PASS;
const DB_NAME = process.env.DB_NAME;

const connection = mysql.createConnection({
  host: `/cloudsql/${process.env.DB_INSTANCE}`,
  user: DB_USER,
  password: DB_PASS,
  database: DB_NAME,
  socketPath: `/cloudsql/${process.env.DB_INSTANCE}`,
});

sequelize:

const { Sequelize } = require('sequelize');

const DB_NAME = process.env.DB_NAME;
const DB_USER = process.env.DB_USER;
const DB_PASS = process.env.DB_PASS;
const DB_INSTANCE = process.env.DB_INSTANCE;

const sequelize = new Sequelize(DB_NAME, DB_USER, DB_PASS, {
  host: `/cloudsql/${process.env.DB_INSTANCE}`,
  dialect: 'mysql',
  dialectOptions: {
    socketPath: `/cloudsql/${DB_INSTANCE}`,
  },
});

Navigate back to the app.yaml file in the Cloud Shell terminal to include these database environment variables. The app.yaml should and must be in the root directory of the project folder.

runtime: nodejs10

env_variables:
  DB_USER: "root"
  DB_NAME: “<your-database-name>"
  DB_PASS: "<your-database-password>"
  DB_INSTANCE: "<your-database-instance-name>"

Pull Latest Version & Build in the Cloud

If you’ve followed all the steps so far, you should have a GCP project setup with an App Engine, Cloud SQL instance, and a cloned repository cloned with an app.yaml in the project root directory. If you’ve made any upstream changes to your repository since your initial setup, feel free to pull those changes in now. As long as you added the app.yaml to the .gitignore before cloning it into the cloud and resisted the urge to make any last minute corrections in the cloud, you should be able to pull your new code without any conflicts.

Next run your client and server build scripts in the Cloud Shell terminal.

Deploy Your App Engine

The final step is really easy! Simply run the following command in the Cloud Shell terminal.

gcloud app deploy

And that should do it! Google will give you a link where your new app is hosted. To double check that everything has connected properly, navigate to the App Engine Dashboard and select Services from the left-side navigation panel. In the Services table, select Logs from the Diagnose dropdown menu.

If for some reason you are in the wrong project, you may receive an error message. Simply run the following command to switch projects.

gcloud config set project [PROJECT_ID]

Conclusion

That’s it for Part 2! We’ve created a Cloud SQL instance and made configurations across the stack to ensure a smooth deployment. And hopefully, you were able to successfully deploy your app! In case you missed it, be sure to check out Part 1 of this tutorial. Thanks for reading!

Deploy a Full-Stack App on GCP & Make a Cloud SQL Connection: Part 1

Will Preble — Sun, 05 Jul 2020 16:21:01 +0000

Prerequisites

This will be a two-part tutorial focused on deployment of a full-stack, JavaScript application on Google Cloud Platform. The relevant tech stack I’ll be focused on is a SQL database and a Node server. I also used React and Webpack although any front-end framework and build strategy should be fine. I’ll touch on this in Part 2 when it’s time to deploy.

In Part 1, I’ll cover setting up a GCP App Engine and configuring the app.yaml.

In Part 2, l’ll cover setting up a Cloud SQL instance and deploying with a successful database connection.

I’m going to assume that you have built a full-stack JavaScript app in a local development environment and are ready to deploy some initial version. If you’re under a deadline for an application, it’s always a good idea to deploy early! Once your production environment is configured properly, redeploying new versions should only take a minute or two.

Signup For a Google Cloud Platform Account

Next, make sure you have a Google Cloud Platform (GCP) account. If you are just signing up for an account, Google should give you $300 of free credit to start experimenting. Just make sure you activate it when you make an account.

If you’re like me, you’ll probably make mistakes and have several duplicate projects working out the kinks. Just make sure you shutdown old projects and instances that are no longer being used so that you don’t waste your free credit!

You’ll need a credit card to make a GCP account. Google claims this is for authentication and that they won’t roll you into automatic billing when your credit expires. I’m trusting you Google!

Once you’ve jumped through these hoops, let's get started!

Create a Project in the Cloud

From the Google Cloud Platform dashboard, click the project dropdown in the navbar to create a new project. This will either say “My First Project” or a project name. Click the New Project button.

Give your project a name. You won’t be able to change this name so choose carefully. You can leave the organization as No Organization.

After creating the project, you will land on the project dashboard. Around this time, you may start to realize the breadth of options available to you on GCP. It can feel overwhelming!

I like to use the Search products and resources bar to find what I’m looking for because the Navigation menu is hilariously overstuffed.

Create an App Engine

Navigate to the App Engine resources page and click Create Application.

[APP ENGINE CREATE APP IMAGE]

Select the region closest to your app users. This should be filled correctly automatically unless you are using a VPN or blocking your location in some other way. Then, click Create App.

Next, select your language. Assuming you built a JavaScript app, select Node.js. You can leave the Environment as standard and select Next.

Boom. App Engine created. That was easy!

Activate the Cloud Shell

Feel free to download the Cloud SDK if you want. That won’t be required for this tutorial since I’ll be showing you how to use the Google Cloud Shell in your browser.

In the navbar, click the Activate Cloud Shell icon.

This opens a bash terminal in the browser. Your terminal will be organized by project. Since we already are inside of a project, your command line should have the following format:

username@cloudshell:~ (project-name) $

If for any reason your terminal instance doesn’t have the correct project name associated with it, you can change it with the following command, where PROJECT_ID is the project name:

gcloud config set project [PROJECT_ID]

Clone the Repository Into the Cloud

Before we move on, I recommend adding the following two files to your .gitignore and pushing the changes to your repo: app.yaml and .gcloudignore.

GCP will ultimately need these two files in the cloud repo, but they shouldn’t live in your local environment. This is especially true regarding the app.yaml which will contain your environment variables. On GCP, instead of a .env file, you will be declaring your environment variables inside the app.yaml. The same rule applies to the .env and the app.yaml:

Never commit a file containing environment variables to a public repository because malicious bots can steal your credentials!

As you’ll see later, this change to the .gitignore file will pave a smooth workflow for updating your deployed version even if you make minor changes in your development environment.

Next, copy your clone link from your Github repository, and clone it inside the cloud shell.

git clone <clone link to your github repository>

Change directories into your project, then open the terminal in a new window. Next open the editor.

The Google Cloud editor looks remarkably like VSCode.

In the project root directory, create the app.yaml.

touch app.yaml

Next add the following line of code to the app.yaml:

runtime: nodejs10

This simply informs GCP that your app is intended to run in the node environment. Version 10 is the earliest version of node supported by GCP.

Conclusion

That’s it for Part 1! We’ve created an App Engine inside of a Google Cloud Project. Then we used the Google Cloud Shell to clone a Github repository into the cloud. Finally, we added an app.yaml to the project directory and configured our local IDE to ignore this file in the Git workflow.

Next week in Part 2, we’ll create a Cloud SQL instance, make the necessary configurations, and deploy the app!

Upgrade Your Styling With Tailwind CSS

Will Preble — Sun, 28 Jun 2020 17:17:45 +0000

Styling Is Very Important for Full-Stack Developers

In full-stack development, I’ve found styling often gets the least attention. This is a shame and has doomed many great apps to obscurity. The style of your app will be everyone’s first impression! It is very important! This is especially true when you are building out a portfolio for job hunting.

Your apps could function perfectly with amazing features, but with weak styling, your average user will never find out about them because they will be bored and leave.

Your styling doesn’t need to be great! Leave that to professional designers. It just needs to be not bad.

As a full-stack developer, aim for good styling.

Why Use Tailwind?

CSS is the language that web-based styling is composed in.

Writing raw CSS is psychotic. You may think it’s fun on FreeCodeCamp, but in the context of a full application, you’ll find yourself maintaining thousands of lines of code and worse, hundreds of uniquely named classes.

The most popular framework for CSS is Bootstrap. Bootstrap is great if you want every button on your website to look like you stole it from Twitter dot com.

It’s a victim of its own success. Every website designed in the last decade uses bootstrap, and they all look the same. Default settings are difficult to change and people are lazy.

So here’s the pitch for Tailwind CSS direct from their website:

Tailwind CSS is a highly customizable, low-level CSS framework that gives you all of the building blocks you need to build bespoke designs without any annoying opinionated styles you have to fight to override.

Sounds great! I’ll get over my distrust of things bespoke.

In my short experience with Tailwind, I have found it to be the most intuitive, beautiful, quick, and easily customizable option for styling that I’ve ever used.

Tailwind Utilities

The other thing you will hear about Tailwind is that it is utility-first.

A utility is a built-in, pre-named class. Once you have configured Tailwind (see below), you can simply insert these class names directly into your html.

When I heard that Tailwind came with thousands of pre-named classes, I was already sold. I hate coming up with class names. It’s like how Obama made someone else choose his suit color, “I have too many other decisions to make.”

The syntax is as simple as naming classes.

<p class="text-xl text-gray-600 leading-normal">You have a new message!</p>

Check out some of the detailed examples in the Tailwind docs such as this one for creating cards. I recommend copying the entire example over, which is intentionally complex, and using the Tailwind CSS Intellisense hover feature to identify the CSS used in the example utilities. This will build your intuition for utility names.

Customizing Tailwind

The fact is, Tailwind utilities break down styling to a low enough level that you may not find the need to ever customize them. But you totally could, and it’s easy to do so. It just requires editing the tailwind.config.js file which should be in your project root directory (see below). This is also where you could define color schemes and other project level design schemas.

styles.css

You probably won’t find yourself writing much CSS when you first start using Tailwind, but you still need a styles.css file. Make sure you include these directives or nothing will work. And that’s it as far as bare CSS!

@tailwind base;

@tailwind components;

@tailwind utilities;

Also, make sure you import this file into the front-end index file. I had an index.jsx file in my client/src directory that rendered the React app. This is a good place for the following line of code. Make sure your file path matches the location of your styles.css file.

import './styles/styles.css';

Dev Dependencies

One of the more difficult aspects of transitioning to Tailwind was configuring all of the additional dependencies. My project incorporated a React front-end and a Webpack build. A lot of the following information will probably be helpful for other types of configurations as well, but keep that in mind in case your stack differs from mine.

This command will install required dev dependencies:

npm i -D tailwindcss autoprefixer css-loader postcss-loader postcss-cli style-loader

Make sure to install the Tailwind CSS Intellisense extension. When you hover over an existing Tailwind utility, it will show you the equivalent CSS which is great for getting the hang of new utilities. When writing new utilities, it provides helpful auto-complete suggestions.

PostCSS Configuration

Tailwind makes use of PostCSS. All I needed was the following postcss.config.js in my root directory.

module.exports = {
  plugins: [
    require('tailwindcss'),
    require('autoprefixer'),
  ],
};

Then I added the following rule to my webpack.config.js file. Keep in mind, I trimmed out unrelated Webpack configuration details.

module.exports = {
  module: {
    rules: [
      {
        test: /\.css$/,
        use: [
          'style-loader',
          'css-loader',
          'postcss-loader',
        ],
      },
    ],
  },
};

Purging Unused Utilities for Production Build

It is absolutely necessary to purge any unused classes when you build for production. There are thousands of utilities provided by Tailwind which results in a huge build if they’re not purged.

Purging is handled in the tailwind.config.js file which should live in your project’s root directory. Any file included in the purge array will be searched for utilities. My tailwind.config.js looked like this on a recent react project:

module.exports = {
  purge: [
    './client/src/*.jsx',
    './client/src/**/*.jsx',
  ],
  theme: {},
  variants: {},
  plugins: [],
};

Any utilities that are found will not be purged. This means you can’t do anything goofy with the provided class names. Use whole class names only.

// don’t do this
<div className={‘text-’ + error ? ‘red’ : ‘green’ + ‘-600’}></div>

Conclusion

If you’re looking for a way to freshen up your web styling, give Tailwind a try! I found it to be very beautiful, intuitive, and quick once everything was configured properly. Hopefully this post will help you get up and running with Tailwind.

Regular Expressions in JavaScript

Will Preble — Sun, 31 May 2020 21:27:59 +0000

Instantiation

I find it strange that all of the JavaScript courses I’ve taken online and my current immersion program have skipped over regular expressions. I first encountered them in solution code for some beginner algorithm puzzles on Free Code Camp. Frankly, they looked like witchcraft. That’s because JavaScript borrows its regex syntax from Perl. Although the syntax can be strange at first, regular expressions are powerful tools for matching patterns in strings.

In JavaScript, Regular Expressions are built-in objects, e.g. Array, Date, Promise, and have their own prototypical methods. They can be instantiated with RegExp literal syntax or via a constructor.

const myFirstRegExp = /[abc]/g; // literal syntax
const mySecondRegExp = new RegExp(‘[abc]’, ‘g’); // constructor syntax
myFirstRegExp === mySecondRegExp; // true

They can also be inserted as arguments into common string methods such as replace or match.

const sentence = 'I walked my dog to the store. My dog is happy.';
console.log(sentence.replace(/dog/g, 'hippo'));
// logs => I walked my hippo to the store. My hippo is happy.

Whether you’re a JavaScript beginner or an experienced developer who’s been putting it off, now is the time to learn regular expressions.

Tools for Writing Regexes

Before we dive into the details, I want to introduce a couple of tools that I use every single time I need to build a regular expression.

The first is RegExPal. RegExPal provides a fabulous GUI for visualizing regexes and matches in sample text. It is very easy to write a regular expression that matches too often with false positives or one that misses a specific edge case. It can also be difficult to determine the order of operations of complicated regular expressions since the syntax is very compressed and characters can serve different purposes in different contexts. When hovering your cursor over characters in the regular expression you write, RegExPal will tell you exactly how that character is behaving in your regular expression.

Next is this cheat sheet at Debuggex. Even as I become more familiar with writing regexes, I always have a cheat sheet close at hand. It’s much more efficient than browsing the wealth of material in the MDN docs. I like this cheat sheet a little more than the one that comes with RegExPal. Just make sure you have the correct language selected! You will notice that Perl Compatible Regular Expressions (PCREs) don’t change much between languages, although Python adds a few extra features over the JavaScript set.

If you find yourself looking for a deeper explanation, don’t forget about the JavaScipt MDN docs. This is my default reference for any native JavaScript features and regexes are no exception.

Flags

The most common way to instantiate a regular expression is via the literal syntax. The entire expression is contained between a pair of single forward slashes. Flags can be tacked on after the ending slash. The two flags to know are global, g, and case insensitive, i. With the global flag, your regex will match every result. Without it, it will only match the first result. Obviously, the case insensitive flag allows your regex to match both upper and lower case if this is desirable.

const sentence = 'My dog is named Dog. He is friends with lots of dogs.';

const dogRegex1 = /dog/; // matches the first dog 
const dogRegex2 = /dog/g; // matches the first dog and the dog inside of dogs
const dogRegex3 = /dog/gi; // matches all three instances of dog

Groups and Ranges

If you want to match one of a group of possible characters, wrap the group of characters in square brackets. Ranges can be established with a hyphen between characters. Ranges are intuitive for letters of the same case and digits, i.e. a-z, A-Z, or 0-9.

Say you want to find all the individual numbers in a document. Both of the following regualar expressions are equivalent.

const allDigits1 = /[0123456789]/g;
const allDigits2 = /[0-9]/g;

Character Groups

But there’s an even more efficient way with special characters that represent character groups! For digits, these are represented by lowercase d. Special characters must be escaped with a preceding backslash. The following regex is equivalent to the previous two.

const allDigits3 = /\d/g;

If you wanted to match every character that is not a digit, you could use the special character D.

const nonDigits = /\D/g;

This is a common form with character groups. The inverse is often the capital version of the special character. Check out this table in the Debuggex cheat sheet I referenced above.

Quantifiers

What if you wanted to match a string of 16 digits such as a credit card? Quantifies have you covered. The most useful form is {n}, where n is the number of characters to match. The quantifier always refers to the character preceding it. Add a comma to match n or more characters. Add a second integer to match a quantity range.

const sixteenDigits = /\d{16}/;
const atLeastThreeDigits = /\d{3,}/;
const fiveToTenDigits = /\d{5,10}/;

Assertions

Say you only wanted to match strings that begin or end with a number. You will need an assertion to accomplish this. The ^ character will insist that a string begin with the character following it. The $ character will insist that a string ends with the character preceding it.

const beginWithALetter = /^[a-zA-Z]/;
const endWithAWhiteSpace = /\s$/;

Remember that this is the entire string, not the beginnings of each word! Look into the special characters for word boundaries if you want all words that begin with the letter s, for example.

Putting it All Together

Let's write a simplified version of a regular expression to identify a MasterCard number given the following conditions:

Starts with either 51, 52, 53, 54, or 55
Must be 16 characters in length

We will use an assertion to ensure the first number is 5. We will use a character group with a range to ensure the second digit is 1, 2, 3, 4, or 5. Then we use a special character to specify digits followed by a quantifier for the remainder. And finally we will add an assertion to ensure that the string ends with the 14 digits. But don't take my word for it, be sure to test it out in RegExPal!

const regexMasterCard = /^5[1-5]\d{14}$/;

Conclusion

In this blog, I introduced some useful tools for building your own custom, regular expressions in JavaScript. I recommend using RegExPal and the Debuggex cheat sheet. I covered instantiation syntax, flags, groups, ranges, character classes, special characters, and assertions. This will allow you to match most patterns in any length string. Once you have these down, be sure to look into capturing groups!

Thanks for reading!

Introduction to TypeScript

Will Preble — Mon, 25 May 2020 03:33:43 +0000

Why TypeScript?

When I decided to pursue a career as a computer programmer, there was an important decision to make. Which language should I learn first as my point of entry? JavaScript seemed like a logical choice. It is ubiquitous in web development. It’s versatile and easy to learn. I soon learned, it is also very quirky.

For one, JavaScript is dynamically typed. The type of a variable, e.g. number, string, object, is associated with its run-time value. In practice, this means that a variable can change type via reassignment or through another operation without throwing an error. This allows developers to code quickly without worrying about whether type is consistently maintained.

Unfortunately, this can lead to unpredictable bugs that are hard to track down without debugging line by line. In a small application, like animating an element on a web page, this trade-off of speed vs. care could be worthwhile. Historically, this was JavaScript’s domain.

However, as the JS community has continued to grow, JS applications have grown in scale and complexity. These type related bugs can cause major headaches.

TypeScript was developed by Microsoft in 2012 to grant the vast community of JS developers easy access to a statically typed language, that is more suitable for the complexity of modern JS applications.

Getting Started with TypeScript in VS Code

Before we get started, let’s install the necessary packages in node so we can experiment in VS Code. For our purposes of experimentation, the following two lines are enough. Run them in the terminal to install the necessary dependencies. If you don't have node and npm installed, make sure to do that first.

npm install -g typescript
npm install -g ts-node

This will allow us to compile our TS files into JS, and also test our TS files directly in the terminal.

Next let's make a file called type.ts. VS Code will automatically provide language support for TS files that end with the extension .ts.

Assigning Types

The first thing to know about TypeScript is that it is a superset of JavaScript, or JavaScript with extra features. This means that all existing JS syntax is valid in TS, so you can use any of your favorite libraries when coding in TS. Furthermore, TypeScript compiles into plain JavaScript. So when you run your code that you wrote in TS, you are running JS. This means that any code you write will run in any browser or node environment.

TypeScript enforces strict rules regarding type as you code. You can’t reassign a variable that should be an array into a string. Let's create some variables from the three main primitive types.

const make: string = 'honda';
const color: string = 'gold';
const year: number = 2006;
const isReliable: boolean = true;

It is good practice to assign a type when creating a variable but TypeScript can infer all of the types above if standard JavaScript syntax is used.

Let's create a car object with that information.

const myCar = { make, color, year, isReliable };

Next let's create a function to paint our car a new color. Notice that we have an opportunity to assign types to parameters in functions as well. If we chose not to assign a type in the function parameters, it will default to the 'any' type. Although this would technically work, we will be missing out on some powerful IDE features granted by TypeScript.

const paintCar = (car: object, color: string) => {
  car.color = color; // Property 'color' does not exist on type 'object'.
  return car;
}

Uh oh! We have encountered our first error. This is because TypeScript doesn't merely enforce type, but also the shape of complex datatypes like objects and arrays. In other words, the values of the keys or indices also have types associated with them. So even though the type of the car is an object, we will need to be a little more specific.

Let's create an interface!

interface Car {
  make: string;
  color: string;
  year: number;
  isReliable: boolean;
  soundSystem?: string;
}

An interface describes the type requirements of the properties of an object. In the example above, all the properties are required except for sound system. The ? denotes an optional parameter. Let's try our function again and log the result to the console.

const paintCar = (car: Car, color: string) => {
  car.color = color;
  return car;
}

console.log(paintCar(myCar, 'zebra'));

In the terminal, navigate to the directory containing your type.ts file and run the following command. This allows our TS file to be tested in the node environment similar to using the node command. Make sure you install ts-node using npm first.

ts-node type.ts
// logs { make: 'honda', color: 'zebra', year: 2006, isReliable: true }

A powerful benefit of using TypeScript is that your IDE knows at any given time what type and properties exist on your objects. Take our contrived example, which returns the car object after changing the color. This means that any function invocation can be chained with a property of the car object. Optional properties are shown with a question mark.

paintCar(myCar, 'zebra'). // IDE shows color, make, isReliable, soundSystem?, year as options

This is a wonderful time saver when working deep in a complicated project. You don't need to insert console logs everywhere to find out what the data structures are. Your IDE can simply tell you at any given time.

Compiling

Finally, once your TypeScript file has been written, simply run the following command to compile the file into JavaScript. type.js will appear in the same directory, ready to be implemented wherever JS is supported.

tsc type.ts

Conclusion

I've just scratched the surface of TypeScript, but honestly I can't wait to start implementing it in my projects. One of my greatest frustrations in web development is keeping track of complicated data structures deep inside of nested callbacks. TypeScript makes this a breeze. Any large scale JavaScript project would benefit tremendously from its type control features.

Implement A Debouncer in React

Will Preble — Mon, 18 May 2020 02:16:29 +0000

Before I realized I had started my journey towards a career in software development, I worked for an escape room designing and maintaining automation systems.

There was a puzzle that incorporated antique elevator buttons. In order to solve the puzzle, the buttons had to be pressed in a specific order. An Arduino microcontroller was listening to the electrical signals from the switches. When the buttons were pressed in the correct order, a secret door would open.

As always, there was a bug. With each press, the Arduino would detect a ripple of current and register multiple events even if the button was only pressed once. This made the puzzle impossible to solve.

The buttons needed to be debounced! Each ripple of current needed to be interpreted as a single event.

In JavaScript development, I’ve encountered analogous situations. Computers are capable of reacting to user input much quicker than what may be considered desirable. Expensive functions may be triggered too often. These issues can be solved with rate-limiting function decorators. In this post, I’ll explain why, when, and how to use debounce.

Rate-Limiting Function Decorators

A function decorator accepts an input function and returns an altered version of that same function. For example, the native JavaScript bind method, which returns a function bound to a specific context, is perhaps the most common function decorator used in JavaScript. Rate-limiting means reduces the frequency or total number of times that a given function can be called.

Debounce is a rate-limiting function decorator. Although many forms of it could be derived, I will be using the Lodash version in my React example below.

Lodash dot Debounce

_.debounce requires a function as the first parameter and a wait time in milliseconds as the second. An options object can be passed as a third argument.

_.debounce(func, wait, options);

By default, if no options are passed, _.debounce will return a function that when called will execute after the given wait period only if no other invocations of that same function have been made. If another invocation is made, then the wait time resets. See this wonderful visualization by David Corbacho.

He also wrote a fantastic article where he examining the differences between debounce and a similar function decorator, throttle.

This is known as the trailing edge implementation of debounce.

Another option is to call the function on the leading edge of a repetitive event. The terms leading and trailing edges are inherited from the application of debouncing an electrical signal like I discussed in the introduction.

If a function is invoked on the leading edge, then it will be invoked immediately. Any invocations made in the wait time afterwards will be ignored or debounced. To set this option in lodash, simply pass the object { leading: true, trailing: false } as the third argument. If both options are set to true, the function will be invoked on the trailing edge only if it is called more than once during the wait. This could be useful for implementing an event upon a double mouse click.

Debounce a Method in React

Recently, I was building a React project that mimicked YouTube using the YouTube Data API. I wanted to incorporate a search bar that would search automatically when a user stopped typing. Let’s debounce!

First I created the skeleton for my search bar component which will maintain the state of the search query in the input form.

class Search extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      searchQuery: '',
    };
  }
  render() {
  }
}

Next I built out my render method. I attached the synthetic event handler onChange to the input form and call a method to handle any changes made to the input form.

render() {
  return (
    <div className="search-bar form-inline" >
      <input className="form-control" type="text" onChange={this.handleChange} />
    </div>
  );
}

Then, I needed to define the handleChange method by adding it to my component class. This will set the state of the search query to the current value of the input form. Once the state is updated, it will call the delaySearch method.

handleChange(event) {
  this.setState({
    searchQuery: event.target.value,
  }, this.delaySearch);
}

Just below my handleChange method, I defined delaySearch which simply calls the function searchYoutube that I passed in as a prop. This function accepts the state of the search query and performs my AJAX request.

delaySearch() {
  this.props.searchYoutube(this.state.searchQuery);
}

Finally, I need to bind my methods inside the constructor of the Search component. Here is where I debounce the delaySearch method to call only once every second on the trailing edge. This allows the user to finish typing their search query before a search is made. Since I want the debounced function to invoke on the trailing edge, and this is the default option in Lodash, I don't need to provide an option.

this.delaySearch = _.debounce(this.delaySearch.bind(this), 1000);
this.handleChange = this.handleChange.bind(this);

tldr

Debounce is a useful, rate-limiting, function decorator. In the Lodash version of debounce, you have the option of invoking the debounced function on the leading or trailing edge. To debounce a method in React, simply set the method equal to a debounced version when binding your method in the constructor.

Intro to Test Driven Development

Will Preble — Mon, 11 May 2020 03:28:11 +0000

In a previous life before programming, I worked as an electrician. I liked electrical work. Still do. You’re either right or you’re wrong or so I thought when I was starting out.

To some extent this is true, a freshly wired light turns on or it doesn’t.

But often on projects in older homes, I discovered that repairing one problem could lead to surprising results elsewhere in the house. I would follow the building code and make my best judgments, but ultimately I was layering my work onto decisions that an electrician made decades ago. I could only see the wires coming in or out of the box I was working on.

The same issue exists in software development on a much greater scale. Dependencies can be interwoven in unexpected ways, features are deprecated over the years. Enter test driven development.

Red, Green, Refactor

If the essence of an existing project is successfully captured with tests, any new bug created in the process of adding a new feature or performing maintenance would appear as a failing test, represented in angry red font in a browser. A programmer should analyze the test to identify the issue, devise a plan, and write code with the single goal of flipping the test to green. During this phase, resist the urge to refactor freshly written code if it doesn't directly lead towards passing the test.

When the test is passing again, that is the time to refactor. Examine your work. What could be improved for performance or readability? Keep an eye on your tests as you refactor and repeat the process if necessary. Test driven development describes this style of programming that could also be called red, green, refactor.

Not Just for Education!

I first encountered tests in an educational environment where the tests were already written out for me. It was my job to pass them. Tests made sense in this context. They make sure a beginner stays on track and tackles a larger problem in small pieces. As I moved onto more advanced, open-ended problems, I learned that the pre-written tests often contained hints towards how the program should be written. Functions that should be called at specific times or the data type that should be returned by an unwritten method.

It took me a while to realize that the process of writing tests could benefit all levels of programming. I also didn’t realize that you would ever be writing tests for yourself.

There are huge advantages that come with carefully crafted tests. In fact, on any project, it should be the first thing you do! Testing provides a written record of the intended functionality of a project that can easily be viewed in one place. But even in a greenfield or ephemeral project, writing tests is easy enough and provides structure to keep you working towards deliverable goals.

Mocha and Chai

Let’s quickly discuss two technologies available for implementing TDD in JavaScript. Mocha is a JavaScript test framework that runs in node.js or the browser. I’ll show examples of how Mocha displays in the browser here. You can get started with the basic functions describe() and it(). “Describe” functions can be thought of as sections of your testing framework. A describe section takes a descriptive string as the first parameter and a callback function as the second. The callback function will contain any subsections, i.e. additional describe functions, and your unit tests.

“It” functions are your unit tests. Each it function should test a single aspect or component. Similar to “describe” functions, “it” functions take a string and a callback function. The string should be the name of the test. The callback function is usually anonymous and should run any necessary assertion statements. Mocha has many more features including hooks which are especially useful if you are testing features that work in parallel. Rather than repeating the code necessary to set up the parallel tasks, you can use a “beforeEach” hook to provide the same setup for each unit test.

Chai is a test assertion library that complements Mocha. Think of Chai as the code that invokes the tests. Think of Mocha as providing the box to hold the test and display the results. Chai expect() functions can be chained with a vast array of methods to test various qualities of code. They also come with language chains which are blank methods that make tests more readable.

Check out the following example that includes the features discussed above. The describe section will encapsulate any tests related to “boxyDancer”. Here I set up some initial variables and call in the chai assertion. Before each unit test, a new boxyDancer will be created. I’m also making use of the Sinon library to track if a method has been called. The expect statement is the last function called in the unit test. It will test its argument against the assertion at the end of the language chain. In this case it is testing if the value located at boxyDancer.$node.animate.called will resolve to true. The .to and .be methods are simply language chains that don’t affect the assertion.

Here is what the tests look like when hosted in Chrome. You can see that this section will relate to “boxyDancer”. The assertions within the it statement are also shown for reference. Any hooks or setup code in the describe section will be hidden.

And finally, here is the same test before it was passed.

A Recursive Descent: Recreating JSON.parse

Will Preble — Mon, 04 May 2020 03:55:30 +0000

My White Whale

Building an equivalent JSON.parse function has haunted me since I first encountered the problem alongside recreating JSON.strigify. With stringify, you're given a value which could be almost any data type, and it's your job to turn that value into a string of a specific format. That format, of course, is JSON. Using little more than typeof and isArray, you can sort values by data type, apply a format with string interpolation, deploy recursion for the nested structures, and soon enough you'll be returning a certified JSON string.

Starting JSON.parse felt like driving the wrong way down a one-way street. typeof won’t help you here. It will be our job to take the unwieldy beast that is a stringified JSON object and parse the appropriate JavaScript data contained within:

JSON Grammar & Mutual Recursion

The data contained within a JSON object can accommodate most data types in Javascript including objects, arrays, strings, numbers, true, false, and our favorite oddball, null. Functions and undefined data are excluded from the JSON format. We can rely on the fact that these data types will always be written in a predictable way because JSON follows a specific grammar.

Looking at the grammar of an array, courtesy of json.org, we will see that it starts and ends with a square bracket and contains either ‘ws’ (white space) or ‘elements’. What are elements? Well, it could be a single ‘element’ or an ‘element’ separated from other ‘elements’ with a comma. By definition, this is semantic but illustrates an important point. Elements are separated from other elements with a comma. If there is a single element inside of an array, no comma. But wait, what is an element??

An element is a value with white space before and after. Since white space can be represented in JavaScript as an empty string, we can effectively ignore it’s presence here. So what is a value? A value can be an object, array, string… starting to sound familiar? That’s because an array allows nesting of other complex data. See the visual below representing the grammar of an array, also from json.org.

Once we are able to parse our elements, we will need to call our primary parseJSON function to parse the values of the elements themselves. Here is how I structured my primary value parsing function:

I'll cover regular expressions another time. The important thing to notice here is that simple data types can be returned as is, but arrays, objects, strings, and numbers all need to call another function. This act of “descending” into functions that will eventually call the function we started in is called “mutual recursion”. Hence the challenge of this exercise, coding a recursive descent parser.

The dirty work of parsing key-value pairs or escape characters in strings is done deep inside the parseObject or parseString functions, respectively. Here’s my code for parsing an array, all the way down to the bottom:

Helper Functions

I’m sure there is an elegant solution that traverses one character at a time through the entire JSON string, tracking the state of how many nested arrays or objects you’re inside of for a given index. This could operate at something close to a linear time complexity. I chose a different path, instead relying on helper functions to determine the state of a given index whenever I needed it. This adds some computing time but shortened the time it took me to code to a minimum viable product.

Here is a simple one that I named insideString:

When do we need to know if we’re inside of a string? Let’s go back to our array example. Since elements inside of an array are separated by commas, we could parse our elements if we could locate the commas within our array. But what if it was an array of strings that contained commas? We only care about the commas separating the elements. The insideString helper function helps us locate only the commas we care about, i.e. those that are not within a string.

Thanks for reading! I found this project to be very challenging, and it is not for the faint of heart. If you decide to embark on this journey, beware the escape characters!