DEV Community: Seb

Difference between arrow functions and regular functions

Seb — Fri, 25 Sep 2020 14:00:00 +0000

The difference between regular functions and arrow functions

ES6 and subsequent ECMAScript releases have featured the arrow function, amongst other things. The arrow function seems to be one of the features that causes much confusion and takes some time to learn.

There are 3 key differences between an arrow function and a regular (named) function.

First, we'll go over what each type of function is, then I'll quickly show you the differences. We're only looking at the differences in terms of how they might affect you day-to-day. For a more in-depth look, Mozilla has a good reference article on arrow functions.

A regular (named) function in javascript looks like this;

function formatName(firstName, lastName) {  
  return firstName + " " + lastName;  
}

And an arrow function might look like this;

const formatName = (firstName, lastName) => {  
  return firstName + " " + lastName;  
}

The differences

1. "this"

An arrow function does not have it's own this keyword. Instead, this is bound to the parent this. In the case where the arrow function is executed in the global context (it has no parent function/scope), this will be bound to the global object (window in the browser or globalThis in node).

When is this useful?

This is particularly helpful when you have some function whose this you might need to access from within an inner function. For example consider this pattern. (It's a bit contrived, but it shows how useful an arrow function can be when you need to access parent this).

// Let's create a controller to manage the value of some counter  
// when a button is pressed  
function ButtonController() {  
  // initialise the count value  
  // here "this" is the ButtonController instance  
  this.countValue = 0;  

  // create an arrow function to increase out counter  
  // within the arrow function "this" refers  
  // to the same "this" as above  
  const increaseCount = () => {  
    this.countValue += 1;  
  }  

  // As an example, this would be how we would have to do  
  // the same thing, without arrow functions  

  // we capture the parent "this" in some variable  
  var \_this = this;  
  function decreaseCount() {  
    // \_this is now available in the scope of decreaseCount  
    \_this.countValue -= 1;  
  }  

  return {  
    increaseCount,  
    decreaseCount,  
    get countValue() {  
      return this.countValue;  
    }  
  }  
}  

const controllerInstance = SomeController();  

// And we could bind this method to the on click event of a button  
controllerInstance.increaseCount();

In the above example, increaseCount is an arrow function, and can easily access this from the ButtonController instance.

In contrast, decreaseCount is a named function, and to access this from the ButtonController instance, we have to save it to a variable (_this) and then reference it inside.

If you've done much with jQuery back in the day, this pattern might look familiar to you (capturing parent this for reuse inside a closure).

2. Implicit return

One of (in my opinion) the best things about an arrow function is implicit returns.

What is an implicit return? Take the example at the top of the post. If we have a function that is really only a one-liner, it'd be nice not to have to write out the curly brackets and return statement, right?

Well, arrow functions allow us to do that!

// Instead of writing this function like this:  
const formatName = (firstName, lastName) => {  
  return firstName + " " + lastName;  
}  

//We can make use of implicit returns instead  
const formatName = (firstName, lastName) => firstName + " " + lastName;

If your arrow function is written without the curly brackets, it will implicitly (by default) return whatever comes next.

When is this useful?

Implicit returns from arrow functions becomes especially useful when working with array methods or callbacks.

Let's see some examples;

//Let's make an array of fruit.  
const fruitArray = ["Apple", "Banana", "Orange"];  

//Now we want an array of fruit but all lower case  
//Here we will use Array.map, and make use of the implicit return  
//from the arrow function that we pass as the callback  
const fruitArrayLowerCase = fruitArray.map(fruit=>fruit.toLowerCase());  

//The same thing without an arrow function would look like  
const fruitArrayLowerCasae = fruitArray.map(function(fruit) {  
  return fruit.toLowerCase();  
});  


//Imagine we need to chain a couple together:  
const fruitArrayFiltered = fruitArray  
  .map(fruit=>fruit.toLowerCase())  
  .filter(fruit=>fruit.charAt(0) === "a");

Quick note:

If you want to return an object literal from your arrow function with an implicit return, you'll need to wrap it in brackets (parentheses). This is because passing a "curly" bracket to the arrow function looks like a function body, not a return value.

Example;

// The following function returns an object literal with  
// the two arguments as properties  
const myRegularFuncThatReturnsAnObject = function(a,b) {  
  return {a,b};  
}  

// To do the same with an arrow function, we need to wrap  
// the return value in brackets "(" ")"  
const myImplicitReturnFunc = (a,b) => ({a,b});

3. Always anonymous

The third major difference between arrow functions and regular functions is that arrow functions are always anonymous. They cannot be named. Whereas a regular function created with the function keyword can be named or anonymous (function myFunc() {... } vs function() { ... }), arrow functions are always anonymous.

Most of the time, this isn't a problem, as function naming is often only important when being passed to an event listener addEventListener('click', myFunc) so it can be removed again or similar.

The one main way that this impacts me is usually to do with hoisting. If you're not sure how hoisting works, the quick version is this;

Named functions are hoisted to the top of the current scope.

What does this mean? It means you can call a named function in your script higher up that where it is declared (within the same scope).

For example

// In this first example, we're using a named function, \*before\*  
// it's declared. This is because hoisting allows us to call  
// any named function within the same scope, despite the fact  
// that the function isn't declared until the end of the scope  
function initMyComponent1() {  

  // This works  
  this.addEventListener('click', handleComponentClick);  

  // handleComponentClick is a named function and thus  
  // it is hoisted to the top of initMyComponent1 scope  
  function handleComponentClick(e) {  
    // Do something  
  }  

}  

// In this second example, we're trying to use an anonymous  
// function \*before\* it's been declared  
// This will throw an error!  
function initMyComponent2() {  

  // THIS WILL FAIL!  
  this.addEventListener('click', handleComponentClick);  

  const handleComponentClick = (e) => {  
    // Do something  
  }  
}

This largely only affects how you structure your file, but handy to know!

Limitations

Just like anything, arrow functions are good in moderation & there are some cases where you don't or can't use them!

1. Use as methods or constructors

Arrow functions shouldn't be used as methods. That's not to say you can't use them as methods, but they're not best suited. This example from Mozilla demonstrates why quite nicely. Essentially, as arrow functions don't have their own this, they can't access any other properties from a parent object.

Arrow functions can't be used as constructors, and will throw an error if you try.

2. call, apply & bind

Because arrow functions use this from the scope that they were created in, using call, apply & bind with arrow functions can lead to some unexpected results, again I'm going to defer to Mozilla on that one because, well, it's boring.

When to use an arrow function?

When should you use an arrow function? Good question!

An easy rule of thumb; if you don't need access to the local this within your closure, go with an arrow function.

For example, simple utility functions, pure functions etc, an arrow function will do the trick.

A great use for arrow functions is with setTimeout, setInterval, and addEventListener. These methods will execute regular function callback with the global or window scope. Which can often lead to strange behaviours when the callback is executed.

// This won't work, as the addEventListener callback is  
// executed on the global (window) scope  
// obj.count is always 1  
const obj = {  
  count: 1,  
  addEventListener: function(el) {  
    el.addEventListener('click', function() {  
      this.count ++;  
    });  
  }  
}  

// This will work as expected, the arrow function is created  
// with the obj scope, and obj will be incremented  
const obj = {  
  count: 1,  
  addEventListener: function(el) {  
    el.addEventListener('click', ()=>{  
      this.count ++;  
    });  
  }  
}

When to use a regular, or a regular named function

When should you use a regular (or a named) function? There are a few cases where you definitely want to use a regular function;

You need the function's this or super access
An object constructor
An object method*
If you want to use yield within the function body
You want to use call, apply, or bind

*You can use either type of function for an object method, but it will depend on your use case.

Add Woocommerce Support in Sage 9

Seb — Wed, 23 Sep 2020 14:00:00 +0000

Sage 9 from Roots is an awesome way to build modern, fast Wordpress themes with a great developer experience. Unfortunately, early in the Sage 9 development life supporting Woocommerce & Woocommerce template overrides was a little tricky. This has lead to a bit of old and redundant information floating around.

Fortunately for us, adding support for Woocommerce to Sage 9 is really easy, using a package from Roots themselves and a couple of simple steps.

Add sage-woocommerce from Roots

First up, we need to add a package from Roots that enables Woocommerce template files in the Blade templating engine.

This is as simple as one composer require... line.

The repo for the package is located at https://github.com/roots/sage-woocommerce, and please check out the install instructions there if anything is unclear. Plus, we'll need some code from the repo in the next step.

First, change directory into your theme folder;

(Replace the path with your correct path)

cd .../my\_wordpress\_site/wp-content/themes/mytheme

Then require the package

composer require roots/sage-woocommerce

That's the big part of the job done!

If you're interested in how this actually works under the hood to make Woocommerce & Sage 9 work together, check out src/woocommerce.php in the repo.

Add the necessary template files

Due to some quirks in the way that blade templates work in Sage 9, it's necessary to override two Woocommerce template files to get everything to work.

Fortunately, the kind Roots people have provided the necessary files. Find them in the repo above at (github:roots/sage-woocommerce) under examples/resources/views/woocommerce.

The two files we need are

Create the woocommerce folder in your theme

First, create the folder in which we will place Woocommerce template overrides, within your theme.

mytheme/resources/views/woocommerce

Add the two Woocommerce overrides

Finally, download the two template files above and place them within this folder.

You should have

mytheme/resources/views/woocommerce/single-product.blade.php
mytheme/resources/views/woocommerce/archive-product.blade.php

Add woocommerce support to your theme

The last required step to make Woocommerce work with Sage 9 is to add Woocommerce support to your theme.

Open up mytheme/app/setup.php

In the hooked function for after_setup_theme, add theme support for woocommerce by calling add_theme_support. (This will usually be near the theme support for Soil).

<?php  

// app/setup.php  

add\_action('after\_setup\_theme', function() {  

  // ...  

  /\*\*  
   \* Add Woocommerce Support   
   \*/  
  add\_theme\_support('woocommerce', array(  
    'thumbnail\_image\_width' => 415,  
  ));  

  // ...  

});

You now have Woocommerce & Sage 9 playing nicely!

Congratulations.

Extras

As you know if you read some of my posts, I like to give extra "pro tips" at the end of an article.

When using Sage 9 and Woocommerce, it's a good idea and you probably want to remove Woocommerce's default stylesheets. By default these look a bit tacky, and who wants like 4 extra stylesheets to be downloaded in their fast, lean, awesome theme, right?

To remove the Woocommerce styles is actually really easy!

Just add the following filter wherever suits you best (probably app/filters.php)

<?php  

// Disable woocommerce stylesheets  
add\_filter('woocommerce\_enqueue\_styles', '\_\_return\_empty\_array');

And you're done!

Happy building with Woocommerce and Sage 9!

Gatsby generate related posts at build time

Seb — Wed, 13 May 2020 14:00:00 +0000

Gatsby is exceptional. There are no two ways about it. But a static site can pose some challenges.

One challenge devs building Gatsby sites come across is: how can I automatically generate "related" posts at build time?

Until the Gatsby team gives us a way to make multiple queries to build one page (main page query and then sub queries), we'll have to find workarounds.

One solution I've seen is to query all post data and then filter through them at runtime. It should be fairly obvious that this might not be a winning strategy. What happens when you've got 10,000 posts? 20,000?

I wanted a solution for NimbleWebDeveloper where I could have some pseudo related posts generated automatically, at build time.

This method should work regardless of where you're pulling content from. In our case the posts are coming from Sanity.io.

createSchemaCustomization

A little while back, the Gatsby team introduced the Schema Customization API. The schema customization API is quite helpful for a number of things; we can set default field values (really useful when working with datasets where missing data is not defined), and extend existing fields.

We're going to use it to add an 'artificial' field to our posts which uses the Gatsby runQuery API to look for related posts using any and all of our existing data sources, and do it at build time.

Don't believe me? Read on!

What you're going to need

To use this example, you're going to need a Gatsby site, with some posts from some source (where they're coming from shouldn't matter), and some way of linking posts to each other. I've gone with categories but you might use tags, categories and tags, a text match of the titles, it's up to you.

Gatsby Node APIs

The Schema Customization API is part of the Gatsby Node APIs. So if you haven't already got a gatsby-node.js file in your project, go ahead and create one in your Gatsby project root.

// gatsby-node.js  

//Hook into the createSchemaCustomization API  
//This hook runs after all our nodes have been created  
exports.createSchemaCustomization = ({ actions, schema }) => {  
  //The createTypes action allows us to create custom types  
  //and modify existing ones  
  const { createTypes } = actions  

  //...  
  // Create our schema customizations  
  //...  
}

Associate posts

You'll need some way to associate posts with other posts. In my case I have categories, and each post has many categories, so my data looks something like this;

{  
  "posts":[  
    {  
      "id":"...",  
      "slug":"...",  
      "title":"...",  
      "categories":[  
        {  
          "id":"<CategoryID>"  
        },  
        {  
          "id":"<CategoryID>"  
        },  
        {  
          "id":"<CategoryID>"  
        }  
      ]  
    }  
  ]  
}

How you do this is up to you, just have some way you can query posts (in GraphQL) by a category, tag or some other identifier.

(To find out how your data can be queried, use the GraphiQL tool which by default is located at http://localhost:8000/__graphql)

Generate related posts

Finally, we can create a new field on our post type which contains our related posts.

// gatsby-node.js  

//Hook into the createSchemaCustomization API  
//This hook runs after all our nodes have been created  
exports.createSchemaCustomization = ({ actions, schema }) => {  
  //The createTypes action allows us to create custom types  
  //and modify existing ones  
  const { createTypes } = actions  

  // Create our schema customizations  
  const typeDefs = [  
    // Replace "sanity\_post" with your \_typename of your post type  
    "type sanity\_post implements Node { related: [sanity\_post] }",  
    schema.buildObjectType({  
      name: "sanity\_post",  
      fields: {  
        related: {  
          type: "[sanity\_post]",  
          //The resolve field is called when your page query looks for related posts  
          //Here we can query our data for posts we deem 'related'  
          //Exactly how you do this is up to you  
          //I'm querying purely by category  
          //But you could pull every single post and do a text match if you really wanted  
          //(note that might slow down your build time a bit)  
          //You could even query an external API if you needed  
          resolve: async (source, args, context, info) => {  
            //source is the current (post) object  
            //context provides some methods to interact with the data store  

            //Map a simple array of category IDs from our source object  
            //In my data each category in the array is an object with a \_id field  
            //We're just flattening that to an array of those \_id values  
            //E.g. categories = ["1234", "4567", "4534"]  
            const categories = source.categories.map((c) => c.\_id)  

            //If this post has no categories, return an empty array  
            if (!categories.length) return []  

            //Query the data store for posts in our target categories  
            const posts = await context.nodeModel.runQuery({  
              query: {  
                filter: {  
                  categories: { elemMatch: { \_id: { in: categories } } },  
                },  
              },  
              //Change this to match the data type of your posts  
              //This will vary depending on how you source content  
              type: "sanity\_post",  
            })  

            //Gatsby gets unhappy if we return "null" here  
            //So check the result and either return an array of posts,  
            //or an empty array  
            return posts && posts.length ? posts : []  
          },  
        },  
      },  
    }),  
  ]  

  createTypes(typeDefs)  
}

Use it!

If you restart your development instance (gatsby develop) and navigate to your GraphiQL tool (usually http://localhost:8000/__graphql) you should see your posts now have an additional field related available!

We didn't put any limits on the related field, but you might want to limit it in the resolver to only a couple of results. Or you can do that in your page query.

Now that you can access the data, you can use it to build your page. Like so;

(This query is specifically for data sourced from Sanity, your query will be a little different depending on your data)

// templates/post.js  

export const query = graphql`  
  query SanityBlogPost($slug: String) {  
    post: sanityPost(slug: { eq: $slug }) {  
      slug  
      title  
      #... other fields  
      related: {  
        slug  
        title  
        #... other fields  
      }  
    }  
  }  
`

PHP Splice into an associative array

Seb — Wed, 06 May 2020 22:16:36 +0000

For those of use with maybe more experience in nicer (don't @ me 😎🙉) languages like Javascript, splicing into an associative array in PHP may seem a little challenging.

In javascript, we could simply call array.splice and specify our index and offset and it would work. Javascript doesn't care that it's an associative array (object) or and indexed array, it just works.

PHP is a bit more complicated. Indexed arrays and associative arrays are fundamentally different.

It's ok though there's a pretty easy way to do it. And I've made a little helper function to wrap it up;

<?php  

/\*\*  
 \* array\_splice\_assoc  
 \* Splice an associative array  
 \* Removes the elements designated by offset & length and replaces them  
 \* with the elements of replacement array  
 \* @param $input array  
 \* @param $key string  
 \* @param $length int  
 \* @param $replacement array  
 \*/  
function array\_splice\_assoc($input, $key, $length, $replacement=array()) {  
  // Find the index to insert/replace at  
  $index = array\_search($key, array\_keys($input));  

  // How do we handle the key not existing in the array?  
  // Up to you. In my case I'm going to return the original array  
  // But you might want to return false, throw an error etc  

  if($index === false) {  
    return $input;  
  }  

  // We're going to create 3 slices of the array  
  // the 'before' slice, before our $key  
  // the $replacement slice  
  // the 'after' slice, after our $key  

  //This could easily be done all in 1 line, but I've split it out for readability  

  $before\_slice = array\_slice($input, 0, $index);  
  $after\_slice = array\_slice($input, $index+$length);  

  return array\_merge($before\_slice, $replacement, $after\_slice);  
}

How it works

I've modelled this helper function on the built in array_splice method, with the key difference being the second parameter which is now a string key rather than a numeric index.

With the given string key, we can then search the keys of the associative array for the index corresponding to this key.

If we don't find the index in the array, simply return the original input array. (This part is sort of a choose-your-own-adventure. You might want to return false or an error instead.)

With the index in hand, we can now effectively slice up our associative array into 3 pieces;

The "before" slice, before our key's index
The replacement slice
The "after" slice, after our key's index, plus the length

Finally, all that remains is to merge the three elements together, in order, using array_merge.

And that's it!

Note that in the built in array_splice method, the $length and $replacement parameters are optional. This could be replicated, but let's be honest it's not really valuable.

How to convert a React Class Component to a Function Component

Seb — Fri, 17 Apr 2020 01:53:26 +0000

Since the React 16.8 update which added hooks to function components, you might have seen function components replacing class components everywhere.

Partly this is just because developers suffer from 'shiny-object-syndrome', and hooks are new and shiny, but there are also good reasons for the shift as well.

Function components are far less verbose, and require less boilerplate. They're (in my opinion) a bit more flexible with hooks and custom hooks, and they are (usually) a bit more performant.

What's the difference between class components and function components?

Well to put it simply, one is a class, and the other is... a function!

Take these examples below. The first one is a class component, the second one is a function component. They both do exactly the same thing.

// Example class component  

class MyComponent extends React.Component {  

  render() {  
    return <p>Hello, {this.props.name}    
  }  

}  


//Example function component  

function MyComponent(props) {  
  return <p>Hello, {props.name}</p>  
}

Both components take a prop (name) and render Hello, **{name}**. It's an extremely simple example but already we can see some of the differences.

The class component needs to extend the React Component class, and must specify a render method. Whereas the function component is simply a function, and the render method is simply the return value of the function.

Why convert a class component to a function component

If you've got a slightly older codebase, and you'd like to refactor some of your components into function components, then you're in the right place!

Beware! Not all class components can be converted to functions! There are still some cases where you need to use a class component. But 99% of the time you'll be fine with a function component.

When can't you use a function component?

There are some use cases where a function component simply won't work. We'll quickly discuss a couple, and there may be more! Consider yourself warned.

If you need a constructor

If you really, really need a constructor, you're gonna have a bad time. A constructor runs once and only exactly once , before the first render of the component. Currently, I haven't found a hook that will replace this functionality (know of one? Let me know!)

Most of the time all that's being done in the constructor of a class component anyway is setting up state, and binding event listeners. Both these things are handled differently in function components so we're good.

If you need to extend a component

In Javascript, classes can extend other classes, thus inheriting the parent's prototype. In fact, if you're creating a class component, you have to extend the base component from React. This is more or less not possible with function components, so I wouldn't bother trying

Higher order components

You can make a HOC (higher order component) with a function, however it can often be a bit easier to use a class. Up to you, just be warned.

Side-effects of combined state updates

this.setState is no longer available in a function component. Instead we use the useState hook, which returns a state variable, and an updater function. If you have some peculiar pattern where you're updating a couple of state variables at once, and need to run a specific side effect, you might find this difficult (not impossible) with a function component.

As an example, if you do this

class MyComponent extends React.Component {  

  onSomeEventHandler(newName) {  

    this.setState({  
      counter: this.state.counter+1,  
      name: newName  
    }, () => {  
      console.log('Counter AND name have been updated!')  
    })  

  }  

}

You're going to struggle to exactly replicate that functionality with a function component.

Quick steps to convert to a function component

1. Change the class to a function

Change

class MyComponent extends React.Component {  
  //...  
}

function MyComponent(props) {  
  //...  
}

2. Remove the render method

Remove the render method, but keep everything after & including the return. Make this the last statement in your function.

From

//...  
  render() {  

    return (<p>Hello, World</p>);  

  }  
//...

function MyComponent(props) {  
  //...  

  return (<p>Hello, World</p>);  

} // end of function

3. Convert all methods to functions

Class methods won't work inside a function, so lets convert them all to functions (closures).

From

class MyComponent extends React.Component {  

  onClickHandler(e) {  
    // ...  
  }  

}  

jsx  
function MyComponent {  

  const onClickHandler = (e) => {  
    //...  
  }  

}

4. Remove references to this

The this variable in your function isn't going to be super useful any more. Remove the references to it throughout your render and functions.

Change

clas MyComponent(props) extends React.Component {  

  //...  

  mySpecialFunction() {  
    console.log('you clicked the button!')  
  }  

  onClickHandler(e) {  
    this.mySpecialFunction();  
  }  


  render() {  
    return (  
      <div>  
        <p>Hello, {this.props.name}</p>  
        <button onClick={this.onClickHandler}>Click me!</button>  
      </div>  
    );  
  }  

}

function MyComponent(props) {  

  //...  

  const mySpecialFunction = () => {  
    console.log('you clicked the button!')  
  }  

  const onClickHandler = (e) => {  
    mySpecialFunction();  
  }  

  return (  
    <div>  
      <p>Hello, {props.name}</p>  
      <button onClick={onClickHandler}>Click me!</button>  
    </div>  
  );  

}

5. Remove constructor

Simply removing the constructor is a little tricky, so I'l break it down further.

1. useState

Instead of

constructor(props) {  
  super(props);  
  //Set initial state  
  this.state = {  
    counter: 0,  
    name: ""  
  }  
}

Use the useState hook

function MyComponent(props) {  

  const [counter,setCounter] = useState(0);  
  const [name,setName] = useState("");  

}

2. Remove event handler bindings

We don't need to bind event handlers any more with function components. So if you were doing this;

constructor(props) {  
  this.onClickHandler = this.onClickHandler.bind(this);  
}

You can simply remove these lines. (What a gross, overly verbose syntax anyway).

6. Replace this.setState

this.setState obviously doesn't exist any more in our function component. Instead we need to replace each of our setState calls with the relevant state variable setter.

Replace this;

class MyComponent extends React.Component {  

  onClickHandler(e) {  
    this.setState({count: this.state.count+1})  
  }  

}

With this;

function MyComonent {  

  const [count, setCount] = useState(0)  

  const onClickHandler = e => {  

    setCount(count+1);  

  }  

}

7. useEffect for state update side effects

Remember how this.setState could accept a callback that would run after the state was updated? Well our useState updater function does no such thing. Instead we have to use the useEffect hook. It doesn't work exactly the same though! useEffect will trigger whenever and of it's dependencies are changed.

If you do this;

this.setState({counter: this.state.counter+1}, () => {  
  console.log('Counter was updated!')  
})

Do this instead

const [counter, setCounter] = useState(0)  

useEffect(() => {  
  console.log('counter changed!')  
}, [counter])

8. Replace lifecycle methods with hooks

ComponentDidMount

Instead of using the componentDidMount method, use the useEffect hook with an empty dependency array.

useEffect(()=>{  
  console.log('component mounted!')  
},[]) //notice the empty array here

ComponentWillUnmount

Instead of using the componentWillUnmount method to do cleanup before a component is removed from the React tree, return a function from the useEffect hook with an empty dependency array;

useEffect(() => {  
  console.log('component mounted')  

  // return a function to execute at unmount  
  return () => {  
    console.log('component will unmount')  
  }  
}, []) // notice the empty array

ComponentDidUpdate

If you pass nothing as the second argument to useEffect, it will trigger whenever a component is updated. So instead of using componentDidUpdate, use;

useEffect(() => {  

  console.log('component updated!')  

}) // notice, no second argument

Example components converted to functions

Example 1 - simple state

Replace this

import React, {Component} from 'react';  

class MyComponent extends Component {  

  constructor(props) {  

    super(props);  

    this.state = {  
      count: props.count || 0  
    }  

    this.onClickHandler = this.onClickHandler.bind(this);  

  }  

  onClickHandler(e) {  

    this.setState({  
      count: this.state.count + 1;  
    })  

  }  

  render() {  
    return (  
      <div>Count : {this.state.count}</p>  
          <p>Count isis: {this.state.count}</p>  
        <button onClick={onClickHandler}>Increase Count</button>  
      </div>  
    );  
  }  
}

With this

import, React {useState} from 'react';  

function MyComponent(props) {  

  const [count, setCount] = useState(props.count || 0);  

  const onClickHandler = () => {  
    setCount(count + 1);  
  }  

  return (  
    <div>  
      <p>Count is: {count}</p>  
      <button onClick={onClickHandler}>Increase count</button>  
    </div>  
  );  

}

Example 2 - useEffect

Replace this

import React, {Component} from 'react';  

class MyComponent extends Component {  

  constructor(props) {  

    super(props);  

    this.state = {  
      data: null,  
      isLoading: false,  
      error: null  
    }  

  }  

  async loadAsyncData() {  

    this.setState({isLoading: true, error: null});  

    try {  
      const resp = await fetch('https://...').then(r=>r.json());  
      this.setState({isLoading: false, data: resp});  
    } catch(e) {  
      this.setState({isLoading: false, error: e});  
    }  

  }  

  componentDidMount() {  

    loadAsyncData();  

  }  

  render() {  

    if(this.state.isLoading) return (<p>Loading...</p>);  
    if(this.state.error) return (<p>Something went wrong</p>);  
    if(this.state.data) return (<p>The data is: {data}</p>);  
    return (<p>No data yet</p>);  

  }  
}

With this

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

function MyComponent() {  

  const [data, setData] = useState();  
  const [isLoading, setIsLoading] = useState(false);  
  const [error, setError] = useState();  

  const loadAsyncData = async () => {  

    setIsLoading(true);  
    setError(null);  

    try {  
      const resp = await fetch('https://...').then(r=>r.json());  
      setData(resp);  
      setIsLoading(false);  
    } catch(e) {  
      setError(e);  
      setIsLoading(false);  
    }  

  }  

  useEffect(() => {  

    loadAsyncData();  

  }, []);  


  if(this.state.isLoading) return (<p>Loading...</p>);  
  if(this.state.error) return (<p>Something went wrong</p>);  
  if(this.state.data) return (<p>The data is: {data}</p>);  
  return (<p>No data yet</p>);  

}

Custom React Hooks Make Asynchronous Data Fetching Easy (er)

Seb — Sat, 04 Apr 2020 13:00:00 +0000

When you're building a cool app with React, you will often eventually have the need to fetch remote or asynchronous data. Maybe you need to grab some data from an API to display posts, or get search result data for a search query. Whatever your use case, fetching remote data in React can sometimes get a little tricky.

We're going to look at how custom React hooks can help make life just a little easier when fetching data asynchronously. We'll take a look at three ways you might fetch data in your React component.

What do we need to know to fetch data?

If you're loading foreground data (i.e. it's not in the background, and it matters to the user) then we need to know a couple of things. Bare minimum we'd like;

the loaded data (if it exists)
whether the data is loading or not
and whether there was an error loading the data

To manage this, we need 3 different state variables (yes I know you could put them all in one state object): the data, the loading state, and the error, plus the logic to set them all correctly based on particular actions.

For example, on load start, we need to set loading to true, error to null, and fire the request. When the request returns we need to set loading to false, and depending on whether it was successful or not, set the data or the error. Potentially we might want a 'reset' function to reset the state to default or idle.

A simple way of fetching data

Let's quickly recap a method of fetching data in a React component that you've probably seen or used before. The issues with this method become clear pretty quickly.

Consider the code example below (or check out the codepen underneath).

// A sample component to fetch data from an async source  
// Note that the 'fetchFn' isn't specified, but assume it  
// returns a promise  

// this component just shows a list of people,  
// its not necessary, just part of the example  
const DisplayPeople = ({ people }) => {  
  return (  
    <div className="people">  
      {people.map((person, index) => (  
        <div className="person" key={index}>  
          {person.name}  
        </div>  
      ))}  
    </div>  
  );  
};  


// Here's our component that uses async data  
const Component1 = props => {  
  const [data, setData] = useState();  
  const [isLoading, setIsLoading] = useState(false);  
  const [error, setError] = useState(false);  

  const fetchData = async () => {  
    setIsLoading(true);  
    setError(null);  

    try {  
      const resp = await fetchFn(shouldFail);  
      setData(resp);  
      setIsLoading(false);  
    } catch (e) {  
      setError(e);  
      setIsLoading(false);  
    }  
  };  

  return (  
    <div>  
    {/\* If not isLoading, show a button to load the data  
    // otherwise show a loading state \*/ }  
      {!isLoading ? (  
        <div>  
          <button onClick={() => fetchData()}>Load data</button>  
        </div>  
      ) : (  
        "Loading..."  
      )}  

      {/\* if not isLoading and there is an error state,  
      display the error \*/ }  
      {!isLoading && error ? (  
        <div>  
          <p>Oh no something went wrong!</p>  
        </div>  
      ) : null}  
      {/\* If we have data, show it \*/}  
      {data ? <DisplayPeople people={data.results} /> : null}  
      {/\* if there's no data and we're not loading, show a message \*/ }  
      {!data && !isLoading ? <div>No data yet</div> : null}  
    </div>  
  );  
};

This component loads data from some asynchronous source when the button is clicked.

When the button is clicked, the following actions need to happen;

set the error state to null (in case there was a previous error)
set the loading state to true (so we know it's loading)
fire the data fetching function and wait for a response
set the loading state to false on a response
store the error or data response state

And then in our render function, we have a few messy if s to check (yes I've used ternary operators here, but you could have a separate function with ifs or a switch).

So what's wrong with this?

Nothing is wrong with this. It works fine, it fetches data and shows a response. But see how we need to manage three separate state variables? Imagine you need to make two API calls in your component. Or one call that depends on a another. Suddenly you've got at least 6 state variables (unless you can find a way to reuse them?)

A custom hook to fetch data

We can somewhat address these problems in a slightly better way. We can abstract the logic required to make this work into a custom hook.

How exactly you'd go about this probably depends on your app, and how you want to use it, but I'm going to show you a fairly generic way that can be used to help simplify your component.

First we're going to create a custom hook, then we're going to modify the component to use it. I'm going to show you the code first (in case you're just here for the ol' copy paste) then talk about it.

The custom hook; I like to call him 'useAsyncData'

import { useState, useEffect } from "react";  

//Our custom hook 'useAsyncData'  

// Options:  
// fetchFn (required): the function to execute to get data  
// loadOnMount (opt): load the data on component mount  
// clearDataOnLoad (opt): clear old data on new load regardless of success state  
const useAsyncData = ({  
  loadOnMount = false,  
  clearDataOnLoad = false,  
  fetchFn = null,  
} = {}) => {  
  // Our data fetching state variables  
  const [data, setData] = useState();  
  const [error, setError] = useState();  
  const [isLoading, setIsLoading] = useState(false);  

  // A function to handle all the data fetching logic  
  const loadData = async (event) => {  
    setIsLoading(true);  
    setError();  
    if (clearDataOnLoad === true) setData();  

    try {  
      const resp = await fetchFn(event);  
      setData(resp);  
      setIsLoading(false);  
    } catch (e) {  
      setError(e);  
      setIsLoading(false);  
    }  
  };  

  // 'onMount'  
  // maybe load the data if required  
  useEffect(() => {  
    if (loadOnMount && fetchFn !== null) loadData();  
  }, []);  

  // Return the state and the load function to the component  
  return { data, isLoading, error, loadData };  
};  
export default useAsyncData;

And the component, refactored to use the custom hook

//Component using custom hook  
const Component2 = (props) => {  
  const { data, isLoading, error, loadData } = useAsyncData({  
    fetchFn: (event) => fetchFn(event),  
  });  

  return (  
    <div>  
      {!isLoading ? (  
        <div>  
          <button onClick={() => loadData()}>Load the data (success)</button>  
          <button onClick={() => loadData(true)}>Load the data (error)</button>  
        </div>  
      ) : (  
        "Loading..."  
      )}  
      {!isLoading && error ? (  
        <div>  
          <p>Oh no something went wrong!</p>  
        </div>  
      ) : null}  
      {data ? <DisplayPeople people={data.results} /> : null}  
      {!data && !isLoading ? <div>No data yet</div> : null}  
    </div>  
  );  
};

Or if you'd like to see it in action, check the codepen here:

So what's happening here?

We've created a custom hook, which accepts a function (fetchFn) as a parameter (it also accepts some other useful parameters, but they're not essential). This function should actually do the data fetching and return a promise which resolves with the data, or rejects with an error on failure.

We've then put all the state variable stuff, pretty much exactly the same as the first example, inside the hook.

Then we created a function (loadData) which can accept some arbitrary data (which it will pass to the fetcnFn - just in case you need it). loadData then does all the state logic we previously had in our component (setIsLoading, setError etc). loadData also calls fetchFn to actually get the data.

Finally, we removed the fetchData function from our component, and instead of setting up the three state variables, we simply use the hook instead;

const { data, isLoading, error, loadData } = useAsyncData({  
    fetchFn: (event) => fetchFn(event),  
  });

Does it make our lives easier?

It does a little bit. It's not perfect. It means we don't have to do all the logic for those three state variables every time we need some data. We still have to call the hook for every API call, but it's better. If you've got a slightly complex data fetching scenario you could compose this custom hook into another custom hook. Sky's the limit!

Pro tip: use state machines

As our friendly neighbourhood state machine enthusiast (@davidkpiano) would say; "state machines".

I'm not going to go into depth explaining state machines here as it's outside the scope. If you want a bit of background on state machines, try this video with David himself, and Jason Lengstorf, or this article on CSS tricks(React specific).

Essentially, a (finite) state machine state machine has a number of discrete (or specific) states that it can be in. This can significantly simplify our logic. Take our example above. We have three state variables (not to be confused with our machine's states) that combined, essentially make up our application state. Our application can be idle (nothing has happened yet), loading (we're waiting for the data), success (we got some data), or failure (there was an error getting the data).

Using three separate variables, we have to do a bit of if-checking every time we need to know the state of the application (as you can see in the render method with all the ternary operators).

If we used a state machine instead, we'd have one thing to check: the state (e.g. 'idle', 'loading', 'success', 'error').

Another cool thing with state machines is that we can specify which states the machine can transition to from certain states, and what actions should run in between. Essentially it's predictable.

A state machine for async data fetching

I'm going to show you how you can use a state machine for async. data fetching. This is based heavily on the documentation in the xstate/react docs so definitely check that out.

For this example we're using xstate and @xstate/react so you'll need to install those as dependencies. You could write your own state machine implementation and react hook for it, but why reinvent the wheel? And this is a really good wheel.

$ yarn add xstate @xstate/react

The xstate library provides the state machine implementation, and @xstate/react provides the custom react hook to bind it to react.

Now we need to set up the state machine.

// fetchMachine.js  

import { Machine } from "xstate";  

// The context is where we will store things like  
// the state's data (for our API data) or the error  
const context = {  
  data: undefined  
};  

// This is our state machine  
// here we can define our states  
// along with what each state should do  
// upon receiving a particular action  
export const fetchMachine = Machine({  
  id: "fetch",  
  initial: "idle",  
  context,  
  states: {  
    idle: {  
      on: { FETCH: "loading" }  
    },  
    loading: {  
      entry: ["load"],  
      on: {  
        RESOLVE: {  
          target: "success",  
          actions: (context, event) => {  
            context.data = { ...event.data };  
          }  
        },  
        REJECT: {  
          target: "failure",  
          actions: (context, event) => {  
            context.error = { ...event.error };  
          }  
        }  
      }  
    },  
    success: {  
      on: {  
        RESET: {  
          target: "idle",  
          actions: \_context => {  
            \_context = context;  
          }  
        }  
      }  
    },  
    failure: {  
      on: {  
        RESET: {  
          target: "idle",  
          actions: \_context => {  
            \_context = context;  
          }  
        }  
      }  
    }  
  }  
});

Our state machine has some context, or data that it can store, and a set of states, along with which states it should transition to upon certain actions.

For example, our initial state is idle. No data yet. From our states declaration, we can see that if it's idle and receives the FETCH command, it should transition to loading.

We've got four states in total (idle, loading, success, failure), and I've added a 'reset' action so we can get rid of our data and go back to idle if we want.

Finally, we need to import the custom hook from @xstate/react in our component

import { useMachine } from "@xstate/react";

And use the hook in our component. This replaces our previous hook call. The load function is our loadData function and should 'send' a command back to the machine.

const [state, send] = useMachine(fetchMachine, {  
  actions: {  
    load: async (context, event) => {  
      const { shouldFail = false } = event;  
      try {  
        const resp = await fetchFn(shouldFail);  
        send({ type: "RESOLVE", data: resp });  
      } catch (e) {  
        send({ type: "REJECT", error: e });  
      }  
    },  
  },  
});

Finally we need to modify our render to use the machine state and context.

return (  
  <div>  
    {state.value === `idle` ? (  
      <div>  
        <button onClick={() => send("FETCH")}>Load the data (success)</button>  
        <button onClick={() => send("FETCH", { shouldFail: true })}>  
          Load the data (error)  
        </button>  
      </div>  
    ) : null}  
    {state.value === `loading` ? (  
      <div>  
        <p>Loading...</p>  
      </div>  
    ) : null}  
    {state.value === `success` ? (  
      <DisplayPeople people={state.context.data.results} />  
    ) : null}  
    {state.value === "failure" ? <div>Something went wrong!</div> : null}  
    {state.value !== "idle" && state.name !== "loading" ? (  
      <div>  
        <button onClick={() => send("RESET")}>Reset</button>  
      </div>  
    ) : null}  
  </div>  
);

And if you assembled it right (ish) it should look something like this (mileage may vary):

import { useMachine } from "@xstate/react";  
import { Machine } from "xstate";  

const context = {  
  data: undefined  
};  

export const fetchMachine = Machine({  
  id: "fetch",  
  initial: "idle",  
  context,  
  states: {  
    idle: {  
      on: { FETCH: "loading" }  
    },  
    loading: {  
      entry: ["load"],  
      on: {  
        RESOLVE: {  
          target: "success",  
          actions: (context, event) => {  
            context.data = { ...event.data };  
          }  
        },  
        REJECT: {  
          target: "failure",  
          actions: (context, event) => {  
            context.error = { ...event.error };  
          }  
        }  
      }  
    },  
    success: {  
      on: {  
        RESET: {  
          target: "idle",  
          actions: \_context => {  
            \_context = context;  
          }  
        }  
      }  
    },  
    failure: {  
      on: {  
        RESET: {  
          target: "idle",  
          actions: \_context => {  
            \_context = context;  
          }  
        }  
      }  
    }  
  }  
});  




const Component3 = () => {  
  const [state, send] = useMachine(fetchMachine, {  
    actions: {  
      load: async (context, event) => {  
        const { shouldFail = false } = event;  
        try {  
          const resp = await fetchFn(shouldFail);  
          send({ type: "RESOLVE", data: resp });  
        } catch (e) {  
          send({ type: "REJECT", error: e });  
        }  
      },  
    },  
  });  

  return (  
    <div>  
      {state.value === `idle` ? (  
        <div>  
          <button onClick={() => send("FETCH")}>Load the data (success)</button>  
          <button onClick={() => send("FETCH", { shouldFail: true })}>  
            Load the data (error)  
          </button>  
        </div>  
      ) : null}  
      {state.value === `loading` ? (  
        <div>  
          <p>Loading...</p>  
        </div>  
      ) : null}  
      {state.value === `success` ? (  
        <DisplayPeople people={state.context.data.results} />  
      ) : null}  
      {state.value === "failure" ? <div>Something went wrong!</div> : null}  
      {state.value !== "idle" && state.name !== "loading" ? (  
        <div>  
          <button onClick={() => send("RESET")}>Reset</button>  
        </div>  
      ) : null}  
    </div>  
  );  
};

Introduction to Custom React Hooks

Seb — Thu, 26 Mar 2020 13:00:00 +0000

How to write custom React hooks

If you've been around the the React world lately, you'll no doubt have noticed or used hooks. Hooks were introduced into React in 16.8 and were kinda a big deal.

React hooks gave us the ability to have state in function components, reduce the need for render props, and just generally make DX and life better.

As always, the React docs are a good place to start on this, so I recommend checking them out too.

Custom hooks in React are a way to reuse functionality (particularly functionality involving stateful logic) between components. You could just use a function to share between components, but then you don't get all the goodness of being able to access component lifecycle events and state. React hooks let you 'hook' (see, it's in the name) into things like component lifecycle (mount, unmount, etc), state, and other hooks.

So what is a custom hook, and how is it different to just a function? Well, a custom hook is just a function that uses other hooks. These might be other custom hooks, or React's basic hooks (useState, useEffect, etc). If you don't use any hooks, you've just got a function, not a hook.

The convention for naming hooks is to prefix your function with "use" (as in "useState", "useEffect" etc). For example if I were to create a custom hook to use the scroll distance down the page, I might name it "useScrollDistance". This is by no means a rule, and your hook will still work if you name it "myCoolHook", but it's a useful convention allows others to easily recognise your function as a hook.

Custom hook example

To help explain how custom hooks work, I'm going to show you a quick example of hook that you might even use in a real app (in fact it's in the codebase of one of mine). We'll make a hook that let's us keep track of the scroll distance down a page.

Quick react hook recap

First, we'll just take a quick recap of how react hooks work; we'll use useState and useEffect as examples.

If we have a simple component, which needs some state, we can use useState to keep track of it like this;

import React, {useState} from 'react'  

const myComponent = () => {  

  //This is our hook call to useState  
  // useState will return an array [stateValue, stateSetter]  
  // useState can also take the initial state as an argument (0)  
  const [counterValue, setCounterValue] = useState(0);  

  const incrementCounter = () => {  
    setCounterValue(counterValue+1);  
  }  

  return (<div>  
    <p>Counter Value: {counterValue}</p>  
    <div>  
      <button onClick={incrementCounter}>Increment Counter</button>  
    </div>  
  </div>);  
}

Here we have a simple component which calls useState , with the argument 0. This returns an array containing the state variable, and a function to update that state variable. The argument 0 is the initial value we would like to store in the state variable.

Ok, lets say we'd like to know when the counterValue has changed, and trigger some action, a side-effect. We can do that with the useEffect hook. useEffect will subscribe to changes in the variable you specify.

import React, {useState, useEffect} from 'react'  

const myComponent = () => {  

  //This is our hook call to useState  
  // useState will return an array [stateValue, stateSetter]  
  // useState can also take the initial state as an argument (0)  
  const [counterValue, setCounterValue] = useState(0);  

  const incrementCounter = () => {  
    setCounterValue(counterValue+1);  
  }  

  // Using the useEffect hook  
  // The first argument is the callback to trigger  
  // when the value changes  
  // The second argument is the variable we'd like to track  
  useEffect(() => {  
    console.log(`The new counter value is: ${counterValue}`)  
  }, [counterValue]);  

  return (  
    <div>  
      <p>Counter Value: {counterValue}</p>  
      <div>  
        <button onClick={incrementCounter}>Increment Counter</button>  
      </div>  
    </div>  
  );  
}

Now we've modified the component to log the value of the counter every time it changes. This isn't a particularly useful real-world scenario, but hopefully it demonstrates how the hook works.

We added a call to useEffect and passed it a callback to run every time the variable we're interested in changes. In the second argument, we passed in an array of the variables we'd like to keep track of.

A really simple custom hook

Using the example above, let's say we wanted to reuse this functionality (logging a state variable) in multiple places. I can't see why, but bear with me.

What we can do is compose a custom hook from our basic useState and useEffect hooks and make it reusable.

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


//This is our custom hook  
//it abstracts the logic & state of our counter  
const useCounterValue = (initialValue=0) => {  

  // Set up the state, same as before  
  const [counterValue, setCounterValue] = useState(initialValue);  

  // Create our count increment function  
  const incrementCounter = () => {  
    setCounterValue(counterValue+1);  
  }  

  // Watch for changes in the value  
  useEffect(() => {  
    console.log(`The new counter value is ${counterValue}`);  
  }, [counterValue])  

  // Return the state variable and our  
  // increment function  
  return [counterValue, incrementCounter];  
}  

const myComponent = () => {  
  // Use our custom hook  
  const [counterValue, incrementCounter] = useCounterValue(0);  

  return (  
    <div>  
      <p>Counter Value: {counterValue}</p>  
      <div>  
        <button onClick={incrementCounter}>Increment Counter</button>  
      </div>  
    </div>  
  );  
}

Here we created a custom hook useCounterValue which does exactly the same thing as our previous component, but now it's reusable. We could add this code into multiple components and consume it anywhere .

( BIG note: the state won't be shared simultaneously. The state is specific to the component you're using the hook in!)

I know this example is a bit contrived, but hopefully it demonstrates some of the power and simplicity of custom hooks!

A real example

Ok, now we're going to make a real custom React hook, one that would actually be useful!

We'll make a custom hook called useScrollDistance which will tell us how far down the page the user has scrolled. Examples of use cases for this might include; "polyfilling" position: sticky, infinite loaders, animation triggers etc. You could even adapt this to know how far a different scrollable element has been scrolled (think; fullpage style transitions etc).

I think I've wasted enough of your time already, so let's just do it. Here's our custom hook;

// useScrollDistance.js  

import {useState, useEffect} from 'react';  

const useScrollDistance = () => {  
  //Set up a state variable and  
  // store the initial value of window.scrollY  
  const [scrollDistance, setScrollDistance] = useState(window.scrollY);  

  //Set up a handler to update our state variable  
  //on scroll events  
  const onScrollHandler = () => {  
    setScrollDistance(window.scrollY);  
  }  

  //call useEffect to listen to component mount & unmount  
  useEffect(() => {  
    //Add a javascript event listener to the window  
    //to listen to scroll events  
    window.addEventListener('scroll', onScrollHandler);  

    //Return a function to run on unmount  
    return () => {  
      //Don't forget to remove any event listeners on unmount!  
      window.removeEventListener('scroll', onScrollHandler);  
    }  
  }, []);  

  //Finally return the value of interest  
  return scrollDistance;  
}  

export default useScrollDistance;

That's our hook, it uses useEffect to run a function on component mount which binds an event listener to the window's scroll event. Our event handler then updates our state with the new value of the scroll distance.

And here's how we might use it;


//Import our custom hook  
import useScrollDistance from './useScrollDistance'  

const myComponent = () => {  
  //Call our hook  
  const scrollDistance = useScrollDistance();  

  //Render the value  
  return (  
    <p>Scroll distance: {scrollDistance}</p>  
  );  
}

And this is what that might look like (with a little styling applied)

You probably wouldn't want to just slap this code into production as is. For one, you might want to add some throttling to the event listener (see my post about understanding throttling, or my post about using custom hooks to listen to DOM events for an example).

Your turn

Hopefully this has shown you how easy it is to create custom hooks, and how useful and powerful they can be. Check out my other posts on the topic for a bit more info if you're interested.

Understanding event throttling
Using custom React hooks to listen to DOM events

Anything a bit vague? Need more info? Let me know! Hit me up on twitter @baffledbasti.

Using absolute (alias) imports in Javascript and VSCode

Seb — Wed, 25 Mar 2020 13:00:00 +0000

Learn how to import javascript or typescript modules with absolute paths in webpack & VSCode

Developers love productivity hacks. Get more done in less time, more time for... more coding? Something like that anyway, and I'm no different.

One of my favourite little productivity and "tidyness" hacks lately is absolute imports in javascript apps - the ability to import modules from an absolute path rather than a relative path.

Using relative imports works great for small projects and examples in blog posts, but for larger projects, relative imports can quickly become a nightmare.

Hopefully this tip helps you out too!

Note : this tip is specific to webpack. If you're not using webpack the first part of this will not work! The part pertaining to VSCode is still relevant.

What are relative and absolute module imports?

In javascript, relative module imports usually look something like this (in ES6);

// e.g. src/pages/index.js  

import myComponent from '../components/myComponent'  

import someUtil from './utils/someUtil'  

// ...

In this example, the component myComponent is imported from the relative path ../components/myComponent.

Why is this path 'relative'? Because the path is relative to the current file. The single dot or double dots at the beginning of the import path, followed by the directory separator (slash) indicate a either the same directory as the current file or a directory one level above.

As you can see, if we have a large project with a deeply hierarchical directory structure, we might end up with relative imports like;

import myComponent from '../../../../myComponent'

And that's going to get annoying real fast!

Why use absolute module imports?

Relative imports aren't all bad. I'm not saying never use them! On the contrary, it's a good idea to use relative module imports sometimes. For example if you have closely related files that might be considered part of the same larger module, which are probably located in the same directory, you would almost definitely want to use a relative import.

Much of the time, however, relative imports are used throughout the whole codebase, and this can get messy really quickly as the project grows in scale. Relative imports just work straight out-of-the-box. Zero config necessary. Whereas absolute imports require a (very) small amount of configuration.

Webpack configuration for absolute imports

To enable absolute imports we'll need to make a small change to our webpack config.

(Note: if you're using create-react-app you might have difficulty customizing your webpack config).

It's really easy to configure webpack to look for your source files using an absolute path. All we need to do is add some aliases to the resolve section of the webpack config.

For example a vanilla webpack.config.js might look like; (See the webpack docs on resolve settings).

module.exports = {  
  //...  
  resolve: {  
    alias: {  
      '@Components': path.resolve(\_\_dirname, 'src/components/'),  
      '@Utilities': path.resolve(\_\_dirname, 'src/utilities/')  
    }  
  }  
};

Now we can use these aliases like;

import myComponent from '@Components/myComponent'  

import someUtil from '@Utilities/someUtil'

Which is awesome! No longer do we need to know where the component we want is relative to our current file. Nice!

Use webpack alias in VSCode

Being able to import our components and utilities with absolute paths is awesome. But it can still get annoying typing out "@Components/myComponent..." every time.

Fortunately the lovely people behind visual studio code thought of this. You can use a jsconfig.js file in the root of your project to tell VSCode about your webpack aliases.

Add a file called jsconfig.js to the root of your project with the following code;

// jsconfig.json  

{  
  "compilerOptions": {  
    "baseUrl": ".",  
    "paths": {  
      //Assuming your components/utilities live in ./src  
      //Update this path as necessary  
      "@Components/\*": ["./src/Components/\*"],  
      "@Utilities/\*": ["./src/Utilities/\*"]  
    }  
  },  
  //Add any build/compiled folders here to stop vscode searching those  
  "exclude": ["node\_modules", "build"]  
}

You might need to update the paths in the config to match your project. This config assumes your components folder is in ./src which may or may not be the case.

Now you should have absolute webpack imports that work in vscode

Hopefully this quick tip helped you set up your project for faster, more productive development using absolute imports with webpack aliases.

Got more tips? Let me know! Everyone likes a good productivity hack!

Using Custom React Hooks to Listen to DOM Events

Seb — Mon, 23 Mar 2020 13:00:00 +0000

Listening to DOM events in React can be a little tricky and can quickly get messy. Even worse, it can be hard to trigger effects and state updates based on DOM events. Luckily, we can easily use custom hooks to 'reactify' our DOM event listeners. Read on!

Watch Video

Rather watch than read? I recorded a video of this post too!
Note: I didn't have an external mic for this video, so please forgive the typing and fan noise!

Get Started

To get started, you're going to need a (surprise...) React app.

If you don't already have one, I recommend using create-react-app to quickly scaffold a new React app with all the tools you need for quick development.

Jump into your favourite terminal and run the command below. If you'd like to change the name of the folder your app is created in, change custom-react-hooks-dom-events to the folder name you'd like (this folder will be created).

npx create-react-app custom-react-hooks-dom-events

Open up the project in your favourite code editor. I'm using VS Code.

If you already have a React project, open that and get started.

Add a new hook

We're going to add a hook to listen to viewport width and changes. I'm going to put this code in a separate file so it's easy to reuse throughout the project.

Create a new file called useViewportWidth.js

I'm adding this file in src/useViewportWidth.js, but if you have a larger project, you'll probably want to have it somewhere more sensible.

Open up our new file and add the following code;

// src/useViewportWidth.js  

// We'll need useState and useEffect from react  
//This let's us 'reactify' our values  
import { useState, useEffect } from "react";  

// This is our custom hook  
// It's just a function that returns a value for now  
const useViewportWidth = () => {  

  // Just a test  
  const viewportWidth = "Viewport Width goes here"  

  // Our hook should return something  
  return viewportWidth  
}  

export default useViewportWidth

At this point this code is just a test to make sure our hook works.

Test that it works

I'm going to edit src/App.js for this demo, but you should open the component where you'd like to use the hook value.

// src/App.js  

//  
// ... other code  
//  

// Import our hook  
import useViewportWidth from "./useViewportWidth";  

function App() {  
  // ... other code  

  // Add our hook call  
  // We're setting the result of our hook  
  // to a constant called 'viewportWidth'  
  const viewportWidth = useViewportWidth();  


  // Render something  
  return (  
    <div className="App">  
      <header className="App-header">  
      {/\* We're just going to render the viewport width for now.  
      You could use this however you like \*/}  
        <p>The viewport width is: {viewportWidth}</p>  
      </header>  
    </div>  
  );  
}

Here we imported the hook from the file we made earlier, and then called the hook within our component. Finally we rendered the result of the hook (viewportWidth) to the DOM.

If everything has gone well, you should see something like;

Make it useful

So far so good, but that's not really very useful yet. We need some information about the viewport.

We'll achieve this in a couple of steps.

Add a function to get the width of the viewport
Create a state object and setter via useState
Bind an event listener to changes in the viewport size

Get the viewport width

We're going to add a function to get the width of the viewport. Now this could go in a separate file again if you want it to be reusable, but for simplicity I'm going to include it in the hook.

Update your src/useViewportWidth.js to look like this;

import { useState, useEffect } from "react";  

const useViewportWidth = () => {  

  // Get the viewport width  
  const getViewportWidth = () => {  
    let e = window,  
      a = "inner";  
    if (!("innerWidth" in window)) {  
      a = "client";  
      e = document.documentElement || document.body;  
    }  
    return e[a + "Width"];  
  };  

  return viewportWidth;  
};  
export default useViewportWidth;

Here we've added a function called getViewportWidth which does exactly what it says on the tin. It returns the width of the viewport (excluding scrollbars), and is reasonably cross browser compatible. It checks if window.innerWidth exists and if not uses document.clientWidth.

Add the viewport width to a state object

Remember how in React we need to add values into "state" if we want to perform actions (side-effects) based on their values? Side-effects might be two-way bindings, rendering etc.

So after our getViewportWidth function, we're going to add the following line.

const [viewportWidth, setViewportWidth] = useState(getViewportWidth())

What this does is sets up a state variable (viewportWidth) and sets it to the initial viewport width.

Bind and event listener to the viewport width

Finally, we need to add an event listener to listen to changes in the viewport width. We can do this via window.addEventListener, but there are a couple of things we need to do to 'reactify' it.

We're going to add a useEffect hook, just after the last line we added (useState) to run a side-effect when the component mounts.

// Run an effect when the component mounts  
useEffect(() => {  
  // We're going to create an 'onResize' event handler which will update our state  
  const setFromEvent = () => setViewportWidth(getViewportWidth());  

  // Add an event listener for resize, which will update our state  
  window.addEventListener('resize', setFromEvent)  

  //Finally, remember to unbind the event listener on unmount  
  return () => {  
    window.removeEventListner('resize', setFromEvent)  
  }  
}, []); // Empty parentheses will cause this to run once at mount

Our useEffect hook only runs once on component mount, and adds an event listener to the window resize event. The event listener sets our state variable to the new size of the viewport. Finally, we return a function to be called on unmount which will tidy up and remove the event listener.

Here's one I prepared earlier

If you put it all together correctly, your src/useViewportWidth.js file should look like this;

You can feel free to copy/paste this into your project if you want.

import { useState, useEffect } from "react";  

const useViewportWidth = () => {  
  const getViewportWidth = () => {  
    let e = window,  
      a = "inner";  
    if (!("innerWidth" in window)) {  
      a = "client";  
      e = document.documentElement || document.body;  
    }  
    return e[a + "Width"];  
  };  

  const [viewportWidth, setViewportWidth] = useState(getViewportWidth());  

  useEffect(() => {  
    const setFromEvent = () => setViewportWidth(getViewportWidth());  

    window.addEventListener("resize", setFromEvent);  

    return () => {  
      window.removeEventListener("resize", setFromEvent);  
    };  
  }, []);  

  return viewportWidth;  
};  
export default useViewportWidth;

And if you save and switch to your app should should see;

Wrapping up

Awesome, you should now have seen how we can use a custom React hook to bind to a DOM event. See if you can use this to listen to the scroll position (scroll top) instead. Hit me up on twitter if you have an questions, feedback or suggestions, I'd love to hear them. I'm @baffledbasti on twitter.

Before you go...

One last thing before you go. You might have noticed that our custom React hook will fire on every single update of the DOM event we're listening to. Consequently, any side-effects or renders that result from those updates will also run every single time. This might be many times per second! If you're using this in production it could have significant performance implications.

One thing we can do to this code to make it have a slightly smaller performance impact is throttle our hook updates.

The idea behind throttling is that we only allow an event to occur once per some period of time. Any additional triggers in this period are ignored.

Below is an example of how we can throttle our hook updates using the throttle function from the lodash library. You may not want to include lodash for just this function (although with tree shaking you can get around that).

Two (and a bit) steps to throttling

1. Import our throttle function

It's not really a step, but import the throttle function from lodash like so

// Only import the throttle function  
// this way tree shaking can only include this function  
import {throttle} from 'lodash'

2. Create a throttled version of our set state function

The throttle function from lodash works by taking a function and returning a throttled version. (You can read the lodash docs about throttle function if you like).

Remember our function we created to pass to the window.addEventListener?

We're going to create a throttled version.


// ...  
// ...  

// This is unchanged  
const setFromEvent = () => setViewportWidth(getViewportWidth());  

// Create a throttled version  
// that only fires every 100ms  
const throttledSet = throttlee(setFromEvent, 100, {  
  leading: true,  
  trailing: true  
});

We created a throttled version of our function (called throttledSet ) that only fires every 100ms. We also specified that we want it to fire on the leading edge and the trailing edge.

If you're interested in understanding throttling and what the leading and trailing edge triggering are about, check out our post Understanding event throttling.

3. Update our event binding

Finally, change your event bindings to call our new throttled function instead of the old one.'

useEffect(() => {  

  // ...  

  window.addEventListener('resize', throttledSet);  
  return () => {  
    window.removeEventListener('resize', throttledSet);  
  }  

})

If you save and run your code again, you'll notice the viewportWidth is only updated at most twice per 100ms. Of course this may be hard to see, so if you'd like to see it with your own eyes, try setting the throttle window to 1000ms (1 second) and see what happens.

Understanding event throttling

Seb — Sun, 22 Mar 2020 13:00:00 +0000

Event throttling, what on Earth is it, how does it work, and why do you care?

Ok, I apologise that this post isn't so much something you can crack open in a project and get your teeth into. It's more of a concept, a lesson. But it's something you might come across and it is relevant to frontend Javascript. It's probably relevent in quite a few places.

We're going to talk about event throttling or more accurately, throttling event handlers, as we don't actually have any control over the events themselves.

What's an event

We're going to talk about events in the context of frontend web development. In this context, events that we might want to throttle include things like mouse move , scroll or mobile specific events like touch events.

Browsers will listen to all kinds of events that are provided, either by the user or some other system, and allow you to attach your own listeners via javascript to run various actions when these events occur.

When we bind a function to an event, it's called an event handler. The event happens, our event handler runs (essentially). In code, that often looks like this;

// For example, listen to scroll events  

const onScrollHandler = () => {  
  console.log('Window scrolled!');  
}  

window.addEventListener('scroll', onScrollHandler);

Why would I want to throttle an event handler

Good question. Let's take the example above, and let's say you're doing some complicated maths every time the event handler is fired, instead of just logging to the console.

Now, how the event loop works is (loosely) that the browser will call your event handler pretty much as often as it can while the event/s triggering it are happening.

You're listening to scrolling? And the user is scrolling? Cool, the browser is calling your event handler many, many times per second (or as many as it can). See where I'm going with this?

If you stick some complicated, memory intensive, long running process in your event handler, what happens? Every time the browser calls it, it starts chewing through the complicated stuff. This takes a while, probably longer than the time it takes for the browser to call the function again. The browser kicks off the event handler again. And so on. Eventually the browser crashes (maybe).

What can I do?

I mean, I really set myself up for this one; throttle the event handler!

Throttling our event handler involves creating a function to wrap our event handler and only allow it to be invoked once per some time period. For example we only allow our function to run once every 100ms at most.

This means our code has time to complete, and we're not chewing up CPU by running our function an unneccessary number of times. (For reference, if you're updating the DOM, the human eye can only update 60 times per second* which is roughly every 16 ms.)

* not entirely true, but for the purposes of this article let's assume it is.

Throttling explained

So throttling ensures that our function executes once, and only once, per the time period we specify.

A good example is from this article by David Corbacho on CSS tricks about throttle vs debounce, using an infinite scrolling element.

As the user is scrolling down the page, we need to know how far from the bottom the user is. To do this we need to listen to the on scroll event. We don't want to miss it though, so we need our function to execute at least once per our window.

To achieve this we need our function to execute on both the leading and trailing edge of our throttle period.

What does this mean? If we consider our incoming events (in this case scroll events) as signal pulses, and plot them against time, we get the below figure.

When the first event occurs, it starts our throttle period. This is our leading edge, as it starts the throttling.

Any events that occur for the next 100 ms are effectively ignored.

When our period is over (after 100 ms), this is our trailing edge.

So if we specify that we want our function to execute once per 100 ms, on the leading edge, it will run at the first event, and not for the next 100 ms.

If we specify that we want our function to execute once per 100 ms, on the trailing edge, it will run 100 ms after the first event.

If we specify that we want to throttle our function to 100 ms but execute on the leading and trailing edge, it will run on the first event, and not again until the end of the 100 ms.

That's throttling

Hopefully you've got a somewhat better understanding of how to throttle a javascript event handler, why you might want or need to do it, and how to set it up.

If there's anything unclear, or you think I should explain some bits better, please reach out to me on twitter @bafffledbasti.

One last pro-tip to leave you with: I wouldn't recommend writing your own throttling function. Trust me, it's a recipe for failure. Use something like lodash - it's tried and tested and just works.

Enqueue Wordpress Plugin Admin Panel Scripts

Seb — Mon, 21 Oct 2019 13:00:00 +0000

How To Enqueue Wordpress Plugin Admin Scripts Only Where You Need Them

If you're building a Wordpress plugin with an admin panel, only enqueue your scripts/styles on your page

On of my pet peeves with Wordpress plugins is intrusive scripts and styles. They're the biggest contributor to big, slow Wordpress sites, and they give Wordpress a bad name.

When I'm building a plugin with an admin panel, I like to only enqueue my scripts and styles on that page.

Here's how I do it;

1. First, create your admin page

<?php  
add\_action('admin\_menu', 'nwd\_add\_admin\_page');  
function nwd\_add\_admin\_page() {  
  // add top level menu page  
  add\_menu\_page(  
    'My Admin Page',  
    'My Admin Page',  
    'manage\_options',  
    'my-admin-page',  
    'admin\_page\_html'  
  )  
}

This code will add a top level menu item 'My Admin Page', which will display the HTML returned by the callback 'admin_page_html'

You may also want to create a submenu page which will be slightly different code.

2. Enqueue your scripts and styles cleverly

<?php  

add\_action('admin\_enqueue\_scripts', 'nwd\_admin\_enqueue\_scripts');  

public function nwd\_admin\_enqueue\_scripts($screen) {  
  // Check the $screen variable to see what page we're on  
  // if you created a top level page in the previous step  
  // $screen should be toplevel\_page\_$slug  
  // If $screen doesn't match, we will quit so we don't   
  // pollute the whole admin with our scripts/styles  


  // Quit if it's not our screen  
  if('toplevel\_page\_my-admin-page' !== $screen) return;  

  // If we get this far, it must be our screen  
  // Enqueue our assets  
  wp\_enqueue\_script('my-admin-page', plugin\_dir\_url( \_\_FILE\_\_ ) . 'assets/js/admin.js', array(), null, true);  
}

This code is how you're probably already adding scripts, but the small difference is we check the $screen variable to see if we are on the right screen.

Wordpress will pass the $screen variable in when it calls your enqueue scripts function, and you can use this to check which admin page you're on.

Clever!

How To Add Tabs To Wordpress Admin Page

Seb — Mon, 21 Oct 2019 13:00:00 +0000

How To Add Tabs To Your Wordpress Plugin Admin Page

Ever wanted to add tabs to your Wordpress plugin's admin page without rolling your own? Well you can very easily it turns out.

Tabs are baked into the Wordpress core, so you don't need to do anything particularly difficult to add them.

You might have seen various plugins such as Woocommerce using the tabs to add many settings areas to one plugin page.

Adding tabs to Wordpress plugin admin

1. Add your admin page

If you haven't already got an admin page, add one with the following code;

If you already have, skip to step 2.

<?php  

//Add admin page to the menu  
add\_action( 'admin\_menu', 'add\_admin\_page');  
function add\_admin\_page() {  
  // add top level menu page  
  add\_menu\_page(  
    'My Plugin Settings', //Page Title  
    'My Plugin', //Menu Title  
    'manage\_options', //Capability  
    'my-plugin', //Page slug  
    'admin\_page\_html' //Callback to print html  
  );  
}

This code hooks in to the admin_menu Wordpress hook and registers a new admin menu item. We're adding a top level item, but it's also possible to add a submenu item.

You can change these settings to suit your needs. I'd usually recommend leaving the capability ('manage_options') as is. The 'admin_page_html' is the name of the function to call to generate the html for your admin page.

Note: if you're using this inside a class, change the callback to be array($this, 'admin_page_html').

2. Generate admin page HTML - with tabs!

Ok, now you can add the tabs to your markup;

<?php   

//Admin page html callback  
//Print out html for admin page  
function admin\_page\_html() {  
  // check user capabilities  
  if ( ! current\_user\_can( 'manage\_options' ) ) {  
    return;  
  }  

  //Get the active tab from the $\_GET param  
  $default\_tab = null;  
  $tab = isset($\_GET['tab']) ? $\_GET['tab'] : $default\_tab;  

  ?>  
  <!-- Our admin page content should all be inside .wrap -->  
  <div class="wrap">  
    <!-- Print the page title -->  
    <h1><?php echo esc\_html( get\_admin\_page\_title() ); ?></h1>  
    <!-- Here are our tabs -->  
    <nav class="nav-tab-wrapper">  
      <a href="?page=my-plugin" class="nav-tab <?php if($tab===null):?>nav-tab-active<?php endif; ?>>Default Tab</a>  
      <a href="?page=my-plugin&tab=settings" class="nav-tab <?php if($tab==='settings'):?>nav-tab-active<?php endif; ?>>Settings</a>  
      <a href="?page=my-plugin&tab=tools" class="nav-tab <?php if($tab==='tools'):?>nav-tab-active<?php endif; ?>>Tools</a>  
    </nav>  

    <div class="tab-content">  
    <?php switch($tab) :  
      case 'settings':  
        echo 'Settings'; //Put your HTML here  
        break;  
      case 'tools':  
        echo 'Tools';  
        break;  
      default:  
        echo 'Default tab';  
        break;  
    endswitch; ?>  
    </div>  
  </div>  
  <?php  
}

The important part of the markup is the nav-tab-wrapper and it's contents. This is all you need to add tabs to your admin panel, and the styling is provided by Wordpress!

How it works

First, we add the required markup for the tabs. This is a element with the classname "nav-tab-wrapper", and child elements with the "nav-tab" class.

<nav class="nav-tab-wrapper">  
  <a href="?page=my-plugin" class="nav-tab nav-tab-active">Default Tab</a>  
  <a href="?page=my-plugin&tab=settings" class="nav-tab">Settings</a>  
</nav>

The child elements (anchor links) have a query string variable tab which allows us to know which tab is active.

We use this variable like so;

<?php  

//Get the active tab from the $\_GET param  
$default\_tab = null;  
$tab = isset($\_GET['tab']) ? $\_GET['tab'] : $default\_tab;

We can then query the $tab variable to add the nav-tab-active class, and render the html for the correct tab content.

Easy!