DEV Community: Dale L. Jefferson

JavaScript's Object.freeze and TypeScript's Readonly

Dale L. Jefferson — Tue, 29 Oct 2019 12:06:59 +0000

Do you want static or runtime immutability, or both? In this article I will show you how to combine Object.freeze with Readonly to get the best of both worlds.

JavaScript's Object.freeze

JavaScript's Object.freeze() function provides runtime immutability (at a minor performance cost). You have a 100% guarantee your array or object will not change underneath you.

const austrians = Object.freeze([
  Object.freeze({name: "Carl Menger"}),
  Object.freeze({name: "Eugen Böhm von Bawerk"}),
  Object.freeze({name: "Ludwig von Mises"})
]);

austrians.push({name: "John Maynard Keynes"}); // Runtime Error
austrians[0].name = "John Maynard Keynes"; // Runtime Error

TypeScript's Readonly

TypeScript's Readonly<T> generic type provides static type immutability which has zero performance overhead. At runtime the array or object can change, so this only works if all your code is TypeScript.

interface Austrian {
  readonly name: string;
}

const austrians: ReadonlyArray<Austrian> = [
  {name: "Carl Menger"},
  {name: "Eugen Böhm von Bawerk"},
  {name: "Ludwig von Mises"}
];

austrians.push({name: "John Maynard Keynes"}); // Compile error
austrians[0].name = "John Maynard Keynes"; // Compile error

TypeScript ❤️ JavaScript

These two tools are not mutually exclusive you can combine Static typing immutability & runtime immutability.

interface Austrian {
  readonly name: string;
}

const austrians: ReadonlyArray<Austrian> = Object.freeze([
  Object.freeze({name: "Carl Menger"}),
  Object.freeze({name: "Eugen Böhm von Bawerk"}),
  Object.freeze({name: "Ludwig von Mises"})
]);

austrians.push({name: "John Maynard Keynes"}); // Everything error
austrians[0].name = "John Maynard Keynes"; // Everything error

Error first pattern for JavaScript Async/Await

Dale L. Jefferson — Thu, 30 May 2019 21:49:36 +0000

Dealing with errors is not fun. In this article, I will show you a pattern for dealing with errors in Async/Await. This pattern avoids the use of try/catch.

// Callback
fetch(URL, (error, response) => ...)

// Promise
fetch(URL).then((response) => ...).catch((error) => {})

// Async / await
try { fetch(URL) } catch (error) {}

Notice with callbacks you have no choice but to deal with the error, or at least feel guilty of not dealing with it.

The problem

async fetchData() {
    let json;

    try {
        const response = await fetch(URL)
        try {
             json = await response.json()
        } catch (error) {
             console.log("Parsing failed", error)
             return
        }
    } catch (error) {
        console.log("Request failed", error)
        return
    }

    const stars = json.stargazers_count
    this.setState({stars})
}

Yuck, I hope that disgusts you as it does me, exceptions should be exceptional, and there is nothing exceptional about connectivity issues on a mobile device, this is normal control flow.

Go To Statement Considered Harmful (Edsger Dijkstra - 1968)

I believe try / catch is a glorified Go To statement, execution stops and control jumps to the catch block. It should be used sparingly for exceptions not normal control flow.

So we have gone from explicate returned errors to throwing exceptions, this does not sound like progress.

A possible solution

async fetchData() {
    const [responseError, response] = await fetch(URL);

    if (responseError || !response) {
        console.log("Request failed", responseError)
        return
    }

    const [parseError, json] = await response.json()

    if (parseError || !json) {
        console.log("Request failed", parseError)
        return
    }

    const stars = json.stargazers_count
    this.setState({stars})
}

This uses array destructuring and since error is the first value it makes you think about handling errors. I’ve mixed Go error handling with NodeJS error first callbacks.

Implementation details

const errorFirstPromise = promise => {
  return new Promise(resolve => {
    return promise
      .then(result => {
        return resolve([null, result]);
      })
      .catch(error => {
        return resolve([error, null]);
      });
  });
};

ES7 Async/Await with React Native

Dale L. Jefferson — Thu, 30 May 2019 21:47:40 +0000

Async/Await is a new syntax for writing asynchronous code in JavaScript. Support was added in React Native 0.10 and it’s now reached TC39 stage 3 (candidate).

