DEV Community: Dan Homola

Point-free gotchas in JavaScript

Dan Homola — Mon, 26 Feb 2018 10:41:48 +0000

Note: this post was originally published on my Medium profile

I am a big fan of functional programming, I enjoy the conciseness of it and it fits my way of thinking better. I also like clean code with as few redundancies as possible. Having said that, it should come as no surprise that point-free (sometimes also called tacit) style appeals to me. Over the last few days I came across several gotchas when applying this style in JavaScript and decided to write them down.

What is point-free style

As Wikipedia states:

[Point-free] is a programming paradigm in which function definitions do not identify the arguments (or "points") on which they operate.

This may seem weird at first, but let's use a simple example. Assume we have a function that takes a string and returns that string with the first letter capitalised. Next, we have an array of strings that we all want to capitalise. This is a simple use case for the map function:

const capitalise = str =>
    str && str.charAt(0).toLocaleUpperCase() + str.substr(1);

const words = ["foo", "bar", "baz"];

// logs [ 'Foo', 'Bar', 'Baz' ]
console.log(words.map(w => capitalise(w)));
// logs [ 'Foo', 'Bar', 'Baz' ]
console.log(words.map(capitalise));

Notice the second map use, it does not state the name of the argument and does not create a new function. The reason this works is that map calls its first argument as a function taking three arguments:

the item of the array to process (this is the only mandatory parameter),
the index of that item,
the whole array being processed

Out capitalise function happens to also take the item to be processed as its first (and only) argument and so it works when used point-free in this case.

There are more uses for this style and we will see them as we go through the article.

Gotcha #1: Function taking more parameters than you expected

The first gotcha comes from the fact that you can call a function in JavaScript with as many arguments you want – be it too few or too many.

In case you provide too few arguments, those you haven't provided are set to their default value (which is undefined unless otherwise specified).

In case you provide too many arguments, the function ignores the excessive ones (unless it uses the arguments object).

This is probably not new to you, in the context of point-free it can lead to some unexpected results, though.

Let's take the simplest of examples: write a function that takes an array of strings and returns the numeric values of the items. For the sake of an example we assume the input is correct. Simple enough, there is Number.parseFloat for that:

const nums = ["25", "45", "11"];
// logs [ 25, 45, 11 ]
console.log(nums.map(num => Number.parseFloat(num)));
// logs [ 25, 45, 11 ]
console.log(nums.map(Number.parseFloat));

As we can see, the point-free version works like a charm.

Well, what if someone told us the numbers are always integers and we don't have to parse them as floats? Then we would swap the Number.parseFloat for the Number.parseInt, right?

// logs [ 25, 45, 11 ]
console.log(nums.map(num => Number.parseInt(num)));
// logs [ 25, NaN, 3 ]
console.log(nums.map(Number.parseInt));

Whoa, what is that? The point-free version behaves rather strange all of a sudden.

The reason for this is that while Number.parseFloat only takes one argument – the string to parse – Number.parseInt takes an additional optional argument – the radix of the number to be output (for example 16 for hexadecimal strings). Thus when used in a map like that this is what actually happens:

console.log(nums.map((item, index, array) =>
    Number.parseInt(/* string: */item, /* radix: */index, array)));

As we can see the radix argument of Number.parseInt is set using the index of the current item. That explains the 3 output for the 11 input as 3 is 11 in binary.

This is the first type of issue that can arise from point-free in JavaScript: functions taking more arguments than you expect.

There is no fool-proof way to protect yourself against this other than using point-free only with functions you know the signature of and know are not going to change, otherwise your code can break unexpectedly.

Gotcha #2: Unexpected `this`

This one popped up in a job interview I took not too long ago:

const obj = {
    message: "Hello",
    getMessage() {
        console.log(this.message);
    },
};

// Broken
setTimeout(obj.getMessage, 0);

The question was to fix the error.

One would probably expect "Hello" to be output (I know I did). Yet, undefined is output to the console.

The reason for this is the way setTimeout executes the callback function. The callback is executed in a different execution context and if this is not set explicitly, it will be set to the global object. And as global (or window if run in browser) does not have a message member our example prints undefied.

There are two way to fix this:

// Fix A - closure
setTimeout(() => obj.getMessage(), 0);
// Fix B - binding
setTimeout(obj.getMessage.bind(obj), 0);

The first one uses a closure to implicitly set this of the getMessage call to the proper value.

