DEV Community: John Stewart

Unit Tests and Snapshots are Fake News

John Stewart — Sun, 08 Sep 2019 15:24:08 +0000

Alright, I've been told many times that I'm wrong on this but I can't help but feel the same way every time I write or update one of these things.

When writing a unit test I end up stubbing out an entirely fake environment for a given function to run in. This fake environment yields the results I expect every time because I mocked it to do so. So the test passes or fails as expected.

Same is true for snapshots. When I update a React component's render method. Of course, the snapshots will need to be updated. With this one I can at least see that maybe if I update something not clearly referenced in the render method that it might update a snapshot inadvertently.

To me though these "tests" seem fake and not a true measure of if an app is well tested.

Again, I know I'm wrong but I'd love to hear from others on this because I honestly just don't see the value of these things.

5 Programming Patterns I Like

John Stewart — Mon, 20 May 2019 13:04:29 +0000

In this post I get into some patterns I try to use while programming. These patterns are observations I've made about myself recently while working as well as a couple I stole from coworkers over the years.

These patterns are in no particular order just a simple collection.

1. Early exits

function transformData(rawData) {
  // check if no data
  if (!rawData) {
    return [];
  }

  // check for specific case
  if (rawData.length == 1) {
    return [];
  }

  // actual function code goes here
  return rawData.map((item) => item);
}

I call this pattern 'early exits' but some also refer to this as 'the Bouncer Pattern' or 'guard clauses'. Naming aside, this pattern takes the approach of checking for invalid use cases first and returning out from that function otherwise it continues onto the expected use case of the function and executes.

For me, this approach has some positives that I really like:

encourages thinking around invalid/edge cases and how those cases should be handled
avoids accidental and unnecessary processing of code against an unexpected use case
mentally allows me to process each use case much more clearly
once adopted, you can quickly glance at functions and understand the flow and execution which typically follows a top down approach going from - invalid cases -> small cases -> expected case

More info:

The bouncer pattern by Rik Schennink

2. Switch to object literal

// Switch
let createType = null;
switch (contentType) {
  case "post":
    createType = () => console.log("creating a post...");
    break;
  case "video":
    createType = () => console.log("creating a video...");
    break;
  default:
    createType = () => console.log('unrecognized content type');
}

createType();

// Object literal
const contentTypes = {
  post: () => console.log("creating a post..."),
  video: () => console.log("creatinga  video..."),
  default: () => console.log('unrecognized content type')
};

const createType = contentTypes[contentType] || contentTypes['default'];
createType();

Next up is removing the switch. I often make mistakes when writing each case and very often forget a break. This causes all kinds of fun issues. The switch statement doesn't add a whole lot of value when I'm writing code. It seems to get in the way.

I prefer using an object literal instead, here's why:

don't have to worry about case or break
easier to read and quickly understand what's happening
object literals are easy enough to write
less code

More info:

3. One loop two arrays

const exampleValues = [2, 15, 8, 23, 1, 32];
const [truthyValues, falseyValues] = exampleValues.reduce((arrays, exampleValue) => {
  if (exampleValue > 10) {
    arrays[0].push(exampleValue);
    return arrays;
  }

  arrays[1].push(exampleValue);
  return arrays;
}, [[], []]);

This pattern is nothing really special and I should have realized it sooner but I found myself filtering a collection of items to get all items that matched a certain condition, then doing that again for a different condition. That meant looping over an array twice but I could have just done it once.

Turns out this has a name (bifurcate) and I stole it from 30secondsofcode.org. If you've never checked out that site I suggest going there. So much good information and useful code.

I know reduce can be kind of daunting and not very clear what is going on but if you can get comfortable with it, you can really leverage it to build any data structure you need while looping over a collection. They really should have called it builder instead of reduce.

More info:

30secondsofcode.org

4. No 'foo' variables

// bad
const foo = y && z;

// good
const isPostEnabled = isPost && postDateValid;

This one may seem kind of obvious but I'm sure we all have seen code that does this. Take the time and do your best to name something appropriately.

This is especially important for working professionals or people who are in a position where they are educating others. Variable naming should be used to help explain and give context to what is going on within the code.

