Forem: Alex Khismatulin

Pure Functions Explained for Humans

Alex Khismatulin — Tue, 21 Dec 2021 16:00:52 +0000

Start leveraging pure functions TODAY

First things first: you don't have to write code in a functional style to leverage pure functions.

This powerful tool makes it easier to read, reuse, maintain, and test code. Nobody wants to lose any of these benefits because their code is not functional. And you shouldn't neither. So get known to the concept now to make your code even better, functional or not.

 Good news: it is extremely easy to understand and start using pure functions.

A simple definition

A function can be called pure if it returns the same output given the same input every time you call it, doesn't consume or modify other resources internally, and doesn't change its inputs.

Ok, this seems to sound way easier than what we usually see when it comes to pure functions. Now let's break it down and see what each part of this definition means and how those parts are named in the professional lexicon.

Returns the same output given the same input

This one means exactly what it says. Every time we call a function with a constant value, it has to return the same result. 

Let's consider 2 examples

We will create addFive and addSomething functions and see how they follow(or don't follow) the rule. But before we move forward, can you guess which one violates the rule and why?

`addFive` function

const seven = addFive(2); // returns 7

If we have an addFive function, we always expect that addFive(2) would return 7. No matter what happens with the rest of a program, when, or where in the code we call addFive(2), it always gives us 7.

`addSomething` function

const randomNumber = addSomething(2); // returns a random number

As opposed to addFive, there's the addSomething function. As we can guess from the name, it adds an unknown number to a passed value. So if addSomething(2) call returned 6, we have no guarantee that every time we call addSomething(2) it would return 6. Instead, this will be an arbitrary number that we can't predict at the moment of calling the function unless we know how the internal random number generator works. This function does not guarantee to return the same output given the same input.

What does that mean for us?

At this point, we can definitely tell that addSomething is not a pure function. But we also cannot state that addFive is a pure function yet. To do this, we need to check if it satisfies other conditions.

Doesn't consume or modify other resources internally

To explore this topic, we need to think about how the functions from the above examples would be implemented.

First, our pure function candidate, addFive:

function addFive(number) {
  return number + 5;
}

As we can see, the function does exactly and only what it says and what we expect it to do. Nothing else other than adding 5 a passed number is happening. addFive passes this check. 

Now, let's define the addSomething function that is already known as impure:

let callCounter = 0;

function addSomething(number) {
  callCounter = callCounter + 1;
  const isEvenCall = callCounter % 2 === 0;

  if (isEvenCall) {
    return number + 3;
  } else {
    return number + 4;
  }
}

This function has an external variable that stores the number of times the function was called. Then, based on the counter, we check if it's an even call and add 3 if it is, or add 4 if it's not. This call counter is an external state that the addSomething function uses to calculate the results. Such states fall under the definition of side effects.

Side effect is a modification of any external state, consumption of dynamic external values, or anything a function does outside of the work related to calculating the output.

In our case, addSomething modifies and uses callCounter to calculate the final output. This is a side effect. How could we fix addSomething to clean it up from side effects?

If we can't consume or modify an external variable, we need to make it an input:

function addSomething(number, isEvenCall) {
  if (isEvenCall) {
    return number + 3;
  } else {
    return number + 4;
  }
}

Now we control if it's an even or odd call from outside, and our addSomething function becomes pure. Whenever we call it with the same pair of inputs, it would return the same number.

Don't worry if you still don't quite understand what can be a side effect. We will see more examples of side effects a bit later.

Doesn't change its inputs

For this part we need to create the getFullName function:

function getFullName(user) {
  user.firstName = user.firstName[0].toUpperCase() + user.firstName.slice(1).toLowerCase();
  user.lastName = user.lastName[0].toUpperCase() + user.lastName.slice(1).toLowerCase();

  return user.firstName + ' ' + user.lastName;
}

The function takes an object with first and last names. Then it formats these properties in the object so they start with a capital letter and all other letters are lowercased. In the end, the function returns a full name.

If we skip over potential edge cases, our function will return the same output every time we pass an object with the same values. The function doesn't consume or modify any external resources neither and only calculates a full name. So, does that mean it's pure?

No. And here's why.

The object we pass to getFullName is a referential type. When we change its properties inside the function, the changes get reflected in the original object outside the function. In other words, we mutate our inputs.

// note that all letters are lowercased
const user = {
  firstName: 'alex',
  lastName: 'khismatulin'
}; 

const fullName = getFullName(user); // returns "Alex Khismatulin"

// Logs "Alex Khismatulin", capitalized. Object is modified.
console.log(user.firstName + ' ' + user.lastName);

Even though primitive vs reference types separation sounds complex, in practice, it is not. Spend a few minutes to check it out. There are plenty of good posts on the topic. Tip: add your preferred language to the end of the search query to get more contextual results. Here's an example for JavaScript.

Input mutations are also considered side effects. We change inputs that come from outside, so we're still changing an external resource but in a different way.

"Same" doesn't always mean "equal"

As we just touched referential types, we should also note that even though pure functions always return the same output given the same inputs, this doesn't mean that all inputs and outputs must be equal to each other. That is possible when a function takes or returns a referential type. Look at this example:

function createUser(firstName, lastName) {
  return {
    firstName: firstName,
    lastName: lastName,
  };
}

This function takes first and last names and creates a user object. Every time we pass the same names, we get an object with the same fields and values. But objects returned from different function calls are not equal to one another:

const user1 = createUser('Alex', 'Khismatulin');
const user2 = createUser('Alex', 'Khismatulin');

console.log(user1.firstName === user2.firstName); // true
console.log(user1.lastName === user2.lastName); // true
console.log(user1 === user2); // false, objects are not equal

We see that firstName from user1 is equal to firstName from user2. lastName from user1 is equal to lastName from user2. But user1 is not equal to user2 because they are different object instances.

Even though the objects are not equal, our function is still pure. The same is applied to inputs: they don't have to be literally equal to produce the same output. It's just not a 100% correct word used in the first place.

It's "identical", not "same" or "equal"

The word "identical" describes what we expect from pure functions best. Values such functions take or return don't necessarily have to be equal, but they have to be identical.

Other side effects

So, what can be a side effect? Here are a few examples:

Querying or changing external variables and states
Mutating inputs
DOM interaction
Network calls
Calling other impure functions

The list goes on and on, but you get the idea. Anything unrelated to computing output or relies on any dynamic values other than inputs is a side effect.

Moreover, console.log is also a side effect! It interacts with the console, thus doing work unrelated to computing an output. No worries, usually console logs have no impact, so this rule is omitted when debugging code.

Final definition

Now, as we have all the pieces of our simple definition uncovered, we a ready to derive a smarter definition of a pure function:

A function can be called pure if it returns identical output given identical input every time it is called and has no side effects.

Awesome! But there's one thing that might've been bugging you while reading.

What should I do when I do need side effects?

Some things are impure by their nature. At the end of the day, this is what programming is about – transforming data is our bread and butter.

Side effects are imminent. But when we have to deal with them, we should strive to isolate them as much as possible and separate from the code that executes pure operations.

Here's a pretty widespread Redux selector pattern. We have a code that gets a snapshot of Redux state and a selector function that knows how to get a specific value from that state:

function getUserById(state, userId) {
  const users = state.users.list || [];
  const user = users.find(user => user.id === userId);
  return user;
}

const state = store.getState();
const user = getUserById(state, '42');

You don't need to know anything about Redux to understand the example. There's no magic going on here. store.getState() in our case only returns an object that holds some values.

In this example, the values in the store change dynamically and are out of our control. We secure the getUserById value selector function from any third-party states and make it only rely on its inputs.

You see the pattern: separate the code that has to deal with impure data sources or to produce side effects from the code that gives linear output based on its inputs.

What are the pros?

Reusability

Let's come back to the Redux selector example. Other than just returning a user from state, we can update the code and break it down into a few pure functions:

function findUserById(list, userId) {
  const user = users.find(user => user.id === userId);
  return user;
}

function getUsersFromState(state) {
  const users = state.users.list || [];
  return users;
}

Now we have one function that knows how to get users from state and another one that knows how to find a user by id in a list of users. That means we can reuse findUserById in other parts of the app where we use the same shape for the user object:

// find a user in the store users
const state = store.getState();
const users = getUsersFromState(state);
const user = findUserById(users, '42');

// find a user in the lottery players list
const lotteryPlayers = getLotteryPlayers();
const winnerId = (Math.random() * 100).toFixed();
const winner = findUserById(users, winnerId);

Both cases leverage findUserById because it does one small thing and has no unpredictable dependencies. If we ever needed to change the field name that holds user id, we would need to do that in just one place.

Purity gives us space to create functions that are not bound to specific data sources or context in which functions are called.

Testing

We're going come back to the Redux selector example one more time and imagine that we decided to get state from the store right inside the selector function:

function getUserById(userId) {
  const state = store.getState();
  const users = state.users.list || [];
  const user = users.find(user => user.id === userId);
  return user;
}

const user = getUserById('42');

What would it cost us to add a test that validates this function? Well, we would need to do some dark magic to mock store.getState():

test('Should return user with correct id', function() {
  store = {
    getState() {
      return {
        users: {
          list: [{ id: '42' }],
        },
      };
    }
  };

  const user = getUserById('42');
  expect(user.id).toBe('42');
});

You see what's going on? We had to mock the whole Redux store just to test one small selector. More importantly, the test must know how the state is retrieved from the store. Imagine what would we need to do to test a more complex one? What would happen if we decided to replace Redux with some other state management tool?

To see the difference, here's a test for the original pure version:

test('Should return user with correct id', function() {
  const state = {
    users: {
      list: [{ id: '42' }],
    },
  };

  const user = getUserById(state, '42');
  expect(user.id).toBe('42');
});

Now we don't need to think about what method is used to return a state from the store and mock the whole thing. We just use a state fixture. If we ever change a state management tool, this will not affect the tests because they only know what the state's shape is, not how it's stored.

They make the code easier to consume

Last but not least, writing pure functions forces us to create smaller, more specialized functions that do one small thing. The code is going to become more organized. This, in turn, will increase readability.

In the end

Pure functions alone are not going to make your code perfect. But this is a must-have part of your toolset if you want to be a professional in what you do. Every little step moves you to a bigger goal, and pure functions are not an exception. Employ this concept and make your code a little better today.

I hope you learned something today. Make this topic a small piece in the strong foundation of your success. Thank you for reading!

P.S.

If you like occasional no-bullshit web shorties, you should definitely drop me a line on Twitter. Feel free to tag me if you want to discuss this article, and I will make sure to join the conversation!

Post editor: pre-publish confirmation

Alex Khismatulin — Sun, 11 Apr 2021 16:38:01 +0000

Hey everyone! Does anybody else have a problem of accidentally publishing a post instead of saving a draft? It happened to me two times past two weeks. The action is immediate. You hit the publish button in the editor, realize that it was the wrong one in a moment, but it's too late: your post is published.

I guess that could be a good idea to show any kind of a confirmation step before actually publishing: a modal, a 5-second undo option, anything that would save from unintentional action.

What do you think?

TS + React: interface vs type for props

Alex Khismatulin — Sun, 11 Apr 2021 16:22:32 +0000

Hey all!

TypeScript 4.3 Quickly: My TOP-3 Updates

Alex Khismatulin — Mon, 05 Apr 2021 19:37:19 +0000

A few days ago Microsoft announced TypeScript 4.3 Beta. Here are 3 updates that I found the most interesting and a list of the rest of the updates. Let's go!

overrides + noImplicitOverrides compiler option

TypeScript now takes care of method names' safety when overriding parent class methods. When a method is marked with override, TypeScript will always make sure that a method with the same name exists in a base class. So if you make a change in the method name in the base class, you will be forced to also update it in the derived class. Neat!

But what if you forget to put override on a method? TypeScript's got a compiler option for you: with noImplicitOverrides enabled TypeScript will throw an error if you have a method with the same name in both base and derived classes:

class Base {
    show() {
        // ...
    }
}

class Derived extends Base {
    // TypeScript will throw an error
    // unless there's the "override" before the method name
    show() {
        // ...
    }
}

Different types for getter and setter

You don't have to limit getters and setters to the same type anymore.
Let's say you have a private field of type number. You want a setter for the field to accept both number and string, convert to number, and put the value into the private field. But you want a getter to always return number because the field can't be anything but number. This code would throw an error before 4.3 and now this is an acceptable way of typing getter and setter:

class IrresponsibleNumStorage {
    private _num = 42;

    // Before 4.3 TS would throw an error:
    // 'get' and 'set' accessor must have the same type.
    get num(): number {
        return this._num;
    }

    // Before 4.3 TS would throw an error:
    // 'get' and 'set' accessor must have the same type.
    set num(maybeNumber: number | string) {
        this._num = Number(maybeNumber);
    }
}

Import statement completions

This is not something that's going to be directly used in day-to-day coding, but it's going to have a huge impact on developer experience. Starting from version 4.3 TypeScript will provide a list of possible imports after just typing the import keyword. Just look at the demo by Microsoft:

Some IDE's already have similar functionality implemented from their side, but it's going to become more broad and consistent thanks to the native support by the TS language server.

What else?

Thank you for reading!

P.S. I'm new to Twitter and will be happy if you drop me a line there!

Quick Peek: React App Mounted on a Shadow DOM Root

Alex Khismatulin — Sun, 18 Oct 2020 11:56:37 +0000

Code first

import React, { FC } from "react";
import { render } from "react-dom";

const App = () => <div>React + Shadow DOM</div>;

const root = document.querySelector("#react-root");
root.attachShadow({ mode: "open" });

render(<App />, root.shadowRoot);

Play around in playground

What's this all about?

The code above is very similar to the way we usually mount React apps to the DOM. But there's one significant difference: we're creating a shadow DOM and mounting to its root a React app. Learn more about shadow DOM.

Use-cases

Isolate styles: an app will not be affected by any outer CSS that brings a good solution when you need styles isolation
WEB components: React apps can be mounted inside WEB components

Cons

Styles need to be stored in the shadow root
You might have issues with external libraries that access DOM elements inside an app through JS
Some payment processors don't support shadow DOM in the official clients

In the end

This definitely is not something that should be used on a daily basis but it's a good option when you need to implement behavior mentioned in use-cases.

I tried to make this post really short so feel free to ask any questions in the comments.

Thanks for reading!

P.S.

I started doing Twitter recently so I would be glad if you check the things I post there! Also, advise who in your opinion I need to follow from the tech!
Twitter

Is there a way to aggregate dev.to RSS feeds?

Alex Khismatulin — Mon, 07 Sep 2020 15:54:31 +0000

Hey everybody!

I want to avoid getting posts that have several tags I read through RSS more than once in my reader app. Let's say I read the following RSS feeds:
dev.to/feed/tag/webdev
dev.to/feed/tag/javascript
dev.to/feed/alexkhismatulin

If alexkhismatulin posts something with both webdev and javascript tags, the post appears three times in the reader app. I'm wondering if there's a way to subscribe to an aggregation. I imagine something like this:
dev.to/feed/?tags[]=webdev&tags[]=javascript&authors[]=alexkhismatulin

React Context: a Hidden Power

Alex Khismatulin — Mon, 25 May 2020 16:05:49 +0000

Last week I had to implement the new React Context API for a React 15 project. Migrating to React 16 was not the option due to a big codebase so I headed to React sources for references.
The first thing I noted was the second argument of the createContext function:

export function createContext<T>(
  defaultValue: T,
  calculateChangedBits: ?(a: T, b: T) => number,
): ReactContext<T> {

The second argument is not mentioned in the React docs so started discovering what that is. After some investigation I found out that there's an optimization that can be applied to React Context.

So what does it actually do?

React Context allows its consumers to observe certain bits of a bitmask produced by the calculateChangedBits function that can be passed as the second argument to createContext. If one of the observed bits changes, a context consumer gets re-rendered. If not, it's not going to do an unneeded re-render. Sounds great! Let's see how it works in practice.

Before we start

If you're not familiar with bitwise operators, check out this MDN page.

A Sample App

I created a simple Ice Cream Constructor app that has two selects and shows a list of available options based on selected values. The filter is a simple React Context that holds the state of selected values and provides an API for its consumers to get a current filter state and update it. You can check out the full demo here.

First of all, let's define an object that's going to map context consumers to bits they observe:

export default {
  fruit: 0b01,
  topping: 0b10,
};

0b is a binary prefix meaning that a number following after it is binary. By putting 1s and 0s we tell what bits are going to be observed. There won't be any observed bits if we put 0, and every bit is observed if we put all 1s. In our example we say that fruit is going to observe the first bit and topping is going to observe the second bit.

calculateChangedBits

Now Let's create a filter context:

import React from 'react';
import observedBitsMap from './observedBitsMap';

const calculateChangedBits = (currentFilter, nextFilter) => {
  let result = 0;

  Object.entries(nextFilter.filter).forEach(([key, value]) => {
    if (value !== currentFilter.filter[key]) {
      result = result | observedBitsMap[key];
    }
  });

  return result;
};

const initialValue = {
  filter: {
    fruit: 'banana',
    topping: 'caramel',
  },
};

export const FilterContext = React.createContext(initialValue, calculateChangedBits);

calculateChangedBits is passed as the second argument to React.createContext. It takes current context value and new context value and returns a value that represents changed context values that are changed.

unstable_observedBits

While result of calling calculateChangedBits represents the whole change, unstable_observedBits tells what particular bits of the whole change are going to trigger a context consumer update. It's passed as the second argument to React.useContext:

import React from 'react';
import observedBitsMap from './observedBitsMap';
import { FilterContext } from './FilterContext';

const FilterItem = ({ name, children }) => {
  const context = React.useContext(FilterContext, observedBitsMap[name]);

  const onChange = React.useCallback(
    (e) => {
      context.onFilterChange(e);
    },
    [context.onFilterChange],
  );

  return children({ name, onChange, value: context.filter[name] });
}

If you want to use a regular JSX Context.Consumer you can pass unstable_observedBits as a prop:

<FilterContext.Consumer unstable_observedBits={observedBitsMap[name]}>
...

If unstable_observedBits is passed, consumer is going to be updated only if the result of bitwise AND on what we got from calculateChangedBits's execution and unstable_observedBits is not equal to 0.

Let's see how it works:

Limitations

As you can see from the unstable_observedBits name, this is an unstable experimental feature. Every time a context value changes React shows a warning:

Also, there's a limitation on the number of bits that can be observed. It is restricted by the max integer size in V8 for 32-bit systems. This means that we can't effectively re-render observe more than 30 different consumers.

Conclusion

Even though React Context API provides a great optimization opportunity, I don't think it should be widely used. This whole thing is more about exploring what the library hides rather than finding something for usual usage. If you think that you want to apply this optimization in your project, ask yourself "why are my renders so slow that I need to use a deep optimization?" question first.

I guess that this feature is going to be used mostly in libraries even when it turns to stable. But I'm really interested in what direction would the implementation evolve.

Suggest a tool for wiring paper prototypes

Alex Khismatulin — Fri, 15 May 2020 17:05:12 +0000

Hey!
I have a bunch of hand-drawn screens and I want to make them interactive.

A perfect solution would have the following flow:

Upload screens(or take a photo) and name them
Mark interactive elements on a screen with some set of primitives and link them to another screen
Generate a link to the project for sharing

Update boolean state right with React Hooks

Alex Khismatulin — Mon, 11 May 2020 14:31:21 +0000

Recently I found a construction like this while doing code review:



const MyComponent = (props) => {
  const [isToggled, setIsToggled] = React.useState(false);
  const toggle = React.useCallback(() => setIsToggled(!isToggled));

  return ...;
};

Creating a boolean state and a toggle method for it is a pretty common use case. The spinnet is 100% correct in terms of functionality. But it could be better in terms of performance. Let's see how it can be improved.

So what's wrong?

First things first – useCallback does nothing in this implementation. Unless a dependencies array is passed as a second parameter, useCallback is not keeping the same reference to a callback through renders and is equal to the following callback declaration:



const toggle = () => setIsToggled(!isToggled);

Also, current implementation violates the exhaustive dependencies rule: every value referenced inside the function should also appear in the dependencies array. This is required to ensure that values inside a callback are always up-to-date and avoid any bugs related to that.

Let's see in practice how these two impact performance. First, let's create a simple RendersCounter component that takes a single onClick prop. It's going to count how many times a component was rendered:



import React from 'react';

const RendersCounter = ({ onClick }) => {
  const rendersCountRef = React.useRef(0);
  rendersCountRef.current += 1;

  return (
    <div>
      <span>
        RendersCounter rendered <b>{rendersCountRef.current}</b> time(s)
      </span>
      <button style={{ marginLeft: '10px' }} onClick={onClick}>
        toggle
      </button>
    </div>
  )
};

export default React.memo(RendersCounter);

Note that RendersCounter is wrapped with React.memo. The optimizations we're going to make are only working if a child component is a pure component: it's an instance of React.PureComponent, a functional component wrapped with React.memo, or has referential equality render optimization via shouldComponentUpdate or any other way to do it. If you don't have any of those implemented for a child component, it will be re-rendered every time a parent component is re-rendered regardless of the way you implement a callback.

Now let's use this component to see what happens if we don't pass dependencies to useCallback at all. I will create two separate state handlers: one for our boolean state and another one for storing a random number.



const BasicBooleanState = () => {
  const [isToggled, setIsToggled] = React.useState(false);
  const toggle = React.useCallback(() => setIsToggled(!isToggled));

  const [randomNumber, setRandomNumber] = React.useState(Math.random());
  const generateRandomNumber = React.useCallback(
    () => setRandomNumber(Math.random()),
    [],
  );

  return (
    <div>
      <div>
        Current random number is <b>{randomNumber}</b>
        <button style={{ marginLeft: '10px' }} onClick={generateRandomNumber}>
          regenerate
        </button>
      </div>
      <div>
        Boolean is set to <b>{String(isToggled)}</b>.
      </div>
      <RendersCounter onClick={toggle} />
    </div>
  );
}

RendersCounter re-renders even though the boolean state is not changed at all!

As said before, the current toggle implementation with useCallback is equal to a regular arrow function declaration. It's re-created each render so RendersCounter gets a referentially different onClick prop that causes its re-render when it doesn't have to.

Try it yourself

Fixing missing dependencies

React documentation says:

Every value referenced inside the function should also appear in the dependencies array

If you don't follow this rule you might end up having outdated values inside a callback. There are two external values used inside the toggle callback: isToggled and setIsToggled. Let's put them into the useCallback's dependencies array.



const BasicBooleanState = () => {
  const [isToggled, setIsToggled] = React.useState(false);

  // here we added [isToggled, setIsToggled] as a second parameter
  const toggle = React.useCallback(
    () => setIsToggled(!isToggled),
    [isToggled, setIsToggled],
  );

  const [randomNumber, setRandomNumber] = React.useState(Math.random());
  const generateRandomNumber = React.useCallback(
    () => setRandomNumber(Math.random()),
    [],
  );

  return (
    <div>
      <div>
        Current random number is <b>{randomNumber}</b>
        <button style={{ marginLeft: '10px' }} onClick={generateRandomNumber}>
          regenerate
        </button>
      </div>
      <div>
        Boolean is set to <b>{String(isToggled)}</b>.
      </div>
      <RendersCounter onClick={toggle} />
    </div>
  );
}

Now RendersCounter is not re-rendering when a random number changes! We said our callback to update only when isToggled or setIsToggled change so it's referentially equal unless isToggled changes.

But when we toggle the boolean state from the RendersCounter it gets re-rendered. And this makes sense because isToggled changes and it's a part the useCallback's dependencies array.

Try it yourself

Optimizing a callback

To fix the problem of re-creating the toggle callback we need a way to avoid depending on isToggled directly but still have its actual value inside a callback. Here's what useRef can help with. We just need to create a reference once and update its value when isToggled changes. Then we replace isToggled with the reference in the dependencies array and callback itself and that's it!

Let's create a custom hook that would return a current boolean state and a toggle method that is changing a boolean value and never gets re-created



// it might be a project-level reusable hook
const useToggle = (initialState) => {
  const [isToggled, setIsToggled] = React.useState(initialState);
  const isToggledRef = React.useRef(isToggled);

  // put [isToggledRef, setIsToggled] into the useCallback's dependencies array
  // these values never change so the calllback is not going to be ever re-created
  const toggle = React.useCallback(
    () => setIsToggled(!isToggledRef.current),
    [isToggledRef, setIsToggled],
  );

  // keep the value in isToggledRef actual
  // when isToggled changes, isToggledRef is updated accordingly
  React.useEffect(
    () => {
      isToggledRef.current = isToggled;
    },
    [isToggled],
  );

  return [isToggled, toggle];
}

Instead of isToggled we use isToggledRef to create the toggle callback. Both isToggledRef and setIsToggled are created only once and React ensures they never change and are referentially equal through renders. That means there's no reason for the toggle callback to be ever re-created.

To make sure the value in isToggledRef is up-to-date we use useEffect with a single isToggled dependency in the dependencies array. It will be executed only when isToggled changes.

It's time to use the hook we created:



const OptimizedBooleanState = () => {
  const [isToggled, toggle] = useToggle(false);

  const [randomNumber, setRandomNumber] = React.useState(Math.random());
  const generateRandomNumber = React.useCallback(
    () => setRandomNumber(Math.random()),
    [],
  );

  return (
    <div>
      <div>
        Current random number is <b>{randomNumber}</b>
        <button style={{ marginLeft: '10px' }} onClick={generateRandomNumber}>
          regenerate
        </button>
      </div>
      <div>
        Boolean is set to <b>{String(isToggled)}</b>.
      </div>
      <RendersCounter onClick={toggle} />
    </div>
  );
}

Now RenderCounter never gets re-rendered!

Try it yourself

Update

As Juan Gabriel S. Palarpalar mentioned in comments, there's no need to use refs in this case. The desirable behavior can be achieved with a functional state updater. Instead of passing a value to setIsToggled we need to pass a function that takes the current state as the first argument. This really makes the hook way clearer:



setIsToggled(state => !state);

Here's how updated useToggle hook looks:



const useToggle = (initialState) => {
  const [isToggled, setIsToggled] = React.useState(initialState);

  // put [setIsToggled] into the useCallback's dependencies array
  // this value never changes so the callback is not going to be ever re-created
  const toggle = React.useCallback(
    () => setIsToggled(state => !state),
    [setIsToggled],
  );

  return [isToggled, toggle];
}

Try it yourself

Conclusion

At the end of the day, useCallback is only about optimization. Your code will still work properly if you declare a callback as a plain arrow function so it's up to you to find a balance between optimization and code brevity.

React Hooks API is super powerful. It allows you to write clear declarative code. It can also boost your app's performance if cooked right.

Thank you for reading!

Redirecting requests to a country-specific URL on AWS with CloudFront and Lambda

Alex Khismatulin — Mon, 04 May 2020 19:45:53 +0000

Sometimes you need to be sure you show relevant content to visitors in different countries. Let's see how it can be done using Amazon Web Services.

Prerequisites

In this tutorial, we will implement location-based redirects for an app distributed via Amazon CloudFront. I will store specific files on Amazon S3 but it could be any storage or web server. Finally, we will use AWS Lambda service to check country codes and return an appropriate response.

I added three files to the S3 bucket. Each of them is responsible for a particular locale:

Each file from the bucket has its own CloudFront distribution with the WEB distribution method. It might not make sense while they point to the same S3 bucket but in a real-world app each distribution would point to a different domain.

Setting Up Lambda Function

Open up Lambda service, select the region you need and hit Create function. Now we need to configure a function and name it:

The only thing that worth to be mentioned is the function's execution role. If this is your first Lambda function for CloudFront, you need to create a new role. Select Basic Lambda@Edge permissions (for CloudFront trigger) from the Policy templates dropdown and insert a role name for future usages. I named it cloudfront_basic but it might be any name. The role is required to let Lambda know what service is going to use the function. Go ahead and save your function.

It's time to get your hands dirty! Put the following code into the editor:

exports.handler = async (event) => {
    const getCustomResponseWithUrl = url => ({
        status: '302',
        statusDescription: '302 Found',
        headers: {
            location: [{
                key: 'Location',
                value: url,
            }],
        },
    });

    const request = event.Records[0].cf.request;
    const headers = request.headers;
    let response = request;

    if (headers['cloudfront-viewer-country']) {
        const countryCode = headers['cloudfront-viewer-country'][0].value;
        switch (countryCode) {
            case 'GB': {
                // generate a redirect response to the United Kingdom distribution
                response = getCustomResponseWithUrl('https://d1zywwhn3ytw4t.cloudfront.net');
                break;
            }
            case 'US': {
                // generate a redirect response to the United States distribution
                response = getCustomResponseWithUrl('https://d3gf6cz8gf6db6.cloudfront.net');
                break;
            }
            default: {
                // don't change the incoming request
                break;
            }
        }
    }

    return response;
};

All we need to do is to check if the country from the cloudfront-viewer-country header fits any of our conditions. If so, we need to generate a redirect response with a URL of the CloudFront distribution we want to redirect to. If not, just need to return the incoming request from the event object that is passed as the first argument to the handler function. Dead simple!

To make the function visible to CloudFront distributions we need to save it and publish a new version from the actions dropdown. Copy the function's ARN, it will be available in the top right corner. We'll need it a moment later.

Adding Lambda Function to CloudFront distributions

Now it's time to make CloudFront distributions use the function. Go to CloudFront and open the distribution we created for requests that don't meet any condition(not from UK or US in our case). Open the behaviors tab and click Create behavior. Put * into the path to make it work for each path for simplicity. For the real-world app, you can add a more complex path pattern.
Next, select Whitelist for the Cache Based on Selected Request Headers setting. In the Whitelist Headers input, add CloudFront-Viewer-Country to the whitelisted headers list. It will make CloudFront add the cloudfront-viewer-country header that we use in the Lambda function.

Finally, put the ARN of the Lambda function we copied and associate it with the Origin Request event:

We're all set! Save the behavior we created. Wait for the distribution to deploy and that's it:

Forem: Alex Khismatulin

Pure Functions Explained for Humans

Start leveraging pure functions TODAY

A simple definition

Returns the same output given the same input

Let's consider 2 examples

addFive function

addSomething function

What does that mean for us?

Doesn't consume or modify other resources internally

Doesn't change its inputs

"Same" doesn't always mean "equal"

It's "identical", not "same" or "equal"

Other side effects

Final definition

What should I do when I do need side effects?

What are the pros?

Reusability

Testing

They make the code easier to consume

In the end

P.S.

Post editor: pre-publish confirmation

TS + React: interface vs type for props

TypeScript 4.3 Quickly: My TOP-3 Updates

overrides + noImplicitOverrides compiler option

Different types for getter and setter

Import statement completions

What else?

Quick Peek: React App Mounted on a Shadow DOM Root

Code first

What's this all about?

Use-cases

Cons

In the end

P.S.

Is there a way to aggregate dev.to RSS feeds?

React Context: a Hidden Power

So what does it actually do?

Before we start

A Sample App

calculateChangedBits

unstable_observedBits

Limitations

Conclusion

Suggest a tool for wiring paper prototypes

Update boolean state right with React Hooks

So what's wrong?

Fixing missing dependencies

Optimizing a callback

Update

Conclusion

Redirecting requests to a country-specific URL on AWS with CloudFront and Lambda

Prerequisites

Setting Up Lambda Function

Adding Lambda Function to CloudFront distributions

Further reading

`addFive` function

`addSomething` function