Example

In this example using the promise returning fetch polyfill. We will display the React Native GitHub star count.

const URL = "https://api.github.com/repos/facebook/react-native";

class StarCount extends Component {
  constructor() {
    super();

    this.state = {stars: "?"};
  }

  componentDidMount() {
    this.fetchData().done();
  }

  async fetchData() {
    const response = await fetch(URL);
    const json = await response.json();
    const stars = json.stargazers_count;

    this.setState({stars});
  }

  render() {
    return (
      <View style={styles.container}>
        <Text style={styles.text}>
          React Native has {this.state.stars} stars
        </Text>
      </View>
    );
  }
}

Async / await works with any Promise based API or one of your creation.

const getStars = () =>
  new Promise(resolve => {
    const FIVE_SECONDS = 5000;
    // Simulate async operation
    setTimeout(() => resolve(1234), FIVE_SECONDS);
  });
const fetchData = async () => {
  const stars = await getStars();
  // Do something with stars
};

The Most Convoluted JavaScript Fizz Buzz Solution

Dale L. Jefferson — Thu, 30 May 2019 21:40:30 +0000

Finding the correct level of decomposition is sometimes challenging. In this article, I will take decomposition to the extreme creating a wildly convoluted Fizz Buzz solution and share my feelings on the correct level of decomposition.

Fizz Buzz Test

Write a program that prints the numbers from 1 to 100. But for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”. For numbers which are multiples of both three and five print “FizzBuzz”.

const modulo = n => a => a % n;
const equals = a => b => a === b;
const compose = (...a) => x => a.reduceRight((p, fn) => fn(p), x);
const equalsZero = equals(0);
const isDivisibleBy = a =>
  compose(
    equalsZero,
    modulo(a)
  );
const isDivisibleBy3 = isDivisibleBy(3);
const isDivisibleBy5 = isDivisibleBy(5);
const isDivisibleBy15 = isDivisibleBy(15);
const ifElse = (condition, onTrue, onFalse) => n => {
  return condition(n) ? onTrue(n) : onFalse(n);
};
const identity = x => x;
const always = value => () => value;

const fizzBuzz = ifElse(
  isDivisibleBy15,
  always("FizzBuzz"),
  ifElse(
    isDivisibleBy3,
    always("Fizz"),
    ifElse(isDivisibleBy5, always("Buzz"), identity)
  )
);

for (let index = 1; index <= 100; index++) {
  console.log(fizzBuzz(index)); // 1, 2, Fizz, 4, Buzz
}

I would hope it is obvious to the reader that I have taken decomposition too far, the question is when should I have stopped and how would I know to stop.

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. - Antoine de Saint-Exupery

Let's take this step by step.

Starting Point

const fizzBuzz = n => {
  if (n % 15 === 0) {
    return "FizzBuzz";
  } else if (n % 3 === 0) {
    return "Fizz";
  } else if (n % 5 === 0) {
    return "Buzz";
  } else {
    return n;
  }
};

Pretty concise code, we could make it a little easier to read and remove duplicated logic by extracting the divisible check into its own function.

First Refactor

const isDivisibleBy = (a, n) => n % a === 0;

const fizzBuzz = n => {
  if (isDivisibleBy(15, n)) {
    return "FizzBuzz";
  } else if (isDivisibleBy(3, n)) {
    return "Fizz";
  } else if (isDivisibleBy(5, n)) {
    return "Buzz";
  } else {
    return n;
  }
};

Now we have the reusable isDivisibleBy function, but should we break it down further? Is isDivisibleBy doing two things finding the remainder and a comparison?

Second Refactor

Extract till you Drop. - Uncle Bob

One Thing: Extract till you Drop.

const equalsZero = n => n === 0;
const modulo = (a, n) => n % a;
const isDivisibleBy = (a, n) => equalsZero(modulo(a, n));

const fizzBuzz = n => {
  if (isDivisibleBy(15, n)) {
    return "FizzBuzz";
  } else if (isDivisibleBy(3, n)) {
    return "Fizz";
  } else if (isDivisibleBy(5, n)) {
    return "Buzz";
  } else {
    return n;
  }
};

Should we stop now or push on? How many of you have "dropped"?

I know it when I see it