Someone should be able to read your code and loosely begin to understand what is trying to be solved.

More info:

The art of naming variables by Richard Tan

5. Nested ternaries

let result = null;
if (conditionA) {
  if (conditionB) {
    result = "A & B";
  } else {
    result = "A";
  }
} else {
  result = "Not A";
}

const result = !conditionA
  ? "Not A"
  : conditionB
  ? "A & B"
  : "A";

I'll admit, in the beginning the idea of nesting ternaries was off-putting. It just seemed like a clever way to write conditionals. Then I started writing business logic and found myself with nested if else clauses and some pretty questionable conditional logic.

I think if and else are much easier to read as they are actual words but when these become nested I start to really have a hard time following what is going on and mentally keeping track of everything.

I started deferring to ternaries and nested ternaries and I found I was able to quickly understand at a glance what was happening.

I think this pattern is really up to you and your team and your preferences. I have worked in codebases that do both well and can see both sides to this, but personally nested ternaries are really growing on me.

More info:

Nested Ternaries are Great by Eric Elliot

Differential Serving

John Stewart — Wed, 01 May 2019 16:18:56 +0000

Recently I was listening to the Shop Talk Show and heard about differential serving. The idea behind differential serving is that you serve different bundles to different browsers.

The benefit here is instead of compiling down to the lowest supported set of features which is probably IE11 for most of us, we can serve an IE11 bundle and a modern bundle for the evergreen browsers.

That seems like a pretty good win. But how well does this work?

Example

To do differential serving we actually don't need much code. Here is small example:

  <div id="root-es5"></div>
  <div id="root-esm"></div>

  <!-- ES5 and below JS -->
  <script nomodule src="/es5.js"></script>
  <!-- ES6 and above JS -->
  <script type="module" src="/esm.js"></script>

The key parts are the the two script tags. <script nomodule> is used by older browsers to parse and execute that specific bundle and <script type="module"> is used by newer browsers. The idea is that we leave the work up to the browsers to determine which bundle to serve.

Generate Two Bundles

To generate two bundles you will need to update your build config to output two bundles, one targeting older browsers such as IE11 and one targeting newer browsers that support the <script type="module">. To do this you can use @babel/preset-env and specify the browser targets.

Example webpack config:

module.exports = [
  {
    ...
    output: {
      path: path.resolve(__dirname, 'dist'),
      filename: '[name].legacy.js'
    },
    module: {
      rules: [
        {
          test: /\.js$/,
          exclude: /node_modules/,
          use: {
            loader: 'babel-loader',
            options: {
              presets: [
                ['@babel/preset-env',
                {
                    targets: {
                        browsers: [
                          /**
                           *  Browser List: https://bit.ly/2FvLWtW
                           *  `defaults` setting gives us IE11 and others at ~86% coverage
                           */
                          'defaults'
                        ]
                    },
                    useBuiltIns: 'usage',
                    modules: false,
                    corejs: 2
                }]
              ]
            }
          }
        }
      ]
    }
    ...
  },
  {
    ...
    output: {
      path: path.resolve(__dirname, 'dist'),
      filename: '[name].esm.js'
    },
    module: {
      rules: [
        {
          test: /\.js$/,
          exclude: /node_modules/,
          use: {
            loader: 'babel-loader',
            options: {
              presets: [
                ['@babel/preset-env',
                {
                    targets: {
                        browsers: [
                          /**
                           *  Browser List: https://bit.ly/2Yjs58M
                           */
                          'Edge >= 16',
                          'Firefox >= 60',
                          'Chrome >= 61',
                          'Safari >= 11',
                          'Opera >= 48'
                        ]
                    },
                    useBuiltIns: 'usage',
                    modules: false,
                    corejs: 2
                }]
              ]
            }
          }
        }
      ]
    },
    ...
  }
];

One thing worth noting is that HTML Webpack Plugin currently doesn't have built in support for generating the different script tag outputs. Luckily there are some plugins that help solve this:

Does it work?

One question you have may have been wondering is, does this really work? The answer is yes but there are a few issues. On Safari 10.1, the browser downloads both bundles and executes both bundles.

