Forem: WellPaidGeek 🔥🤓🔥

JavaScript: Why I both hate and love fat arrow functions

WellPaidGeek 🔥🤓🔥 — Mon, 10 Feb 2020 20:45:49 +0000

When fat arrow functions were first added to JavaScript, I rejoiced.

For a language where you often end up writing small functions is place as an argument passed to something, having a concise way to define an anonymous function was really handy.

A great example would be the following

<Button onClick={function () { console.log('clicked'); }} />

<Button onClick={() => console.log('clicked'); } />
That small example is a perfect example of where arrow functions shine: small anonymous functions where the syntax for the function definition itself would almost be longer than the body body of the function.

So for a while everything was fine with arrow functions.

Then came the linting rules.

Then came everyone thinking all functions should be arrow functions.

Then… then came my hatred.

First there’s the lint rule to only allow arrow functions. We can’t use function declarations any more. Although I would prefer to choose my own style of defining a function based on what I think is suitable in the given situation, I can live with this.

Next comes the linting rule that arrow functions where the body is just a return statement must omit the function body all of the time.

Sounds innocent. Sounds reasonable. I disagree. I think it leads to worse code. This is especially true when using this with React components. You end up with things like this:

const MyComponent = ({
  prop1,
  prop2,
  prop3,
  prop4,
  prop5,
}) => (
    <div>
          <h1>{prop1}</h1>
           <p>{prop2}</p>
           <ul>{prop3.map(x => (
             <li>
                <a href={a.href}>{a.text}</a>
             </li>
           ))}</ul>
           <div>
            <ul>{prop4.map(x => (
             <li>
                <a href={a.href}>{a.text}</a>
             </li>
           ))}</ul>
           <p>
             {prop5}
           </p>
         </div>
);

This is actually a fairly tame example. I’ve seen React components that are multi hundred line single expressions. They’re really hard to read, and therefore maintain. In addition to this, if you want to do any debugging you have to alter the function to add a body so you can use console.log or debugger on the first line. Not a huge amount of work, but still a pain in the ass.

So why do I blame things like this on arrow functions, that seems a tad unfair, no?

I blame them because the sequence which leads to code like this usually goes:

Linting for only using arrow functions
Component starts out small, with just a return statement and small amount of JSX
Linting forces that the arrow function omits the body
The component grows
There’s logic added that should be put outside the return, like complex expressions to calculate props. Instead it’s done in place so the dev doesn’t have to change the function to add a body.
Return expression grows and becomes hard to maintain.

Overall arrow functions represent something I’ve seen from JavaScript dev far more than developers of other languages: concise code over easy to read code. Something I say many times is that code is read many more times than it’s written, therefore devs should optimise for readability over writability.

In summary, I’m not against arrow functions per say, rather their enforced overuse. Want a simple click handler in place, or a function that is basically just a small expression of the arguments? Sure, arrow function away. Want a bigger function? Why not just use, you know… a function?

Liked this? Then you'll love my mailing list. I have a regular newsletter on JavaScript, tech and careers. Join over 5,000 people who enjoy reading it. Signup to my list here.

JavaScript: Using fetch to make HTTP requests

WellPaidGeek 🔥🤓🔥 — Thu, 30 Jan 2020 12:56:30 +0000

Once upon a time JavaScript was used to add a small sprinkling of interactivity to otherwise static web pages. Times have changed since then. People now expect entire applications delivered in the browser. Applications need data, and the best way to get data to a Frontend app is to make HTTP calls to a web server.

In this tutorial, I will teach you the best way to make these HTTP requests in the browser via JavaScript. The fetch API.

Once upon a time JavaScript used to make web requests using XMLHttpRequest. If you want to know why I recommend fetch instead of this, look it up after reading this. It’s verbose and generally less straight forward than fetch.

Let’s use fetch to query the Giphy API, and get us some animated gifs!

If you want to follow along you’ll need to sign up at https://developers.giphy.com/ to get an API key first. You just signup, create a new app, and get the key. It’s probably worth looking at the docs for the search endpoint too, as that’s what we’re going to be using.

We’re going to be using fetch to search the giphy API for 5 Dalek giphys. We’ll then display them on the webpage.

First let’s make the url.

const url = 'https://api.giphy.com/v1/gifs/search?'
  + 'api_key=YOUR_API_KEY_GOES_HERE'
  + '&q=dalek'
  + '&limit=5'
  + '&offset=0'
  + '&rating=G'
  + '&lang=en';

It’s just a simple url of the giphy search endpoint, and query string params to configure the search as follows:

api_key: your api key, duh
q: string – the term to search for
limit: number – the maximum number of results to return
offset: number – skip all results before this offset. Used in conjunction with limit to allow for pagination
rating: string – how naughty it can be
lang: string – the language

To make a fetch request to this url we simply do:

fetch(url)

By default this will make a fetch request to this url. Fetch comes with many options including request type and headers, but we aren’t looking at those now.

The call to fetch will return a promise. If the promise resolves successfully (there is no error) then the function you pass to then will contain a response object.

The response object is an abstraction over an HTTP response. It contains a lot of stuff, but we’re only concerned with one part of it, the response body. The body is where giphy puts the data about the search results. It gives us this data as JSON. We can tell the response object to parse this json to a JavaScript object and give it to us using the .json() function on the response. The result of this will also return a promise.

fetch(url)
  .then(res => res.json())

This means that the result of the call to then() will also be a promise, and this promise will resolve to a JavaScript object containing the result of the search. Giphy gives us an object containing a property data, which as an array of all the search results.

If you console.log data out you’ll see the search results themselves are a huge object. I’m just going to show you an example of what we get back, including only one result, and only the properties we need from it:

const resultsWillLookLike = {
  data: [{
    images: {
      downsized: {
         url: 'http://media.giphy.com/result123.gif'
      }
    }
  }]
};

The part we are interested in is just the url of a downsized version of the giphy.

Let’s map over each result in data, and have the map iterator function create an IMG tag and add it to the webpage. We should end up with 5 giphys of Daleks on a webpage.

Here’s the full code:

function renderGiphy (giphy) {
  const img = document.createElement('IMG')
  img.src = giphy.images.downsized.url
  document.body.appendChild(img);
}

const url = 'https://api.giphy.com/v1/gifs/search?'
  + 'api_key=YOUR_API_KEY_GOES_HERE'
  + '&q=dalek'
  + '&limit=5'
  + '&offset=0'
  + '&rating=G'
  + '&lang=en';

fetch(url)
  .then(res => res.json())
  .then(({ data }) => data.map(renderGiphy));

Liked this? Then you'll love my mailing list. I have a regular newsletter on JavaScript, tech and careers. Join over 5,000 people who enjoy reading it. Signup to my list here.

How to write custom hooks in React

WellPaidGeek 🔥🤓🔥 — Thu, 23 Jan 2020 23:34:58 +0000

Hooks have been the latest hotness in React for a while now. They come with certain advantages like reducing the need for render props (god thank you!) and being able to have state in function based components. If you haven’t used them yet, I really recommend you check out the docs before reading on.

Custom hooks allow you to create functionality that can be reused across different components. You can of course just have functions to reuse functionality, but hooks come with the advantage of being able to ‘hook’ into things like component lifecycle and state. This makes them much more valuable in the React world than regular functions.

What makes a custom hook? A custom hook is just a function that uses other hooks. If you don’t use any hooks in your function, it’s just a function, not a hook. By convention, the name of a hook function should start with ‘use’. It doesn’t have to, but if it doesn’t people won’t easily realise it’s a hook.

To show you an example of a custom hook I’m going to code a simple hook that could actually be useful in the real world.

We’ll call our hook useBodyScrollPosition.

The idea is that each time the body of the document is scrolled, the hook will fire and return the current scroll offset. This could be useful in such cases where you need to move a component on the page or change it in some way in response to scrolling.

Of course you could do this just within your component, but then it wouldn’t be reusable in other components, which is one of the main advantages of hooks.

So without further ado, here’s our component:

// use-body-scroll-position.js
import { useState, useEffect } from 'react';

export default () => {
  const [scrollPosition, setScrollPosition] = useState(null);
  useEffect(() => {
    const handleScroll = () => setScrollPosition(window.scrollY);
    document.addEventListener('scroll', handleScroll);
    return () => 
      document.removeEventListener('scroll', handleScroll);
  }, []);
  return scrollPosition;
}

useEffect makes sure the event listener gets setup when the hook is mounted. The function returned by useEffect’s function will be called when the hook is unmounted, and this will clean up by removing the event listener. If we don’t do this it will try and set state on an unmounted hook when it fires.

The second argument to useEffect, an empty array of dependencies, ensures that the effect is only called once, when the hook first mounts. We don’t want to keep adding the event listener!

The state is just a single value, the scroll offset, and this is the value our hook returns. It defaults to null, which will always be returned when the hook is first called. This value will only change when there’s a scroll event, it will remain null till then. Changes would be required if you wanted it to return the current offset prior to any scroll.