I shall not today attempt further to define the kinds of material I understand to be embraced within that shorthand description ["hard-core pornography"], and perhaps I could never succeed in intelligibly doing so. But I know it when I see it, and the motion picture involved in this case is not that. - Justice Potter Stewart

Personally, when I get to the point that the refactored code becomes more complex and harder to read than the original I stop or revert the refactor. I believe this happened in this simplified example at the second refactor. Like many things in software development, this is a personal preference, all versions of this code work as well as all the others, actually, I would imagine the starting point code is the fastest.

Let me know what you think in the comments, how far do you take decomposition?

JavaScript Named Parameters

Dale L. Jefferson — Thu, 30 May 2019 21:38:11 +0000

I find JavaScript's lack of named parameters frustrating. In this article, I will show you how you can get the same effect and as a bonus, show you how to achieve default values.

Without Named Parameters

This is how you are likely writing functions without named parameters.

const formatDate = (day, month, year) => {
  return `${day}/${month}/${year}`;
};

// Somewhere else in your code.
formatDate(1, 2, 2018); // Good: Little-endian?
formatDate(2, 1, 2018); // Bad: Middle-endian?
formatDate(2018, 2, 1); // Bad: Big-endian?

I've never understood the American middle-endian date format.

With Named Parameters

In this example, I'm using Object destructuring to mimic named parameters.

const formatDate = ({day, month, year}) => {
  return `${day}/${month}/${year}`;
};

// Very readable, order you parameters anyway you like.
formatDate({day: 1, month: 2, year: 2018});
formatDate({month: 2, day: 1, year: 2018});
formatDate({year: 2018, month: 2, day: 1});

Default Values

In this example, I'm providing default values to day, month and year making them optional.

const formatDate = ({day = 0, month = 0, year = 2018} = {}) => {
  return `${day}/${month}/${year}`;
};

// Just pass the parameters you need.
formatDate({day: 1, month: 2, year: 2018});
formatDate({month: 2, year: 2018});
formatDate({year: 2018});
formatDate({});
formatDate();

JavaScript Async/Await Promise All Array Destructuring

Dale L. Jefferson — Thu, 30 May 2019 21:36:16 +0000

I think you will agree with me when I say working with asynchronous code is an important part of modern app development. Using new JavaScript syntax you can drastically improve the readability and performance of your code. In this article, I will show you how to use Promise.all() along with array destructuring.

Let's pretend you are building a book app and you want to fetch a book with its author and ratings.

Naive implementation

const getBook = async bookName => {
  const book = await fetchBook(bookName);

  const author = await fetchAuthor(book.authorId);
  const rating = await fetchRating(book.id);

  return {
    ...book,
    author,
    rating
  };
};

getBook("The Wealth of Nations");

Very clean looking code, but how does it perform?

fetchBook: 1 sec
fetchAuthor: 1 sec
fetchRating: 1 sec
Total: 3 sec

The bright people among you will have already noticed that fetchAuthor and fetchRating are independent and could be downloaded concurrently.

Promise all implementation

const getBook = async bookName => {
  const book = await fetchBook(bookName);

  return Promise.all([
    fetchAuthor(book.authorId),
    fetchRating(book.id)
  ]).then(results => ({
    ...book,
    author: results[0],
    rating: results[1]
  }));
};

Not so clean but now we are fetching the author and rating concurrently.

fetchBook: 1 sec
(fetchAuthor/fetchRating): 1 sec
Total: 2 sec

Best of both worlds

const getBook = async bookName => {
  const book = await fetchBook(bookName);

  const [author, rating] = await Promise.all([
    fetchAuthor(book.authorId),
    fetchRating(book.id)
  ]);

  return {
    ...book,
    author,
    rating
  };
};

Here we are using array destructuring with await, which in my opinion, vastly improves the readability of the code and we still have the performance improvement from using Promise.all.

How to save exact npm package versions

Dale L. Jefferson — Thu, 30 May 2019 21:34:09 +0000

I've recently started using exact versions in my package.json. This allows me to have more control over my versions and with tools like Renovate this is easier than ever.

What is an exact version?

"react": "^16.0.0" // carat: allow 16.1.0
"react": "~16.0.0" // tilde: allow 16.0.1
"react": "16.0.0" // exact: only 16.0.0