Edge and IE seem to have issues with downloading both bundles as well as Firefox 59.

That said, I still think this is a good idea to implement if you can.

Alternative Approach

Another more controlled approach is using user agent detection to find out what browser is making the request and serving the correct bundle based off of that. There is a package called browserslist-useragent that will parse the user agent string and match it against a browser list that you might already have in your .browserslistrc file.

const express = require('express');
const { matchesUA } = require('browserslist-useragent');
const exphbs  = require('express-handlebars');

...

app.use((req, res, next) => {
  try {
    const ESM_BROWSERS = [
      'Edge >= 16',
      'Firefox >= 60',
      'Chrome >= 61',
      'Safari >= 11',
      'Opera >= 48'
    ];

    const isModuleCompatible = matchesUA(req.headers['user-agent'], { browsers: ESM_BROWSERS, allowHigherVersions: true });

    res.locals.isModuleCompatible = isModuleCompatible;
  } catch (error) {
    console.error(error);
    res.locals.isModuleCompatible = false;
  }
  next();
});

app.get('/', (req, res) => {
  res.render('home', { isModuleCompatible: res.locals.isModuleCompatible });
});

This approach gives you a little more control over what is getting sent to the user.

Summary

In the end, differential serving is a great performance win without having to rewrite any of your existing client code. There are some tradeoffs as to which approach is best but that's for you to decide.

Here is a list of some helpful links if you are interested in learning more:

Faster Renders with React.memo

John Stewart — Mon, 15 Apr 2019 14:42:34 +0000

This post I'm getting into React.memo and how it can be used to speed up a React app. I'll start from an example app that contains some unoptimized React code. Using the React Devtools Profiler my goal is to demonstrate how you could go about fine tuning a React app to be be as performant as it can be. Using this approach will allow you to step through each part of your React app and increase performance where you see fit.

Example App

This app is a big list of items that belong to subgroups and those subgroups belong to parent groups which are labeled as A, B, C, etc. There are 15 items in each subgroup and 2 subgroups per parent group bring the grand total of items to 780. That's a lot.

Functionality wise, all we want to do is make selections within this list of items. On click of an item that item should be highlighted in red.

Baseline App Performance

Time to get a baseline for how the app is currently performing. Using the React Devtools Profiler we can do some measuring.

Above is the profiler that shows where the app is spending time. Each one of the blocks is a React component. The colors range from blue to orange. Blue means fast, orange means slow.

Above you can also see that every component is doing something whenever we make an update to a single component. We just want to update the single component we are acting on or the component path to that individual component.

Lastly, on the right you see a metric called the Render duration. The first item we tried to update took 55.5ms for React to commit that change to the DOM.

React.memo

In the example React is processing all of the components and selecting a single item within the list which means that in this case, 779 items are staying the exact same. React exposes React.memo for this kind of use case.

import React from "react";

function Item({ item, selectItem, group, subgroup }) {
  return (
    <div
      className={`item${item.selected ? " item--selected" : ""}`}
      onClick={() => selectItem(group, subgroup, item.id)}
    >
      <div className="item-img">
        <img src="https://placehold.it/64x64" />
      </div>
      <span>{item.name}</span>
    </div>
  );
}

const MemoItem = React.memo(Item, (prevProps, nextProps) => {
  if (prevProps.item.selected === nextProps.item.selected) {
    return true;
  }
  return false;
});

export default MemoItem;

Above is the Item component. At the bottom it's been updated to export a memoized version of the Item component. The function signature looks like this React.memo(MyReactComponent, compareFn(prevProps, nextProps)). Within the compare function you tell React if the component is the same(true) or not(false).

Time to measure.

What changed? The render duration is now at 14.7ms 👍. Diving further into the components you can see all the Item components are now grey except for the one where the change was made. That's closer to the goal!

Unfortunately, there is still extra processing being done that is not necessary. Each one of the ItemGroup components are still doing work when only one of them has been updated. Back to React.memo.

import React from "react";
import Item from "./Item";