The second (point-free) one makes use of the bind method to set the value of this explicitly.

There is another example of a code that seems to be alright – simple regular pattern use:

const isActivationCode = /^\d{4}-\d{4}-\d{4}$/.test;
console.log(isActivationCode("1234-5678-1234"));

However this ends up throwing a TypeError saying:

Method RegExp.prototype.test called on incompatible receiver undefined

or a bit more helpfully in Safari:

RegExp.prototype.test requires that |this| be an Object

Again, the problem is that this has an unexpected value (in this case undefined). The solutions are the same as in the previous case:

// Fix A - closure
const isActivationCodeClosure = code => /^\d{4}-\d{4}-\d{4}$/.test(code);

// Fix B - binding
const regex = /^\d{4}-\d{4}-\d{4}$/;
const isActivationCodePointFree = regex.test.bind(regex);

// logs true
console.log(isActivationCodeClosure("1234-5678-1234"));
// logs true
console.log(isActivationCodePointFree("1234-5678-1234"));

The point to take here is that if the function you want to call point-free makes use of this, you should be very aware that it is set to what you expect.

Conclusion

As much as point-free style is useful in other (functional) languages, in JavaScript it often brings problems that might not be worth the conciseness it brings. I still use it sometimes when the function called is under my control. After these experiences I will be more careful with it, though.

React Higher-Order Components in TypeScript made simple

Dan Homola — Wed, 14 Jun 2017 17:31:04 +0000

Note: this post was originally published on my Medium profile

When refactoring a Higher-Order Component (HOC) in a TypeScript project at work, there was some confusion regarding how to write them properly. After a discussion with my friend and colleague Marek, I decided to write this guide for future reference. I hope it helps you too.

What are HOCs?

As per the official docs, HOC is

a higher-order component is a function that takes a component and returns a new component

They are used for extracting patterns common to multiple components into a single place, thus making the code more DRY. The most “famous HOC is connect from the react-redux package.

How to write them?

For the purpose of this article, we will create out own HOC ClickCounted that counts the number of clicks and passes that count as a prop to the child component (we call this the wrapped component). It also displays the current number of clicks itself and can be styled using the style prop, similarly to a div. Finally, we can configure whether the component console.logs on each click. These attributes were chosen to illustrate all the aspects of HOCs while keeping the HOC as simple as possible.

Props

There are three types of props we need to consider when creating a HOC: OriginalProps, ExternalProps and InjectedProps.

OriginalProps are props of the wrapped component. They are passed straight through, the HOC does not know anything about them.
ExternalProps are props of the component created by the HOC. They are not passed to the wrapped component. There don't have to be any.
InjectedProps are props that the HOC adds to the wrapped component. They are calculated based on the HOC state and ExternalProps. There don't have to be any.

The relations between the prop types are shown on the following diagram

As we can see, the props of the resulting component are of type OriginalProps & ExternalProps (i.e. union of the two).

For our illustrative ClickCounted HOC, the prop types are:

interface ExternalProps {
    style?: React.CSSProperties;
}

export interface InjectedProps {
    clickCount: number;
}

The InjectedProps need to be exported because we need them when using the HOC (see later). The state of the HOC is simple, just the count of the clicks:

interface State {
    clickCount: number;
}

Options

As stated before, HOC is a function that takes a component and returns a component.

Component => Component

While this is true, many HOCs take the form of curried HOC factories (like the mentioned connect from react-redux) that take a configuration object and return a HOC:

options => Component => Component

These options are used to modify the HOC itself providing some static configuration values. Note that those values do not have access to the props or states, they are evaluated only once when the HOC factory is called. If you need to interact with props or states from here, the only way to do it is to specify options as functions, that take the props or states as arguments.

For ClickCounted the options are simple – a flag indicating whether to console.log on click:

interface Options {
    debug?: boolean;
}

Putting it all together

Having declared all the necessary types, we can write our HOC signature:

export const clickCounted = ({ debug = false }: Options = {}) =>
    <TOriginalProps extends {}>(
        Component: (React.ComponentClass<TOriginalProps & InjectedProps>
                  | React.StatelessComponent<TOriginalProps & InjectedProps>)
    ) => {
        // body
    }

This may seem a bit complex at first glance, but let's dissect it part by part.

({ debug = false }: Options = {}) =>

The first line starts a lambda function, that takes a single argument, that is desctructured into its keys (in this case the debug key) while providing the default values for them. This means the caller can call this function either without arguments, or with a single Options argument and when a value for a particular key is not provided, the specified default is used.