Why

Renovate has great documentation on why you would do this dependency-pinning

How

There are two ways to force npm or yarn to save exact versions in your package.json.

1. Everytime you install a package

// npm
npm install --save --save-exact react

// yarn
yarn add --exact react

2. Set a default in your config

npm config set save-exact=true

This adds save-exact=true to your .npmrc

JavaScript ES8 Object.entries/values

Dale L. Jefferson — Thu, 30 May 2019 21:32:16 +0000

JavaScript is advancing at a rapid pace. In this article, I will give a brief overview of the new Object static methods. ES8 (a.k.a 2017) now has Object.values and Object.entries to accompany Object.keys.

Object.keys

Using Object.keys to iterate over JavaScript object’s keys.

const countries = {
  FJ: "Fiji",
  CL: "Chile"
};

Object.keys(countries); // ['FJ', 'CL']

Object.values

Now we can do the same for values.

const countries = {
  FJ: "Fiji",
  CL: "Chile"
};

Object.values(countries); // ['Fiji', 'Chile']

Object.entries

But what happens if you would like to do both at the same time?

const countries = {
  FJ: "Fiji",
  CL: "Chile"
};

Object.entries(countries); // [['FJ', 'Fiji'], ['CL', 'Chile']]

Let’s map over the countries using template strings and array destructuring.

const countries = {
  FJ: "Fiji",
  CL: "Chile"
};

Object.entries(countries).map(([code, name]) => `${name} (${code})`);
// ['Fiji (FJ)', 'Chile (CL)']

Object.values and Object.entries are both available in all modern browsers and node 8.

Understanding Redux

Dale L. Jefferson — Thu, 30 May 2019 21:29:54 +0000

After using Redux on a handful of large applications, this is my understanding of how it should be used.

The simple example

const todos = (state = [], {type, payload}) => {
  switch (type) {
    case "ADD_TODO":
      return [...state, payload];
    default:
      return state;
  }
};

const store = createStore(todos);
store.dispatch({type: "ADD_TODO", payload: "Learn Redux"});

The whole state of your app is stored in an object tree inside a single store.

So what is “whole state” of this application? I think the first thing we need to understand is the difference between state and data. It’s very convenient to put everything into to the redux state, and derive the visible state from the Redux state.

const mapStateToProps = todos => ({
  todos: todos.filter(activeTodos).take(5) // Take the top 5 todos
});

So we keep every single todo the user has ever created (potentially thousands), in memory locally on device, that does not sound like it’s going to end well.

I would argue that the user's todo items are data and not application state. So what is application state? Let's take a look at what is displayed on screen, and attempt to determine the application state that would be required to describe it.

Which filter has been selected (All, Active, Completed)
Text input
Total number of items remaining
Titles of the visible todos

That’s it if I were to inspect the Redux state for this application I should see.

const state = {
  textInput: "Drink Coffee",
  filter: "Active",
  total: 2,
  visableTodos: ["Learn Redux", "Write Article"]
};

It’s a good idea to think of its shape before writing any code. What’s the minimal representation of your app’s state as an object?

So to build this user interface we don’t need every todo the user has ever created, we just need the todos they are currently viewing. So where does the user data live? We solved this problem along time ago, data lives in a Database or Remote Server.

Redux is the minimum currently active application state and the database/server is the source of truth of all the user's data. With this knowledge lets rewrite the todo example with an async action creator.

const addTodo = todo => async (dispatch, getState) => {
  dispatch(resetTextInput());

  await api.post("/todos", todo);

  const {filter} = getState();

  const result = await api.get(`/todos?filter=${filter}`);

  dispatch(updateVisableTodos(result.todos));
  dispatch(updateTotal(result.total));
};

When a user creates a new todo we send it to the server to be stored, and then we query the API to get the updated list of todos. If this was an offline application we would save it in localstorage. What happens when the user changes the filter?

const changeFilter = newFilter => async dispatch => {
  dispatch(changeFilter(newFilter));

  const {filter} = getState();

  const result = await api.get(`/todos?filter=${filter}`);

  dispatch(updateVisableTodos(result.todos));
  dispatch(updateTotal(result.total));
};

I find most of the application logic lives in the async action creators, since reducers have to be pure and synchronous. I extract much of this logic into a repository.