function ItemGroup({ items, selectItem, group }) {
  return (
    <div className="item-group">
      <div className="item-group--a">
        {items.SUB_GROUPA.items.map(item => (
          <Item
            group={group}
            subgroup={"SUB_GROUPA"}
            key={`item-${item.id}`}
            item={item}
            selectItem={selectItem}
          />
        ))}
      </div>
      <div className="item-group--b">
        {items.SUB_GROUPB.items.map(item => (
          <Item
            group={group}
            subgroup={"SUB_GROUPB"}
            key={`item-${item.id}`}
            item={item}
            selectItem={selectItem}
          />
        ))}
      </div>
    </div>
  );
}

const MemoItemGroup = React.memo(ItemGroup, (prevProps, nextProps) => {
  if (prevProps.updatedAt === nextProps.updatedAt) {
    return true;
  }
  return false;
});

export default MemoItemGroup;

Above contains the ItemGroup component which processes each group of items. The default export is now the memoized version of ItemGroup which contains a comparision between the updatedAt timestamp variables.

With this last change the render duration is now 4.3ms! 🚀

Thoughts

Any sort of comparison can be done against the props. I try to use booleans and numbers(timestamp) as they seem simpler to process versus comparing objects.

Another important part in all of this is correctly using keys on collections of items. I found out the hard way how important this is. So make sure those are set properly.

Lastly, the React Devtools Profiler is a great tool for getting a better understanding of your React app. Often we are forced to hit deadlines and cut performance corners. If you can, take a few days and try and deeply understand the parts of your React app to try and figure out where to create fast paths for rendering.

Links

Originally posted on my blog at johnstewart.io.

How I Debug Node

John Stewart — Wed, 12 Sep 2018 15:20:28 +0000

Time to talk about debugging a bit. This post will be quick and be mainly focused on how I do things when it comes to debugging Node apps in Visual Studio Code.

Visual Studio Code Launch Configuration

VS Code has a nice debugger in the left column. Click on the debugger then you will see an option cog you can click that will ask what kind of configuration you want.

Once you select Node.js, it will bring up a configuration that has a couple properties.

The one we directly care about the last property, program. Here it states that it will launch a program called index.js within our current workspace. So let's write some Node and see what this does.

const avengers = ['Iron Man', 'Captain America', 'Thor', 'Captain Marvel'];

for (let i = 0; i < avengers.length; i++) {
  const theHero = avengers[i];
  console.log(theHero);
}

Here is some code we can use as our basis for index.js. After you save that code to the index.js file in your workspace. You can drop a breakpoint on line 5 by clicking in the rail left of the line number.

Then if you go back to your debugger and click the play button it will run the program and pause the program execution on that line.

In the left hand side you can see the variable with it's value in the current scope, theHero: "Iron Man". There is a bunch of other scopes you can drill into and inspect the variables and that specific execution time.

This is a basic example but shows how nice and valuable a good debugger is. There are a variety of built in useful options that you can explore within VS Code. Check out the Node.js Debugging Config Common Scenarios section on the VS Code docs for more info.

Visual Studio Code Attach Configuration

The most common way that I use VS Code debugger is by attaching the debugger to a currently running Node process and setting breakpoints within that process. I use this often when debugging some Node Express apps.

Below is a basic express app that I'll use as the base for the examples here. Replace the code in the index.js file and don't forget to install express via npm.

const express = require('express');
const app = express();

const PORT = process.env.PORT || 5000;

app.get('/', (req, res) => {
  const data = {
    hello: 'world'
  };

  res.json(data);
});

app.listen(PORT, () => console.log(`Up and running ${PORT}`));

Next, open up .vscode/launch.json. You will then see the big blue Add Configuration button. Once you click that you will be prompted with a bunch of configurations to pick from. In this case we are picking the first Node.js Attach option.

That config will then be added to your array of configs for you to use in the debugger.

Next, run node with the --inspect flag.

Then you will see Node start up the script telling you the Node debugger is listening on port 9229 plus a Chrome dev tools URL then your app output. That port is the same port as the one your attach configuration is looking for.

Next, go to your index.js script and drop a breakpoint within the app.get call before the response is sent.