<TOriginalProps extends {}>(
        Component: (React.ComponentClass<TOriginalProps & InjectedProps>
                  | React.StatelessComponent<TOriginalProps & InjectedProps>)
    ) =>

The second part is a generic lambda function with one type parameter TOriginalProps that represents the OriginalProps type discussed above. The extends {} is only a syntactic noise to specify this is meant to be a generic lambda and not a JSX component tag. The lambda takes only one argument called Component (note its name starts with a capital letter, this is intentional, we'll se the reason later in the text) that can be one of two types:

React.ComponentClass<TOriginalProps & InjectedProps> — React class component with props of the TOriginalProps & InjectedProps type
React.StatelessComponent<TOriginalProps & InjectedProps> — Functional stateless component with the same props type

The props type corresponds to the diagram where two types of props are passed to the wrapped component. Now that we have the signature, all that's left is to implement the HOC:

export const clickCounted = ({ debug = false }: Options = {}) =>
    <TOriginalProps extends {}>(
        Component: (React.ComponentClass<TOriginalProps & InjectedProps>
                  | React.StatelessComponent<TOriginalProps & InjectedProps>)
    ) => {
        type ResultProps = TOriginalProps & ExternalProps;
        const result = class ClickCounted extends React.Component<ResultProps, State> {
            static displayName = `ClickCounted(${Component.displayName || Component.name})`;

            constructor(props: ResultProps) {
                super(props);
                this.state = {
                    clickCount: 0,
                };
            }

            handleClick = (e: React.MouseEvent<HTMLDivElement>) => {
                if (debug) {
                    console.log('Clicked');
                }
                this.setState(state => ({ clickCount: state.clickCount + 1 }));
            }

            render(): JSX.Element {
                return (
                    <div onClick={this.handleClick} style={this.props.style}>
                        <span>Clicked {this.state.clickCount} times</span>
                        <Component {...this.props} {...this.state} />
                    </div>
                );
            }
        };

        return result;
    };

First, we define the type alias for the resulting component's props – the TOriginalProps & ExternalProps to simplify its reuse. Then we define the class of the resulting component as having this type of props and appropriate type of state.

We introduce a static property called displayName that helps to identify the component while debugging (in ReactDev tools for example) by telling us the name of the wrapped component as well. Next, we define a simple constructor where we initialise the state.

The handleClick method is defined that increments the click count and if debug was true in options it writes a message to console.

Finally, render method is specified returning a div with style prop and a click handler specified. In the div a span with the current click count is rendered as well as the wrapped component. This is the reason the Component argument starts with a capital letter, otherwise we wouldn't be able to render it like this. Props and state are passed to it with whatever was in the OriginalProps along with the clickCount from the HOC state.

Using the HOC

To illustrate how to use our HOC, we create a Demo component, that displays a different text depending on the amount of clicks and a custom message.

import { clickCounted, InjectedProps } from './ClickCounted';

interface DemoProps {
    text: string;
}

const DemoComponent = (props: DemoProps & InjectedProps): JSX.Element => {
    return (
        <div>
            <p>{props.text}</p>
            <p>
                {
                    props.clickCount >= 5
                        ? 'Easy there!'
                        : 'Bring it!'
                }
            </p>
        </div>
    );
};

export const Demo = clickCounted()(DemoComponent);
export const DemoWithDebug = clickCounted({ debug: true })(DemoComponent);

Notice the type of the props argument – it consists of DemoProps (i.e. OriginalProps) and the InjectedProps. That way it can use props passed either from the HOC or the consumer directly.

Then we export two wrapped versions of the component – one without debug logs and one with them. We can then use them like any other component and thanks to TypeScript benefit from nice things like type checking and code completion.

Conclusion

On a simple example we discussed various aspects of HOCs in TypeScript. There is a GitHub repository with this demo where you can download and play with it to familiarise yourself with the concepts better:

no23reason / typescript-hoc-tutorial

Code samples for my “React Higher-Order Components in TypeScript made simple” article

React HOC demo in TypeScript

This is repo related to my Medium article on React Higher–Order Components.

How to use

To try it yourself, just clone this repository and then run

yarn install
yarn start

For the best experience, I recommend using Visual Studio Code.

Acknowledgements

This project was bootstrapped with Create React App, using the wonderful TypeScript-React-Starter project.

View on GitHub

Also, all the concepts can be put together to make a simple HOC template (just copy it and fill in the blanks indicated by the comments):

import * as React from 'react';

// State of the HOC you need to compute the InjectedProps
interface State {
}

// Props you want the resulting component to take (besides the props of the wrapped component)
interface ExternalProps {
}

// Props the HOC adds to the wrapped component
export interface InjectedProps {
}

// Options for the HOC factory that are not dependent on props values
interface Options {
    key?: string;
}

export const yourHocFactoryName = ({ key = 'Default value' }: Options = {}) =>
    <TOriginalProps extends {}>(
        Component: (React.ComponentClass<TOriginalProps & InjectedProps>
            | React.StatelessComponent<TOriginalProps & InjectedProps>)
    ) => {
        // Do something with the options here or some side effects

        type ResultProps = TOriginalProps & ExternalProps;
        const result = class YourComponentName extends React.Component<ResultProps, State> {
            // Define how your HOC is shown in ReactDevTools
            static displayName = `YourComponentName(${Component.displayName || Component.name})`;

            constructor(props: ResultProps) {
                super(props);
                this.state = {
                    // Init the state here
                };
            }

            // Implement other methods here

            render(): JSX.Element {
                // Render all your added markup
                return (
                    <div>
                        {/* render the wrapped component like this, passing the props and state */}
                        <Component {...this.props} {...this.state} />
                    </div>
                );
            }
        };

        return result;
    };

I hope this article is useful to you. In case of any questions, feel free to comment.

Don’t pay the for-loop tax

Dan Homola — Sat, 03 Jun 2017 08:27:48 +0000

Note: this post was originally published on my Medium profile

Once, when doing code review on a TypeScript project at my work, I came across several instances when a colleague of mine used a for loop, even though it wasn’t necessary (i.e. a more readable declarative equivalent was available). In a joke I stated that we should impose a “for-loop tax for every loop used unnecessarily.
It made me think however, why so many people tend to go for the longer and more error prone solution with the loop and I got to the following conclusion: Nearly every (mainly) imperative programming language course/book I ever took/read (be it Pascal and C# in high school or C/C++ and Wolfram Mathematica in college) contained a section like

“These are the loops available, this is how you write them and this is how you use them to solve these basic problems”.

There is an important point to note here: they only teach how to write a loop but scarcely explain why you would need one (or sometimes even worse they state that loop based solutions are the best ones). For future reference, I decided to write this “cookbook of the main types of situations where loops are often used and how they can be replaced. All the examples will be written using JavaScript as it is very popular, but the rationales behind the examples can be used in many other languages as well.

#1: I need to go over an array and get a single value as a result

We start with the simplest of problems:

Given an array of numbers, return the sum of its elements.

const sum = (array) => {
    let result = 0;
    for (let i = 0; i < array.length; i++) {
        result += array[i];
    }
    return result;
}

const numbers = [5, 25, 8, 18];
console.log(sum(numbers)); // logs 56

If you attended similar courses as me, you surely recognise this code. Create a temporary variable, initialise it with zero and using a for loop iterate over the array returning the final value of the variable. There are some problems though:
For something as simple as a sum of an array, 7 lines of code seem quite a lot.
You must handle the bounds of the iteration yourself. In other words you must know to start at zero (in JavaScript, many other languages have 1-based arrays – Wolfram Mathematica for example) and end at i that is strictly less than the length of the array (not less than or equal). This is prone to errors especially if your work in many languages at the same time.

const sum = (array) => array.reduce(
  (total, current) => total + current,
  0);

const numbers = [5, 25, 8, 18];
console.log(sum(numbers)); // logs 56

The solution that remedies both those problems is to use the reduce function (in other languages also called fold or aggregate). In a single expression we iterate over each of the array elements adding them together (stating the sum’s default and initial value is zero). Notice there is no mention of the iteration bounds, it just guarantees that it will go over all the elements from first to last.

#2: I need to create a new array from a given one and transform all the elements

This is another common problem, let’s illustrate it with this example:

Given the array of prices, return a new array with the prices n % lower.

const discount = (originalPrices, discountAmount) => {
    const multiplier = 1 - discountAmount;
    // we must clone the array
    let result = new Array(originalPrices);
    for (let i = 0; i < originalPrices.length; i++) {
        result[i] = originalPrices[i] * multiplier;
    }
    return result;
}

const prices = [5, 25, 8, 18];
console.log(discount(prices, 0.2)); //logs [ 4, 20, 6.4, 14.4 ]

The loop-based way to do this is pretty similar to the sum code. There is one additional problem though: in order to not destroy the input array, we must clone it first and then transform the values in the new array. This can easily be forgotten introducing a potentially unwanted side effect in the application.

const discount = (originalPrices, discountAmount) => {
    const multiplier = 1 - discountAmount;
    return originalPrices.map(price => price * multiplier);
}

const prices = [5, 25, 8, 18];
console.log(discount(prices, 0.2)); // logs [ 4, 20, 6.4, 14.4 ]

The cloning problem can be avoided altogether using the map function. For a given array it returns a new array where each element is the corresponding element in the original array transformed using the provided function (in our case multiplied by the discount multiplier).

#3: I need the numbers from m to n

Another common situation where loops are used is when generating linear ranges as an input for further transformations. A classic example is:

Return an array of the first n squares

const squaresBad = (n) => {
    let result = [];
    for (let i = 1; i <= n; i++) {
        result.push(i * i);
    }
    return result;
}

const squares = (n) => {
    let result = new Array(n);
    for (let i = 1; i <= n; i++) {
        result[i - 1] = i * i;
    }
    return result;
}

console.log(squaresBad(5)); // logs [ 1, 4, 9, 16, 25 ]
console.log(squares(5)); // logs [ 1, 4, 9, 16, 25 ]

This is a problem that can be solved very badly when using loops. The first naïve solution suffers from the problem that it pushes a new element to an array every iteration. This expands the array and may cause it to reallocate in memory being slow (benchmark).
The second approach instantiates the array of correct size beforehand avoiding this problem, but we can easily make a mistake when assigning the current value (see the result[i – 1] expression in the second for-loop).


const range = require("lodash.range")
const squaresLodash = (n) => range(1, n + 1).map(
    (n) => n * n);

const squares = (n) => [...Array(n).keys()].map(
    (n) => (n + 1) * (n + 1));

console.log(squaresLodash(5)); // logs [ 1, 4, 9, 16, 25 ]
console.log(squares(5)); // logs [ 1, 4, 9, 16, 25 ]

While there is no native way to generate a range of integers in JavaScript there are two ways to tackle this problem in a more declarative ways with map: using the lodash.range function, or a clever ES2015 syntax trick (source).

#4: I need to do something with side effects n times

The final use case of loop I want to discus here is invoking a method with side effects more than once. As Edsger Dijkstra famously said:

Two or more, use a for

The simplest example to illustrate this case is:

Console.log the string “Hello world n times

This is in my opinion the only justifiable use case for loops in JavaScript (not counting infinite loops) as it is the most concise and performant way (at least until Tail Call Optimisation arrives to most environments).
However, I would strongly recommend to abstract this into a helper function to restrict the loop to a single place.

const doNTimesLoop = (n, f) => {
    for (let i = 1; i <= n; i++) {
        f(i);
    }
}

const doNTimesRec = (n, f) => {
    const body = (m) => {
        if (m > n) return;
        f(m);
        return body(m + 1);
    }

    return body(1);
}

//both log "Hello world" five times
doNTimesLoop(5, x => console.log("Hello world"));
doNTimesRec(5, x => console.log("Hello world"));

As we can see in the examples (both calling the provided function with numbers from 1 to n), the iterative version is shorter and simpler to write. Also the “loop-free version would cause a stack overflow on environments without Tail Call Optimisation.

Conclusion

On four elementary situations, we described how to use declarative style to replace loops and therefore make our code shorter and less error-prone.
Do you use loops? Do you disagree with any of the solutions? Comment please!

DEV Community: Dan Homola

Point-free gotchas in JavaScript

What is point-free style

Gotcha #1: Function taking more parameters than you expected

Gotcha #2: Unexpected this

Conclusion

React Higher-Order Components in TypeScript made simple

What are HOCs?

How to write them?

Props

Options

Putting it all together

Using the HOC

Conclusion

no23reason / typescript-hoc-tutorial

Code samples for my “React Higher-Order Components in TypeScript made simple” article

React HOC demo in TypeScript

How to use

Acknowledgements

Don’t pay the for-loop tax

#1: I need to go over an array and get a single value as a result

#2: I need to create a new array from a given one and transform all the elements

#3: I need the numbers from m to n

#4: I need to do something with side effects n times

Conclusion

Gotcha #2: Unexpected `this`