const TodoRepository = {
  addTodo: todo => api.post("/todos", todo),
  getTodos: filter => api.get(`/todos?filter=${filter}`)
};

I challenge you to look at your Redux state and see how much state you have that is irrelevant to what the user is currently doing.

Other examples

A book reading app, while the user is reading a book the application state is: Page number, total pages, font size, current page text. We don’t store every book the user has ever read or may read in Redux and every page of the book.
A shopping app, while the user is searching for Coke, the application state is: The search term Coke, number of results, and the titles of results. We don’t store every product in the inventory in Redux nor the product details.

Redux reimplemented in 12 lines of code

Dale L. Jefferson — Thu, 30 May 2019 21:28:02 +0000

I like to reimplement libraries I use, this allows me to better understand how they work, below is my minimal implementation of Redux.

const createStore = reducer => {
  let onChange;
  let state = reducer(undefined, {});
  return {
    getState: () => state,
    subscribe: fn => (onChange = fn),
    dispatch: action => {
      state = reducer(state, action);
      onChange();
    }
  };
};

This works with the example on the Redux homepage below.

const counter = (state = 0, action) => {
  switch (action.type) {
    case "INCREMENT":
      return state + 1;
    case "DECREMENT":
      return state - 1;
    default:
      return state;
  }
};

const store = createStore(counter);

store.subscribe(() => console.log(store.getState()));

store.dispatch({type: "INCREMENT"}); // 1
store.dispatch({type: "INCREMENT"}); // 2
store.dispatch({type: "DECREMENT"}); // 1

Obviously this only has a fraction of the real Redux API.

Class properties with React

Dale L. Jefferson — Thu, 30 May 2019 21:24:07 +0000

Dealing with this binding in JavaScript can be a real pain. In this article, I will show you three ways to avoid binding issues. Class Properties is the new JavaScript syntax for creating handler functions that have the correct this binding.

Anonymous Arrow Functions

This creates a new function on every render potentially invalidating any efforts to memorise in Button.

class AwesomeProject extends Component {
  constructor() {
    super();

    this.state = {n: 0};
  }

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

  render() {
    return <Button onPress={() => this.onPress()} />;
  }
}

Bind

The same function is reused on every render this is the ES6 best practice.

class AwesomeProject extends Component {
  constructor() {
    super();

    this.state = {n: 0};
    this.onPress = this.onPress.bind(this);
  }

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

  render() {
    return <Button onPress={this.onPress} />;
  }
}

Class properties

We remove the need for a constructor and avoid manually binding the handler. I personally think this is the cleanest way of doing this.

class AwesomeProject extends Component {
  state = {n: 0};

  onPress = () => {
    this.setState({n: this.state.n + 1});
  };

  render() {
    return <Button onPress={this.onPress} />;
  }
}

Async/Await with React Lifecycle methods

Dale L. Jefferson — Thu, 30 May 2019 21:19:41 +0000

If you are like me you will also end up doing a lot of asynchronous work in componentWillMount/componentDidMount. This article will show you how to use Async/Await with React's Lifecycle events. React’s lifecycle methods can return any value, including a promise.

Promise Version

componentDidMount() {
  fetch('https://example.com')
    .then((res) => res.json())
    .then((something) => this.setState({something}))
}

Async/Await Version

async componentDidMount() {
  const res = await fetch('https://example.com')
  const something = await res.json()

  this.setState({something})
}

Note: if you do return a promise from the lifecycle methods it will be not be awaited.

I personally find the Async/Await version much easier to read.

Full example (React Native)

class AwesomeProject extends Component {
  state = {};

  setStateAsync(state) {
    return new Promise(resolve => {
      this.setState(state, resolve);
    });
  }

  async componentDidMount() {
    StatusBar.setNetworkActivityIndicatorVisible(true);

    const res = await fetch("https://api.ipify.org?format=json");
    const {ip} = await res.json();

    await this.setStateAsync({ipAddress: ip});

    StatusBar.setNetworkActivityIndicatorVisible(false);
  }

  render() {
    return (
      <View style={styles.container}>
        <Text style={styles.welcome}>
          My IP is {this.state.ipAddress || "Unknown"}
        </Text>
      </View>
    );
  }
}