Open up your VS Code debugger and press play and you should see some controls come up at the top of VS Code. Now we need to navigate to that route to trigger that code and the debugger, open up Chrome and hit localhost:5000. This should kick you back to the VS Code debugger where you can view the variables and information in scope of the request.

That's it!

Summary

console.log is the tried and true but I think spending an hour or more trying to understand the VS Code debugger or any debug tools around will make solving problems a little bit easier. So I recommend you check out some of the information below!

If you liked this article then please show some ❤️. If you didn’t then lets talk about it 😃.

Originally posted on my blog at johnstewart.io.

First Impressions: React Context API

John Stewart — Mon, 14 May 2018 13:01:24 +0000

Photo by Alex Knight on Unsplash

React came out with the new Context API about a month ago. The past few days I've been playing around with it and have developed some understanding of how it works. It introduces some new use cases to consider and helps with some old ones as well. This post I get into my thoughts on it and how ultimately I think our developer lives are better with the new Context API.

New API

The new Context API is made up of these three parts:

Using the above three pieces we can really do a lot now. Let's take a quick look at how they can be used.

import React from 'react';
import { render } from 'react-dom';

const theme = {
  buttonColor: 'blue'
};

const ThemeContext = React.createContext(theme);

const AppButton = () => (
  <ThemeContext.Consumer>
    {({ buttonColor }) => (
      <button style={{ background: buttonColor }}>App Button</button>
    )}
  </ThemeContext.Consumer>
);

const Container = () => (
  <div>
    <AppButton />
  </div>
);

const App = () => (
  <div>
    <h1>My App</h1>
    <ThemeContext.Provider value={theme}>
      <Container />
    </ThemeContext.Provider>
  </div>
);

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

Above is a basic example of creating some context and then using it. Line 8 I create some context for the app theme. Creating the context gives me two new React components { Provider, Consumer }. On line 27 I use the Provider to allow for child components to have access to the theme context we created. Then on line 11 within my AppButton component I use the Consumer part of the context to gain access to the theme information. This example is small but illustrates the basic setup behind using the new Context API.

Familiarity

If you've ever setup a React Redux project then that Provider part of the API should look pretty familiar. I'm not sure of how the internals work specifically in either code base but it's clear that the intent is the same in React and Redux.

Where they differ is how both want children components to consume state. Redux is more opinionated on how state is updated through reducers and actions but React allows you to read and update state how you see fit.

Taking this a step further Redux exposes a higher order component to connect to the store but in React they expose the state through a child function. Both achieve the same goal but again Redux is a bit more prescriptive.

The broad strokes of this API should be somewhat familiar to you if you have had to deal with or setup a state management library before.

Roll Your Own State Management

With the Context API you can manage small application state much easier now. If you have a small single page application and it's just you or a small team working on it then I think using the Context API should be enough to manage all your app state.

That being said, you should come up with a pattern that you understand or pull concepts from things such as Redux or other state libs and try them out at your scale.

Ultimately it's about what makes you comfortable and works for the app. If Redux is your bread and butter then go for it. If you are just starting with React and find yourself wondering how to pass state over here and down there then check out the Context API for now.

If at some point you feel it's not enough, google "React state management libraries" and try a few.

I like Redux

I've been using Redux for awhile now and I like how it works. I like Redux so much that I've used it for projects that don't use React at all. Redux is a great state management library and does exactly what I need it to do. The only thing I didn't like with Redux was the excess files I would create for actions and reducers. I solved this by using Ducks. It's a nice pattern for Redux and my preferred approach. Check it out!

The Context API will make me reach for Redux a lot less now. In a team environment or on a project of medium to large size I'll still use Redux. At the end of the day you need to do what makes you and your team comfortable and ultimately makes your lives easier.

Final Thoughts

All in all I like the new Context API and think it provides a ton of value. For those just getting started with React it should be able to answer the global app state question much faster then passing props way down and learning a state management library.

Check out some links below to learn more about the Context API:

If you liked this article then please show some ❤️. If you didn’t then lets talk about it 😃.

Originally posted on my blog at johnstewart.io.