Each time the scroll event fires, the state updates, the hook function gets called again with the latest state, and returns the scroll offset to the calling component.

Here’s an example of using it in a component. All it does is put the scroll value in the middle of the window, updating as you vertically scroll. I wouldn’t usually use inline styles, but wanted it all in one file for this post.

import React from 'react';
import useBodyScrollPosition from './use-body-scroll-position';

export default () => {
  const scrollPosition = useBodyScrollPosition();
  const wrapperStyles = {
    height: '5000px',
  };
  const displayStyles = {
    position: 'fixed',
    width: '100%',
    top: '50%',
    transform: 'translateY(-50%)',
    fontSize: '20px',
    textAlign: 'center',
  }
  return (
    <div style={wrapperStyles}>
      <div style={displayStyles}>
        {scrollPosition !== null ? scrollPosition : 0}
      </div>
    </div>
  )
}

Here’s that component in action below.

Of course the hook is maybe not quite production ready. You’d probably want to add configuration options for performance optimisation, like debouncing or only firing based on a predicate on the scroll position, but this is about creating custom hooks so I didn’t bother with all that.

Overall take away, creating custom hooks is easy!

Liked this? Then you'll love my mailing list. I have a regular newsletter on JavaScript, tech and careers. Join over 5,000 people who enjoy reading it. Signup to my list here.

JavaScript: ES6 modules made simple

WellPaidGeek 🔥🤓🔥 — Thu, 16 Jan 2020 21:49:04 +0000

Before ES6 there was no native system in JavaScript for importing modules.

There were tools like commonjs, but nothing built into the language spec. Every other major language seems to have a way to do this, so the fact that JavaScript lacked this did lend credence to the people who thought of JavaScript as a ‘toy language’.

In this article I’m going to be looking at why we need modules in JavaScript, and how we create and use them.

Why do we need modules?

Without modules, by default all code included in our application, either from 3rd party code or our own, would be global in scope by default.

Modern JavaScript applications can use many thousands of imported functions (not just the libraries you use, but the libraries they use and so on). If everything was global, that’s one hell of a cluttered global namespace. You’d forever fear that each time you created a new function there would be a naming clash. The best case is that you get an error as soon as you define something that’s got a name that’s taken. Worse case is it gets silently overwritten, leading to a very very hard to find bug.

The revealing module pattern

In the past this has been solved on an ad hoc basis, usually using the revealing module pattern. An example of this pattern would be this:

const public = (function () {
  var hidden = true;
  function private1 () {}
  function private2 () {}
  return {
    private1,
    private2,
  };
})();

The result of this is that private1, private2 and hidden are private to the scope of the enclosing function. They do not exist in the global scope. All that exists in the global scope is public. ‘public’ is a variable referencing an object that has properties called private1 and private2. These are functions which we are exporting from the ‘module’.

Although this solution worked, there were a few problems with it:

Having to do the self executing closure is annoying, ugly boilerplate
Since it’s not an ‘official’ built into the language standard, 3rd party code may not do it at all
Lack of a standard means different libraries may implement this differently, leading to confusion.

To solve these problems, ES6 gave us modules.

Default Exports

An ES6 module is just a JavaScript file which exports certain expressions which can then be imported elsewhere in your code.

Exports can be default or named. Let’s look at default exports first.

const secretNumber = 123;
export default class User;

A default export is done by using the export keyword followed by the default keyword, followed by the expression to be exported, in this case the User class definition.

Default exports are imported as follows:

import User from './user';
const user = new User('wellpaidgeek@gmail.com');

Here the user would be defined and exported in one js file, and imported and used in another js file. Each js file would be its own module.

The path to user when used in the import statement ('./user') should be the relative path to that file from the current file you’re importing to.

Note with the default exports, what we choose to name the thing we’re importing is completely arbitrary. It doesn’t have to match whatever we called it when we exported it. This means the above could be written as the following, and will still work just the same:

import ICanCallThisAnythingAndItIsStillAUserClass from './user';
const user = new ICanCallThisAnythingAndItIsStillAUserClass('wellpaidgeek@gmail.com');

A module does not have to have a default export, but if it does, it can only have one of them. So the following is invalid:

const func1 = () => {};
const func2 = () => {};

export default func1;
export default func2;

What types of thing can we export?

Any expression. So that’s variables, functions, classes, literals. All of the following are valid default exports:

export default 99;

export default 'foo';

export default 10 + 10;

export default () => { console.log('EXPORTED'); };

const x = 10;
export default x;

Named exports

The other type of exports we can have are called named exports. An example is as follows:

// maths.js
export const pi = 3.142;
export const factorial = x => {
    if (x < 2) {
        return 1;
    }
    return x * factorial(x - 1);
};

// main.js
import { pi, factorial } from './maths';

const myNumber = factorial(4) + pi;

‘maths.js’ is exporting two named exports, pi and factorial. ‘main.js ‘ is using them.

Unlike with default exports where each module can only have one default export, a module can have any number of named exports. The other difference is that named exports must be given a name, and they must be imported using that name. When we import named exports, the names of all the exports we want to import must be included in a comma separated list, wrapped in curly braces.

How do we give an export a name? An export’s name is taken to be the identifier we use for the expression. This could be a function name, variable / constant name or class name. In the case of maths.js, constant names are used.

Other examples of naming:

export class User {} // name: User
export function generatePassword () {} // name: generatePassword
export const apiKey = '123'; // name: apiKey

Mixing default and named exports

What if we want a module to have both a default export and also named exports? This is easy, and would work like this:

// user.js
export default class User {}

export function generatePassword () {}
export const generateUniqueUserId = () => {};

// main.js
import User, { generatePassword, generateUniqueUserid } from './user';

The default import must come first, then a comma, then the list of named exports we want, enclosed in curly brackets.

Aliasing named imports

You may have notice a flaw in named imports. What if we import something and it has a naming clash with another module? Don’t worry, the clever people behind ES6 have thought of that. They have given us the ability to alias named exports.

If we had two modules, module1 and module2, and they each had an export named ‘calculate’, here is how we would alias them to avoid a naming clash in the module importing them:

import { calculate as module1Calculate } from './module1';
import { calculate as module2Calculate } from './module2';

module1Calculate();
module2Calculate();

Using modules

In modern browsers like chrome, you can use modules by specifying type=“module” in the script tag when including them in an HTML page. If you had a module called user, and a module called main that imported from user, you’d include them like this in your webpage:

<script type=”module” src=”user.js”></script>
<script type=”module” src=”main.js”></script>

Although I’m aware this is possible, I never do this, mainly as this is not fully supported in all browsers yet. Instead I use a combination of webpack and babel to compile all modules into a single bundle for deployment. This is beyond the scope of this article (It’s long enough already!). An easy way to try this out would be to use create react app to create a barebones react app. You could then create modules in the src folder and practice importing from them into App.js.

Liked this? Then you'll love my mailing list. I have a regular newsletter on JavaScript, tech and careers. Join over 5,000 people who enjoy reading it. Signup to my list here.

JavaScript: Transforming arrays using map

WellPaidGeek 🔥🤓🔥 — Thu, 09 Jan 2020 09:12:38 +0000

If you’ve done even the most basic coding in JavaScript, I’m sure at some point you’ve used a for loop to iterate an array.

This works just fine, but did you know that Array.prototype (the base array object) contains a number of functions that make performing common tasks based on array iteration more concise?

One such function is map, and map is used to transform an array based on a transformation function. Let’s look at an example using a for loop, then I’ll show you the same thing using map, and I’m sure you’ll agree it’s nicer.

Let’s say we want to transform all the strings in an array to uppercase. Using a for loop we could do:

const list = ['javascript', 'ruby', 'java'];
const allCapsList = [];
for (let i = 0; i < list.length; i++) {
  allCapsList.push(list[i].toUpperCase());
}
// allCapsList ['JAVASCRIPT', 'RUBY', 'JAVA']

The same code when using map would be:

const list = ['javascript', 'ruby', 'java'];
const allCapsList = list.map(item => item.toUpperCase());
// allCapsList ['JAVASCRIPT', 'RUBY', 'JAVA']

As you can see, map makes things much more concise. It removes all of the iteration logic, so you can focus on the transformation you want to perform. As you can see this means less code is required for the same result.

So let’s break down the map function.

It takes as it’s argument an iterator function. That function will be called for each element in the array in turn. The iterator function should return the result of transforming the current array element in some way (uppercasing it in our example).

The return value of map will then be a new array, with every element of the original array transformed by the iterator function. Note that the original array map is called on will not be modified. The transformed elements end up in a new array. It is what we call a pure function.

I’ve only used one argument for the iterator function, the current element in the array for this iteration, but the iterator can take up to 3 arguments:

element: The current element in the array
i: The current numerical index of the array
array: The entire array map was called on (list in our example)

Map is simple. Use it next time you want to transform an array. Give it a go and you’ll never go back to using loops to do this, I promise.

Liked this? Then you'll love my mailing list. I have a regular newsletter on JavaScript, tech and careers. Join over 5,000 people who enjoy reading it. Signup to my list here.