Forem: Mike Borozdin

Change Jest mock per test with ease

Mike Borozdin — Sat, 27 Feb 2021 11:11:52 +0000

Changing implementation of Jest mocks per test can be confusing. This blog post will present a simple solution for that. You'll see how each test can get its own mock for both constant values and functions. The solution doesn't rely on using require().

Sample app

Let's start with an example - we have a function - sayHello(name) - it prints out Hi, ${name}. And depending on configuration it either capitalizes the name or not.

say-hello.js

import { CAPITALIZE } from './config';

export const sayHello = (name) => {
  let result = 'Hi, ';

  if (CAPITALIZE) {
    result += name[0].toUpperCase() + name.substring(1, name.length);
  } else {
    result += name;
  }

  return result;
};

And we want to test its behaviour like this:

say-hello.js

import { sayHello } from './say-hello';

describe('say-hello', () => {
  test('Capitalizes name if config requires that', () => {
    expect(sayHello('john')).toBe('Hi, John');
  });

  test('does not capitalize name if config does not require that', () => {
    expect(sayHello('john')).toBe('Hi, john');
  });
});

One of those tests is bound to fail. Which one - depends on the value of CAPITALIZE.

Setting a value inside jest.mock() will not help either. It will be the same as relying on the hardcoded value - one of the tests will fail.

jest.mock('./config', () => ({
  CAPITALIZE: true // or false
}));

Changing mock of non-default `const`

So we need to change the mock of a non-default const.

First, let's change the way we mock the config module:

jest.mock('./config', () => ({
  __esModule: true,
  CAPITALIZE: null
}));

We do set CAPITALIZE to null, because we'll set its real value in the individual tests. We also have to specify __esModule: true, so that we could correctly import the entire module with import * as config.

Next step is we need to import the module:

import * as config from './config';

And finally change the mock value in each test:

import { sayHello } from './say-hello';
import * as config from './config';

jest.mock('./config', () => ({
  __esModule: true,
  CAPITALIZE: null
}));

describe('say-hello', () => {
  test('Capitalizes name if config requires that', () => {
    config.CAPITALIZE = true;

    expect(sayHello('john')).toBe('Hi, John');
  });

  test('does not capitalize name if config does not require that', () => {
    config.CAPITALIZE = false;

    expect(sayHello('john')).toBe('Hi, john');
  });
});

How does it work?

jest.mock() replaces the entire module with a factory function we provide in its second argument. So when we import that module we get a mock instead of the real module. That also means that we can import the same module in the test itself. And that will give us access to the mock which behaviour we can change.

Why import entire module versus just the `const` we need?

Why can't we just import in this way import CAPITALIZE from './config';? If we import it in that way, we won't be able to re-assign a value to it. Values are always imported as constants.

TypeScript

If you're using TypeScript the line where you're changing the mock:

config.CAPITALIZE = true;

will give you an error:

Cannot assign to 'CAPITALIZE' because it is a read-only property

That's because TypeScript treats imports as constants and objects with read-only properties.

We can fix that by type casting to an object with writeable properties, e.g.:

import * as config from './config';

const mockConfig = config as { CAPITALIZE: boolean };

// and then in a test
mockConfig.CAPITALIZE = true;

Changing mock of `export default const`

Okay, but what if we need to change the mock of a value that is a default export of the module?

const CAPITALIZE = true;

export default CAPITALIZE;

We can use the same approach, we just need to mock the default attribute:

import { sayHello } from './say-hello';
import * as config from './config';

jest.mock('./config', () => ({
  __esModule: true,
  default: null
}));

describe('say-hello', () => {
  test('Capitalizes name if config requires that', () => {
    config.default = true;

    expect(sayHello('john')).toBe('Hi, John');
  });

  test('does not capitalize name if config does not require that', () => {
    config.default = false;

    expect(sayHello('john')).toBe('Hi, john');
  });
});

TypeScript

As with mocking a constant that is non-default export, we need to type cast the imported module into an object with writeable properties

We can fix that by type casting to an object with writeable properties. This time though we change the default attribute instead of CAPITALIZE.

import * as config from './config';

const mockConfig = config as { default: boolean };

// and then in a test
mockConfig.default = true;

Changing mock of non-default function

What if the configuration is returned by a function instead of a constant:

const CAPITALIZE = true;

export default CAPITALIZE;

Actually, it'll be even more straightforward than dealing with constants, as we don't need to import the entire module via import * as entireModule and as a result we won't have to provide __esModule: true.

Our test will simply looks like this:

import { sayHello } from './say-hello';
import { shouldCapitalize } from './config';

jest.mock('./config', () => ({
  shouldCapitalize: jest.fn()
}));

describe('say-hello', () => {
  test('Capitalizes name if config requires that', () => {
    shouldCapitalize.mockReturnValue(true);

    expect(sayHello('john')).toBe('Hi, John');
  });

  test('does not capitalize name if config does not require that', () => {
    shouldCapitalize.mockReturnValue(false);

    expect(sayHello('john')).toBe('Hi, john');
  });
});

TypeScript

This line

shouldCapitalize.mockReturnValue(false);

will give a TypeScript error of:

Property 'mockReturnValue' does not exist on type '() => boolean'.

Indeed, TypeScript thinks we've imported a function that returns a boolean, not a Jest mock.

We can correct it again with type casting to a Jest mock.

import { shouldCapitalize } from './config';

const mockShouldCapitalize = shouldCapitalize as jest.Mock;

// and then in a test
mockConfig.default = true;

Changing mock of default function

There might also be a case that we want to change the behaviour of the function that is the default export of a module.

const shouldCapitalize = () => true;

export default shouldCapitalize;

In that case, we employ a technique similar mocking default constants - we'll mock `default`, set `__esModule: true` and will import the entire module with `*`.

import { sayHello } from './say-hello';
import * as config from './config';

jest.mock('./config', () => ({
  __esModule: true,
  default: jest.fn()
}));

describe('say-hello', () => {
  test('Capitalizes name if config requires that', () => {
    config.default.mockReturnValue(true);

    expect(sayHello('john')).toBe('Hi, John');
  });

  test('does not capitalize name if config does not require that', () => {
    config.default.mockReturnValue(false);

    expect(sayHello('john')).toBe('Hi, john');
  });
});

TypeScript

Similar to mocking a non default function, we need to type cast the imported module into an object with writeable properties

import * as config from './config';

const shouldCapitalizeMock = config.default as jest.Mock;

// and in a test
shouldCapitalizeMock.mockReturnValue(true);

Conclusion

All examples above rely on a simple premise that:

jest.mock() mocks a specific module (unsurprisingly, huh?)
So everywhere you import it you'll get a mock instead of a real module
And that applies to tests, as well
So import mocked modules in test and change their implementation

Managing technical debt

Mike Borozdin — Sun, 07 Feb 2021 16:15:47 +0000

Originally published on mikeborozdin.com.

Often engineering teams struggle with technical debt. They are busy with building features and fixing bugs, but that’s not going well due to a huge amount of technical debt. However, they hardly get any time to fix any of the debt.

In this article I’m going to share my experience on how to manage technical debt and get it fixed.

What is technical debt?

First of all, what is technical debt?

Technical debt is something that slows us down. Technical debt is a code that you are afraid to touch and if you do you produce multiple bugs. Technical debt is a messy code that does not let you ship features fast. Technical debt is an obsolete library version that doesn't allow us to use the latest techniques.

Scalability issues though are not technical debt (more on that below).

Why do teams struggle to address technical debt?

In my experience, it happens simply because it nevers gets prioritised. And that’s usually due to the fact that software developers tend to speak of technical debt purely from a technical point of view. And a result, product managers, who drive prioritisation, don’t quite get the value of it - and that’s why work on fixing technical debt always ends up in the bottom of the backlog.

Technical debt has business impact

But technical debt does have business impact. Technical debt means that new features will take 2x, 3x, 10x times, as longer, if it were not for technical debt. Technical debt means you’ll dedicate a lot of time fixing bugs, instead of building new features.

Technical debt, like financial debt, means that you’ll spend your disposable income (dev time) paying off interest (fixing long outstanding technical debt) instead of spending it on fun things (new features that customers love).

So when persuading product managers to prioritise technical debt, do talk about the business impact it’ll bring. And talk about the negative effect if you postpone it. Ultimately, it is all about reducing time-to-market (time to build new features) and improving product quality (fewer bugs).

How to prioritise technical debt?

And speaking of prioritisation, I have observed two strategies:

Allocate a certain amount of time to technical debt. Say, a day a week
Prioritise technical debt along with features and bug fixes

Personally, I’m not a fan of the first one. Allocating a certain amount of time seems too arbitrary. There are occasions when addressing technical debt takes more a day a week. Sometimes there are times that you have nothing to address. Plus, that may also seem as a blackbox to non-technical stakeholders. Unless they explicitly ask engineers they won’t know what technical debt is being addressed and how that benefits the product.

Prioritise technical debt along with features and bug fixes

Instead I prefer to prioritise technical debt along with features and bug fixes. No matter which software development methodology you use, chances are you have some sort of a backlog - a prioritised list of features and bug fixes. So just put technical debt tickets to that list and prioritise them accordingly.

This method has the following advantages:

It forces you to think of technical debt as atomic pieces of work
It is tied to the roadmap (more on that below)
It gives visibility to non-technical stakeholders

I want to emphasise the second point - 'it is tied to the roadmap'. If you see on the roadmap that three new features will touch an ugly part of the code, then you can accelerate development by prioritising refactoring ahead of the feature work.

Sometimes you can just inflate time estimates

In the previous example, there are three features which depend on fixing technical debt. And it makes sense to prioritise technical debt separately. Multiple developers will work on those features, you don’t want them to depend on each other. So refactor first and let them build those features after.

But if the roadmap says that there’ll be only one feature that requires touching that scary piece of code, then you don’t even need to schedule any additional work. Just inform a product manager that a feature will take longer because you need to tidy up the code first. Otherwise (without refactoring), the work will take even more time and there’ll be a lot of bugs after.

Old dependency versions can become technical debt

Whatever you’re building probably depends on dozens of 3rd party libraries. And they tend to get new versions over time.
You need to keep an eye on new versions and prioritise upgrades.

Why?

New versions can make you more productive. They may introduce new features that simplify your development. And if you don’t upgrade soon enough, your code will start to look obsolete. The dev community will eventually embrace new features of a language or a framework, but you will be still stuck with an old version and its old ways.
The longer you stay on an older version the more painful you’re making an upgrade. If you are one major version behind an upgrade will probably be smooth-ish, but if you are two, three, four major versions behind, it’s likely to be much more painful
Support and security vulnerabilities - you don’t want to be using a framework that is no longer supported, do you?

You can even refactor code as you go along

Nothing prevents you from improving the code quality while you’re fixing bugs or building new features.

Think that something can be refactored into a separate module? Do it!

Noticed that 3rd party library, you’re calling, is 3 major versions behind? Upgrade it!

But... be reasonable and avoid rabbit holes.

Will your new feature make a mess out of the existing code? Yes? Then, take your time and do it properly.

Have you noticed that the function you're calling is difficult to understand, but you don’t have to change it? Just write a ticket about it and prioritise it separately.

When making such decisions also think of people who’ll be reviewing your code. The more things you’re putting in your pull request, the more time it’ll take for them to review and the more things they can miss in a review.

Scalability issues are not technical debt

If your website is meant to serve 10,000 customers a minute, but is only capable of doing 500, then it’s not technical debt, it’s a very big gap in your product functionality. It’s the same thing as building a payment feature that only accepts Visa cards, but not MasterCard.

Yes, there might be the same cause for technical debt and scalability issues, for instance, you cut corners somewhere. But their impact is very different. As mentioned above technical debt does have a huge business impact, but the downfall from scalability issues is far bigger.

And if you need to get work prioritised, you need to clearly explain why it matters. So if you know that next month you’ll be serving more customers that your app is capable of, then this precisely what you should tell all non-technical stakeholders.

Another way to look at it - if you pause entire development, then technical debt will not be relevant - it won’t slow down anything, as there’ll be no features to build. But if people still use the product, well, they try and they cannot, because your system cannot cope with the demand, then it’s a gap in functionality.

Finally, build good relationship with product managers

I have written about it, the other people have written about it before. It is vital to have a good relationship between product and engineering. Both of you need to have trust. That’s because you’ll have to ask a product manager to pause feature/bug delivery and spend time on technical debt. They, in turn, need to trust you that that time will be well spent and ultimately will benefit users.

On being effective tech lead

Mike Borozdin — Mon, 18 Jan 2021 19:36:32 +0000

Originally posted on mikeborozdin.com

Tech Lead / Lead Developer / (Whatever it is called in your company) is a very interesting role that combines technical
work and leadership.

I’ve been in that role at a few different companies and I’d like to share my thoughts on what you can do to be effective in that role.

Equally, this article may also help you to decide if you want to try the role.

Your main goal is to enable your team

Your first and foremost goal as a tech lead is to enable your team. Your team’s success is your success.

Yes, it was partly your technical chops that brought you into this role, but a tech lead is not the person who writes the best
code on the team (at least not just).

But it is the person who enables the entire team. And that means doing whatever it takes to help your team to
succeed - whether it’s mentoring them technically or buying coffee - you have to do it.

Generally though you work on two fronts - product and technical.

Product

Yes, it is a role of a product manager to define a product vision, build a roadmap, and write user stories. But if user stories are missing details or the team does not know what they’ll be coding next week, it is your responsibility to step and help the team.
Sometimes it means you’ll fill the gaps yourself and tell the team about what you’ve heard in that long product meeting last Thursday.

Or sometimes you have to guide the product team on how to better translate their ideas into something developers can work with.

Shortly, you need to make sure that your team knows not only how to build software, but what to build.

Technical

And speaking of the question of how to build, this is where your technical expertise comes in.

You need to make sure that your team knows how to build those fancy features and fix pesky bugs.

So if someone has not worked on a certain part of the codebase, sit with them and walk them through it.

If someone does not know which environment to deploy and where the API keys are, help them with that.

If someone is stuck, drop whatever you’re doing and unblock them.

But... delegate and help your teammates grow

Although you’re there to protect your team and help them focus on writing code, you shouldn’t take away all non-coding activities from them.

You don’t have to be the only person who onboards new team members, defines architecture, and fleshes out user stories with product managers.

If you do that, you’ll soon end up being a bottleneck for your team. Moreover, you’ll prevent your team members from growing professionally.

Instead, identify activities which your teammates are interested in and let them run with that.

If you happen to be their line manager, it’s double as important to do that, as it’ll help them with their career growth. And if you’re not line managing your team, you may pair up with their manager and find out what career aspirations your colleagues have and give them a chance to go in that direction.

Communicate to provide clarity

It’s your job as a tech lead to communicate and provide clarity. The product team may need to know how long some features will take - and you will have to tell a Product Manager that feature XYZ will take longer because the team needs to do essential refactoring.

Equally, your team needs to know that there might be a change in a product direction in two months, hence it is worthwhile to invest time in bringing framework ABC.

Partner with product

I have already mentioned working closely with product managers a few times. Here I want to stress why it is important and a few usual things you have to do.

First of all, you're the main point of contact for all things technical to the product and other departments (if you are working on B2B software you may also have to interact with sales and professional services). So do expect a lot of questions from them about timelines and feasibility of their ambitious ideas.

But working with the product team is more than just answering their questions, it is also about being proactive. It is up to you to help them to build a roadmap. It is up to you to say that certain features are not possible without doing an essential technical work. It is up to you to say that all feature work should stop and you have to move to a different framework.

Equally, it is for you to say that some features are less complex than they thought before and that you can do them now.

But... then again help your fellow engineers engage with product

Yes, you should protect engineers’ time, so don’t invite them to all the meetings.

But every software engineer is still interested to know which features they’ll be coding in six months' time. Every software engineer has great ideas on how to improve the product.

So make that happen - make sure that the product team talks to engineers about product plans and that they all sit together to flesh out user stories.

Trust your team

A tech lead should trust their team to make the best decisions. If someone wants to introduce a 3rd party library XYZ for doing ABC, then let them do it. If your colleague proposes re-designing a part of the system, let them do it, too.

But... be prepared to ask question in a helpful way

Whether it’s choosing a 3rd party library or deciding on architecture, make sure your colleagues have considered alternatives and impact on maintainability, project timelines, performance, security, etc. Feel free to ask questions about that.

Equally be prepared to step in and guide your fellow developers. For instance, if you notice that some tasks are taking much longer than expected, do speak to engineers who are working on them. They may be busy trying to consider every possible edge case that may never happen or do refactoring that should be a separate task. Help your team to avoid such rabbit holes.

Be strategic and stay technical

As a technical lead you should look ahead and be strategic. More specifically, you should:

Collaboratively establish architecture and coding standards
Prioritise working on technical debt
Look into newer version of the tools you use and make sure that you keep your codebase up to date
See what other technologies are available and how they can help your team

And that is impossible without you staying on the bleeding edge of technology. Remember, technical lead does have ‘Technical’ in it.

Yes, it’s a people intensive role, but it is also about technology. And on that note...

Be clear on how much time you can spend coding

A technical lead is expected to code. But how much can vary significantly week by week. Sometimes, you’ll have the luxury of spending 80% of your time coding away new features. Sometimes, it’ll be only 20% of your time.

What is important is to set expectations with your colleagues. No-one would mind if you say that next week you’ll be able to only commit 30% of your time to writing code. But they will certainly be less happy if you forget to mention that. And that includes both other engineers, who may wait for you to redesign an API endpoint, or product managers who expect you to finish that feature that all users want to see.

Work with engineering managers (if you’re not line managing your team)

Often as a tech lead you don’t have line management responsibilities, but it is often you who knows your teammates the best and it is you who can help them to get a promotion, salary increase, bonus, more equity, etc.

So do spend some time with their line manager and pass on feedback. Plus, their line manager can also tell you where you can help your colleagues in their career. You may even want to establish a pattern that you speak to their line manager and pass feedback on before their 1:2:1’s.

Finally

Tech lead is a great role. It allows you to write code and gain exposure to leadership, people, and product. But remember it’s not about you, but about helping you team to succeed!

Move from Redux to MobX - reduce boilerplate

Mike Borozdin — Mon, 13 Apr 2020 17:39:36 +0000

Originally posted on mikeborozdin.com

MobX is a statement management library. Unlike Redux it doesn’t require a lot of boilerplate code. In this post we’ll talk how you can benefit from using MobX vs Redux.

Video version

There’s a video version of this article that I originally recorded for the React Native London. If you prefer to read text, just scroll below.

Problem with Redux

Redux is great for extracting application state and business logic out of components. However, you end up with a lot of boilerplate. Your code will be scattered around many different place. Think of a typical user action - usually, you have to write an action definition, an action creator, and finally a reducer. Now, imagine you have a bug in that action - you’ll have to trace it in at least two different places - an action creator and a reducer.

This tweet by Ben Lesh - a member of the RxJS core team - perfectly summarises that.

// Detect dark theme var iframe = document.getElementById('tweet-1241525265228017670-631'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1241525265228017670&theme=dark" }

Enter MobX

MobX allows you to manage your state in a far more concise way. It's a fairly simple library that you can get started with in almost no time. It's got more than 400k+ weekly downloads on NPM. And many companies, including mine, use it in production.

Unlike, Redux, it's not afraid to mutate state. In fact, it's based on the observer pattern which is all about mutations and reactions to them.

Instead of doing a theoretical introduction of MobX, I'll use an example. We'll build a simple application first with Redux and then'll we'll move it to Mobx, while gradually explaining its concepts.

Sample app

The sample app is a classis todo app:

You can see a list of todo items
You can add new ones
And all of that will be done via the API calls
- That's to make comparison between Redux and MobX more interesting
- After all, in real world we get and save data via APIs most of the time

App code with Redux

First of all, the Redux app needs action creators.

There'll be two action creators:

addTodo()
getTodos()

Since we need to send API requests, there'll be a bit of complexity - we'll have to return a function an async function from the action creators.

store/action-creators.js

import { GET_TODOS } from './constants';

export const addTodo = (todo) => {
  return async (dispatch) => {
    await fetch('http://localhost:9999/todos', {
      method: 'post',
      body: todo
    });

    dispatch(getTodos());
  };
};

export const getTodos = () => {
  return async (dispatch) => {
    const res = await fetch('http://localhost:9999/todos');

    const { todos } = await res.json();

    dispatch({
      type: GET_TODOS,
      todos
    });
  };
};

Then we need to add reducers that will set the initial state and modify it once the actions are dispatched.

store/reducers.js

import { ADD_TODO, GET_TODOS } from './constants';

const initialState = {
  todos: []
};

const todos = (state = initialState, action) => {
  switch (action.type) {
    case ADD_TODO: {
      return {
        ...state,
        todos: [...state.todos, action.todo]
      };
    }
    case GET_TODOS: {
      return {
        ...state,
        todos: action.todos
      };
    }
    default:
      return state;
  }
};

We need to throw a few constants in the mix, so that the reducers module doesn't depend on the action creator one and vice versa.

store/constants.js

export default todos;

export const ADD_TODO = 'ADD_TODO';

export const GET_TODOS = 'GET_TODOS';

Finally, we need to wire it app together and call createStore().

store/store.jsx

import { applyMiddleware, createStore } from 'redux';
import thunkMiddleware from 'redux-thunk';
import todos from './reducers';

export default createStore(todos, applyMiddleware(thunkMiddleware));

Redux store so far

It feels like we had to write a lot of code for such a small application, doesn't it?

Redux wiring

As the final step we have to inject the store into the application context:

index.jsx

import React from 'react';
import ReactDOM from 'react-dom';
import { Provider } from 'react-redux';
import store from './store/store';
import App from './App';

ReactDOM.render(
  <React.StrictMode>
    <Provider store={store}>
      <App />
    </Provider>
  </React.StrictMode>,
  document.getElementById('root')
);

Components

What about the components. We left them till the end, but they are not particularly complicated:

Todos/Todos.jsx

import React, { useEffect } from 'react';
import { connect } from 'react-redux';
import { getTodos } from '../store/action-creators';
import './Todo.css';

const Todos = ({ todos, getTodos }) => {
  useEffect(() => { getTodos() }, [getTodos]);

  return (
    <div className='list'>
      {todos.map((todo, index) => (
        <div key={index} className='todo'>{todo}</div>
      ))}
    </div>
  );
};

const mapStateToProps = (state) => ({
  todos: state.todos
});

const mapDispatchToProps = (dispatch) => ({
  getTodos: () => { dispatch(getTodos()) }
});

export default connect(mapStateToProps, mapDispatchToProps)(Todos);

Todos/Todos.jsx

import React, { useState } from 'react';
import { connect } from 'react-redux';
import { addTodo } from '../store/action-creators';
import './NewTodo.css';

const NewTodo = ({ addTodo }) => {
  const [todo, setTodo] = useState('');

  return (
    <div>
      <input
        type='text'
        onChange={e => setTodo(e.target.value)}
        placeholder='New todo item...'
        className='new-todo' />

      <button
        onClick={() => addTodo(todo)}
        className='new-todo-button'>
        Add a new todo
        </button>
    </div>
  );
};

const mapDispatchToProps = (dispatch) => ({
  addTodo: (todo) => dispatch(addTodo(todo))
});

export default connect(null, mapDispatchToProps)(NewTodo);

Enter MobX

Now, remember a very verbose Redux store we wrote? Let's see how we re-write it in MobX.

import { observable, action } from 'mobx';

export default class TodoStore {
  @observable
  todos = []

  @action
  async addTodo(todo) {
    await fetch('http://localhost:9999/todos', {
      method: 'post',
      body: todo
    });

    this.getTodos();
  }

  @action
  async getTodos() {
    const res = await fetch('http://localhost:9999/todos');

    const { todos } = await res.json();

    this.todos = todos;
  }
}

And that's it! Those mere 25 lines of code replace Redux's action creators, reducers, and the other bits!

Now, we have a very concise store that both has an application state and business logic, yet doesn't mix them together. Indeed, MobX stores are a great answer to the question - 'Where do I put my business logic and HTTP calls in React?'. Also, MobX stores are extremely easy to unit test.

Okay, but how is it possible? Let's dive into the code.

MobX observables

First of all, we declare an array that will hold todo items and mark it as an observable:

@observable
todos = []

What does the @observable annotation mean? It means that all the changes to the array will be monitored and all the observers will be notified? What are the observers? Usually, they are React components that reference observables. And they are re-rendered if corresponding observables change. We'll have a look at it below.

Now, having declared the data, we need to declare operations that can be performed on it. And, in our case, there are two:

Adding a new item
Getting todos

And you can see that they are declared as class methods and have the @action annotation:

store/store.js

@action
async addTodo(todo) {
  await fetch('http://localhost:9999/todos', {
    method: 'post',
    body: todo
  });

  this.getTodos();
}

@action
async getTodos() {
  const res = await fetch('http://localhost:9999/todos');

  const { todos } = await res.json();

  this.todos = todos;
}

Both addTodo() and getTodos() are just regular functions that make HTTP calls and update some data. The only two special things are:

They have the @action annotation
The data they modify - this.todos is marked as @observable.

Why does the methods need to be annotated with @action?

First of all, it's a nice convention that clearly marks methods that modify observable data. Secondly, MobX does performance optimisation if observable data is mutated in an action. Finally, MobX has a strict mode that would throw an exception if observables are modified outside of the actions.

Finally, you need to change the root of your application to this:

index.jsx

import React from 'react';
import ReactDOM from 'react-dom';
import { Provider } from 'mobx-react';
import TodoStore from './store/store';
import App from './App';

ReactDOM.render(
  <React.StrictMode>
    <Provider todoStore={new TodoStore()}>
      <App />
    </Provider>
  </React.StrictMode>,
  document.getElementById('root')
);

It's almost exactly the same as the one for Redux. The only difference is that we import Provider from a different module.

Components in MobX - `observers`

Okay, we have re-written the store in MobX. It does look much more concise than the one in Redux. But what about the components? Will they need much re-write?

Luckily, no! Let's examine the Todos component that is now MobX enabled:

Todos/Todos.jsx

import React, { useEffect } from 'react';
import { observer, inject } from 'mobx-react'
import './Todo.css';

const Todos = ({ todoStore }) => {
  useEffect(() => { todoStore.getTodos() }, [todoStore]);

  return (
    <div className='list'>
      {todoStore.todos.map((todo, index) => (
        <div key={index} className='todo'>{todo}</div>
      ))}
    </div>
  );
};

export default inject(({ todoStore }) => ({ todoStore }))(observer(Todos));

As you can see the component stayed largely unchanged. Similarly, to the Redux version it receives a property, but this time the property contains a MobX store that have a list of todos. It doesn't need need the mapStateToProps(). Instead, of connect() we have inject() that, as the name suggests, injects the data store into the component.

The most crucial thing that the component is wrapped inside the observer() function. As mentioned before, components wrapped inside observer() will be re-rendered once observable change.

Will all observer components re-render if any observable changes?

No! MobX is smart enough only to trigger re-rendering of the components read observables that get changed. For example, if you have a component that reads from the observable called todos, but it the the @observable employees that gets changed, then your component will not be re-rendered.

What about components that modify data?

Easy!

NewTodo/NewTodo.jsx

import React, { useState } from 'react';
import { inject } from 'mobx-react';
import './NewTodo.css';

const NewTodo = ({ todoStore }) => {
  const [todo, setTodo] = useState('');

  return (
    <div>
      <input
        type='text'
        onChange={e => setTodo(e.target.value)}
        placeholder='New todo item...'
        className='new-todo' />

      <button
        onClick={() => todoStore.addTodo(todo)}
        className='new-todo-button'>
        Add a new todo
      </button>
    </div>
  );
};

export default inject(({ todoStore }) => ({ todoStore }))(NewTodo);

Once again, it's very similar to its Redux version. And unlike the Todos component we don't need to wrap it inside observer. Indeed, NewTodo doesn't need to be rendered when todos change. We just need to inject the store with inject().

Source code

The source code of both the Redux and the MobX version is available on Github. It also includes the API server. So you can all run it.

Conclusion

MobX is a great and mature solution for state management of React applications
You'll have almost zero boilerplate in comparison to Redux
MobX stores are great place for business logic and HTTP requests
Give it a try
Have questions? There might be a few answers below

Q&A

What about hooks?
- The example above shows that MobX works nicely with React hooks such as useEffect() and useState()
But React Redux also has useSelector() and useDispatch()?
- So does MobX React have useObserver() and useStores() that you can use instead of observer() and inject().
- Personally, I prefer the HoCs - observer() and inject() because they make it easier to unit test components. But that could be a matter of taste.
Can you have more than one store?
- Easily! You can have as many stores as you want.
- I recommend having a store per feature
- We have around 15 stores on the product I'm working on
Does it come with debug tools?
- MobX comes with a great trace module
- Plus, you can use the standard React devtools to understand why components got re-rendered
Do you have to use ES decorators?
- No. Each ES decorator has a corresponding function which allows to wrap your variables/class properties and components
Does MobX work with any kind of component?
- You can mark 'fat' and simple functional components as observer
- But you cannot do that with PureComponents

Track a Virus: Open Source COVID-19 Dashboard with React, TypeScript, and MobX

Mike Borozdin — Sat, 11 Apr 2020 17:08:23 +0000

Originally posted on mikeborozdin.com

We live in desperate times. And more than ever we need to make decisions based on hard data and collaborate with each other.

So in the spirit of that, I've released an open source COVID-19 Dashboard.

You can play with it here.
And see its source code on GitHub.
- It's written with React, TypeScript, and MobX

Its key features are:

Comparison between different countries
Ability to see daily changes in a number of cases and deaths
Snapshot of the data across the whole world
And the ambition is to provide the most comprehensive COVID-19 dashboard, so your code contributions are more than welcome :-)
Data by the John Hopkins university

Country comparison

You can easily compare countries and see that while China flattened the curve in February a number of infections keeps going up.

Daily increase

The dashboard also gives positive news and says that the peak of the epidemic has passed in Italy.

World snapshot

Finally, you can see a quick snapshot of the data aggregated across the entire world.

Why another dashboard?

You may wonder why another dashboard. It is true, there are a number of dashboards available. In particular, the one by Oleksii Trekhleb looks similar. There are a few key aspects about this one:

Focus on trends, country comparisons, and aggregated global data
- From the day 1 the dashboard includes daily increases for a number of cases and deaths
There is a whole roadmap of the new features
- There are plans to add a growth rate
- Mortality figures
- and so on
Our tech stack and architecture enables developers easily build new features:
- React, TypeScript, Chart.js - is a fairly standard stack
- I've focused on the code quality to make sure it's easy to navigate around the code and add new functionality
I've also provided contribution guidelines that explains the architecture for people who wants to help with the project
- It provides a whole tutorial on how to write a new dashboard component

Of course, it is not perfect

There are a number of thing which needs to be fixed or added
For example, the percentage increase chart above may not accurately represents the trends. But there's already a plan to add a growth rate which could be better it.
That's just the beginning and more features are coming out next week.
And development can go faster if you join the project :-).

Let's try to flatten the curve together

Interested? Let's work on it together!

Shallow rendering & React Hooks. And why shallow rendering is good

Mike Borozdin — Sun, 15 Mar 2020 13:53:13 +0000

Originally posted on mikeborozdin.com

Now you can use shallow rendering for testing React components with hooks. And a few words on why shallow rendering is good.

Shallow Rendering & React Hooks

Up until recently it was tricky to use shallow rendering and libraries like enzyme for testing React components that relied on hooks like useEffect() and useLayoutEffect(). So I've released a library - jest-react-hooks-shallow - that brings those hooks to shallow rendering.

All you need to do is to download the library:

npm install --save-dev jest-react-hooks-shallow
# or
yarn add --dev jest-react-hooks-shallow

and add these lines to your Jest setup file (specified by setupFilesAfterEnv):

import enableHooks from 'jest-react-hooks-shallow';

// pass an instance of jest to `enableHooks()`
enableHooks(jest);

And voilà - useEffect() and useLayoutEffect() will work with shallow rendering. From this moment on your test don't need to know anything about useEffect(). After all, it's a mere implementation detail.

Testing

So if you have a component like this:

const ComponentWithHooks = () => {
  const [text, setText] = useState<>();
  const [buttonClicked, setButtonClicked] = useState<boolean>(false);

  useEffect(() => setText(
    `Button clicked: ${buttonClicked.toString()}`), 
    [buttonClicked]
  );

  return (
    <div>
      <div>{text}</div>
      <button onClick={() => setButtonClicked(true)}>Click me</button>
    </div>
  );
};

You can easily test it with code like this:

test('Renders default message and updates it on clicking a button', () => {
  const component = shallow(<App />);

  expect(component.text()).toContain('Button clicked: false');

  component.find('button').simulate('click');

  expect(component.text()).toContain('Button clicked: true');
});

Please note, that those tests didn't have to import anything else. They simply don't know that a component calls useEffect(). Yet, it's being called when you invoke shallow().

That said, often you want to test that a specific function has been called on some event. For example, you're calling a Redux action creator or a Mobx action. If you're using React Hooks, chances are you'll pass that function as a callback to useEffect().

No problems! You can easily test it with simple Jest mocks.

Say, we have a component like this:

import someAction from './some-action';

const ComponentWithHooks = () => {
  const [text, setText] = useState<>();
  const [buttonClicked, setButtonClicked] = useState<boolean>(false);

  useEffect(someAction, [buttonClicked]);

  return (
    <div>
      <div>{text}</div>
      <button onClick={() => setButtonClicked(true)}>Click me</button>
    </div>
  );
};
test('Calls `myAction()` on the first render and on clicking the button`', () => {
  const component = shallow(<App />);
  expect(callback).toHaveBeenCalledTimes(1);

  component.find('button').simulate('click');
  expect(callback).toHaveBeenCalledTimes(2);
});

You can find out more about jest-react-hooks-shallow on its Github page.

Why shallow rendering?

Some people may say why bring React Hooks to enzyme when there's a trend to use full rendering with libraries like react-testing-library. I've even sparked an interesting discussion on that when I posted about jest-react-hooks-shallow on Reddit. You may check these two sub-threads: one and two.

So there are a few good reasons for doing shallow rendering:

No unexpected side-effects

Let's say you have the following component hierarchy:

ComponentA -> ComponentB -> ComponentC (makes an HTTP request)

And you're writing a unit test for ComponentA. If you render the entire component tree, you tests may not work as expected because of the HTTP request made by ComponentC.

So you either have to mock component B - and that would be very similar to doing shallow rendering. Or you would have to mock component C or provide a stub backend. But the last two options are hardly ideal because they break encapsulation. Your component A has no knowledge of component C or any HTTP requests, why would a test for that component require that knowledge?

Test-driven development

Shallow rendering also assists with test-driven development. Let's take a previous example, but imagine that component A doesn't exist, but you have to write, because you need to wrap component B in another component. So it'll be far easier to write tests first for a new component that renders the existing ones, when you don't have to render the entire tree.

Re-usable architecture

If you have comprehensive unit tests for your components that don't rely rendering the whole tree, it'll be easier make such components re-usable and even extract them to stand-alone libraries.

A few misconceptions about shallow rendering

There are two popular misconceptions about shallow rendering:

It forces you to test implementation details
It doesn't test from a user point of view

First of all, it is absolutely true that it is bad to test implementation details and you should test from a user's point of view.

But shallow rendering does not force use to test implementation details. And it does allow you to test from a user's point of view.

There's a famous example of reading and setting React state in unit tests. This is wrong. You don't have to that and you can easily test without it.

Also, testing that your component renders specific child components or passes specific properties is testing implementation details, it is actually testing its behaviour. After all, that's what your component does - it renders certain elements on certain conditions and passes data to other components.

Let's have a look at a few examples on how you can test components that have different behaviour:

If your component's purpose to render a piece of text, it's totally acceptable to test that piece of text is displayed.

const MyComponent = () => (
  <div>My message</div>
);

it('Renders message', () => {
  const component = shallow(<MyComponent />);

  expect(component.text()).toContain('My message');
});

If your component displays a child component when a certain property is true, then you need to test that it renders that component when the property is true and it doesn't when it is false

const MyComponent = ({ displayChild }) => (
  <>
    {displayChild && <ChildComponent />}
  </>
);

it('Renders `ChildComponent` when necessary', () => {
  expect(
    shallow(<MyComponent displayChild={false} />)
    .find(ChildComponent)
  )
  .toHaveLength(0);

  expect(
    shallow(<MyComponent displayChild={true} />)
    .find(ChildComponent)
  )
  .toHaveLength(1);
});

If a component renders a button and hides another a child component when the button is pressed, then we should simulate pressing on a button and checking that a child component is not there.

const MyComponent = () => {
  cost [displayChild, setDisplayChild] = useState(true);

  return (
    <>
      {displayChild && <ChildComponent />}
      <button onClick={() => setDisplayChild(false)}>Hide child</button>
    </>
  );
};

it('Hides `ChildComponent` after pressing on the button', () => {
  const component = shallow(<MyComponent />);

  expect(component.find(ChildComponent)).toHaveLength(0);

  component.find('button').simulate('click');

  expect(component.find(ChildComponent)).toHaveLength(1);
});

The last example perfectly illustrates how you can test components from a user point of view and still use shallow rendering.

If your component passes a certain value to a child component, it's okay to test for that:

const MyComponent = () => {
  cost [accepted, setAccepted] = useState(false);

  return (
    <>
      <button onClick={() => setAccepted(true)}>Accept</button>
      <ChildComponent accepted={accepted} />
    </>
  );
};

it('Passes `accepted` to `ChildComponent` on pressing the button', () => {
  const component = shallow(<MyComponent />);

  expect(component.find(ChildComponent).prop('accepted')).toBeFalse();

  component.find('button').simulate('click');

  expect(component.find(ChildComponent).prop('accepted')).toBeTrue();
});

Don't forget about end-to-end tests

Finally, if you really want to test from a user's standpoint, then make sure that you have a few end-to-tests. They could be time consuming to write and run. But at they can tests the whole system end-to-end including the backend.

Conclusion

Now you can use shallow rendering and enzyme for testing React components with hooks
- Check jest-react-hooks-shallow for that
Shallow rendering has a number of advantages
It does not force you to write bad tests
You can test from a user's point of view with shallow rendering
Don't forget about end-to-end testing

Gradual move to TypeScript. Running JavaScript and TypeScript side-by-side

Mike Borozdin — Thu, 16 Jan 2020 21:02:19 +0000

Originally posted on my personal blog.

TypeScript has a lot of advantages. However, it's not often that you are starting a brand new project. More often though you are working on an existing codebase and simply don't have luxury of rewriting everything from scratch. After all, we need to deliver new features and fix annoying bugs.

But we shouldn't despair - it's possible to gradually move your projects to TypeScript - one module at a time - and run TypeScript and JavaScript side-by-side.

Example Project

As an example we'll use a simple React & Webpack project. Initially, it'll look like the left-hand side of the diagram - just two modules (App and JsComponent). And gradually we'll move onto the right-hand side the picture where we'll have JavaScript and TypeScript components side-by-side.

Gradual Migration to TypeScript

And in order to keep those languages side-by side, we need to make sure that we can:

Import TypeScript modules from JavaScript ones
Import JavaScript modules into TypeScript code

If we can do that, we'll be able to move a project to TypeScript while working on features and bug fixes.

For example, if you have to add a new React component, you can write it straight in TypeScript. And you'll still be able to use inside other components written in JavaScript.

Initial Webpack setup

Since we use Webpack as a module bundler, I want to show its configuration for the pure JavaScript project. That will allow us to see what we started with and what we've added to enable the TypeScript support.

webpack.config.js

const HtmlWebPackPlugin = require('html-webpack-plugin');
const path = require('path');

module.exports = (env) => ({
  entry: {
    index: ['./src/index.jsx'],
  },
  output: {
    path: path.resolve('./dist/'),
  },
  devtool: env === 'production' ? false : 'source-map',
  module: {
    rules: [
      { enforce: 'pre', test: /\.js$/, loader: 'source-map-loader' },
      {
        test: /\.(js|jsx)$/,
        exclude: /node_modules/,
        use: {
          loader: 'babel-loader',
        },
      },
      { test: /\.(ts|tsx)$/, loader: 'awesome-typescript-loader' },
    ],
  },
  resolve: {
    extensions: ['.js', '.jsx', '.ts', '.tsx'],
  },
  plugins: [
    new HtmlWebPackPlugin({ template: './src/index.html' }),
  ],
});

As you can see it's a very simple setup. The main thing is the use of the babel-loader for loading of ES modules with JSX in them.

Import TypeScript modules into JavaScript ones

Okay, we're adding a new React component and have an opportunity to convert an existing one into TypeScript. This is a perfect example of importing TypeScript modules into JavaScript ones.

Let's start doing this by adding TypeScript and types for React to our project:

npm install --save-dev typescript @types/react

Next step would be to tsconfig.json to the root folder of the project to configure the TypeScript compiler. The important parts of the configuration are:

esModuleInterop: true - we won't be able to import the React module without it
sourceMap: true - enables source map for debugging

tsconfig.json

{
  "compilerOptions": {
    "outDir": "./dist/",
    "sourceMap": true,
    "noImplicitAny": true,
    "module": "commonjs",
    "target": "es6",
    "jsx": "react",
    "esModuleInterop": true,
    "strictNullChecks": true
  },
  "include": [
    "./src/**/*"
  ],
  "rules": {
    "quotemark": [
      true,
      "single"
    ]
  }
}

After this we can write our TypeScript component

src/js-component/ts-component/ts-component.tsx

import React from 'react';

interface Props {
  myProp: number;
}

const TsComponent: React.FC<Props> = ({ myProp }) => (
  <div>
    Hi, I am a TypeScript component and I accept a number prop which is {myProp}
  </div>
);

export default TsComponent;

Now, if we try to import it from a JavaScript component:

src/js-component/js-component.tsx

import React from 'react';
import TsComponent from './ts-component/ts-component';

const JsComponent = () => (
  <>
    <div>Hi, I am a JavaScript component and I am calling a TypeScript component</div>
    <TsComponent myProp={123} />
  </>
);

export default JsComponent;

We'll get an error that Webpack is unable to resolve module ts-component/ts-component. Indeed, if we look at our Webpack configuration above, we'll see that we only instruct it to resolve .js and *.jsx files. Adding the .tsx to that list will not solve the problem - the babel-loader won't be able to parse the TypeScript syntax.

Luckily, we can solve this problem by adding the awesome-typescript-loader

So we just type

npm install --save-dev awesome-typescript-loader

in the terminal and add the following configuration to webpack.config.js:

webpack.config.js

  module: {
    rules: [
    // existing rules...

    // new TypeScript configuration
    { test: /\.(ts|tsx)$/, loader: 'awesome-typescript-loader' },
    ]
  },
  resolve: {
    // we also need to add *.tsx here
    extensions: ['.js', '.jsx', '.ts', '.tsx'],
  }

Now, if we run the code - it'll work flawlessly!

Congratulations! We've added our first TypeScript module into an existing JavaScript project! And more importantly, it didn't require a rewrite of the whole project.

How did that work?

You may wonder how we've managed to import a module written in one language into another? Especially, given that language - TypeScript - has more features than the language we've imported it into - JavaScript.

That was possible thanks to Webpack loaders that transform an imported module on the fly into JavaScript. You can read more about them here.

But do you have to use Webpack? No! You can use whatever module bundler including Browserify. The main thing is to be enable transformation of imported modules on the fly into JavaScript.

What about debugging?

Can you still you the Chrome Debugger? Yes, you still can! First of all, the tsconfig.json we've created instructs the TypeScript compilier to produce source maps. Then the initial webpack.config.js already included source maps. In the Chrome Debugger you step straight into TypeScript code!

Importing a JavaScript Module into TypeScript

Let's have a look at the opposite example - importing a JavaScript module into TypeScript. In this case, I'm talking about importing an own module, as opposed to a 3rd party library, but some of the techniques are the same.

Also, if we're talking about importing an own JavaScript module into TypeScript, why would you do that in the first place? Well, if you have a large JavaScript codebase and you're working on a TypeScript module you may want to re-use your existing work in JavaScript without rewriting it in TypeScript.

Let's add a simple JavaScript component:

src/ts-component/another-js-component/another-js-component.jsx

import React from 'react';
import PropTypes from 'prop-types';

const AnotherJsComponent = ({ a, b }) => (
  <div>
    Hi, I am another JavaScript components. And these are my properties:
    a: {a} & b: {b}
  </div>
);

AnotherJsComponent.propTypes = {
  a: PropTypes.number.isRequired,
  b: PropTypes.string.isRequired
};

export default AnotherJsComponent;

And we can simply import it into our TypeScript component:

src/ts-component/ts-component.tsx

import React from 'react';
import AnotherJsComponent from './another-js-component/another-js-component';

interface Props {
  myProp: number;
}

const TsComponent: React.FC<Props> = ({ myProp }) => (
  <>
    <div>
      Hi, I amm a TypeScript component and I accept a number prop which is {myProp}
    </div>
    <AnotherJsComponent a={1} b='foo' />
  </>
);

export default TsComponent;

It's all nice and easy, we don't need to change anything in the Webpack configuration. We can simply import JavaScript modules into the TypeScript code.

But are we missing anything?

Yes, we do miss type-safety! We don't know the types of the component properties we need to pass.

Is there a way to solve it without having to re-write AnotherJsComponent in TypeScript? Yes, we can provide our own type definitions while leaving the implementation of the JavaScript module intact.

That's exactly the approach that is used when dealing with 3rd party libraries - they either come with their own type definition files or we install them separately. In fact, we've already done that for React when we called npm install --save-dev @types/react.

What do we need to do to create our own type definition?

First, we need to create a file in the same folder as the imported module - another-js-component.d.ts and place the following contents there:

src/ts-component/another-js-component/another-js-component.d.ts

import React from 'react';

interface Props {
  a: number;
  b: string;
}

declare const AnotherJsComponent: React.FC<Props>;

export default AnotherJsComponent;

Don't Start with Renaming `.js` files into `.ts`

Some migration guides recommend you to start with renaming your .js files into .ts. That may sound reasonable, after all isn't TypeScript a superset of JavaScript? And should not existing JavaScript code be valid TypeScript code, as well?

Well, not so fast. Imagine, you have the following module:

const add = (a, b) => a + b;

export default add;

If we just change the file extention to .ts, we will get a TypeScript error. It will tell us that the input arguments a and b has an implicit type of any. And that will be completely reasonable. After all, it's the main purpose of TypeScript to provide static typing.

Now imagine if you're doing it on the whole codebase - it'll be full of TypeScript errors. Of course, you can set "noImplicitAny": false in your tsconfig.json. But that will not help you to prevent errors in legit TypeScript files.

Code

All the code is available on GitHub.

Conclusion

You don't have to move your projects to TypeScript in one big bang
Instead, you can move one module at a time
It's easy to import TypeScript code into JavaScript and vice versa
You can provide static types around JavaScript modules without having to rewrite them
Thanks to types definitions files
You also don't have to use Webpack. All you need is to be able to transform on the fly imported TypeScript modules into JavaScript

Forem: Mike Borozdin

Change Jest mock per test with ease

Sample app

Changing mock of non-default const

How does it work?

Why import entire module versus just the const we need?

TypeScript

Changing mock of export default const

TypeScript

Changing mock of non-default function

TypeScript

Changing mock of default function

TypeScript

Conclusion

Managing technical debt

What is technical debt?

Why do teams struggle to address technical debt?

Technical debt has business impact

How to prioritise technical debt?

Prioritise technical debt along with features and bug fixes

Sometimes you can just inflate time estimates

Old dependency versions can become technical debt

You can even refactor code as you go along

Scalability issues are not technical debt

Finally, build good relationship with product managers

Related posts

On being effective tech lead

Your main goal is to enable your team

Product

Technical

But... delegate and help your teammates grow

Communicate to provide clarity

Partner with product

But... then again help your fellow engineers engage with product

Trust your team

But... be prepared to ask question in a helpful way

Be strategic and stay technical

Be clear on how much time you can spend coding

Work with engineering managers (if you’re not line managing your team)

Finally

Move from Redux to MobX - reduce boilerplate

Video version

Problem with Redux

Enter MobX

Sample app

App code with Redux

Redux store so far

Redux wiring

Components

Enter MobX

MobX observables

Components in MobX - observers

What about components that modify data?

Source code

Conclusion

Q&A

Track a Virus: Open Source COVID-19 Dashboard with React, TypeScript, and MobX

Country comparison

Daily increase

World snapshot

Why another dashboard?

Of course, it is not perfect

Let's try to flatten the curve together

Shallow rendering & React Hooks. And why shallow rendering is good

Shallow Rendering & React Hooks

Testing

Why shallow rendering?

No unexpected side-effects

Test-driven development

Re-usable architecture

A few misconceptions about shallow rendering

Don't forget about end-to-end tests

Conclusion

Gradual move to TypeScript. Running JavaScript and TypeScript side-by-side

Example Project

Gradual Migration to TypeScript

Initial Webpack setup

Import TypeScript modules into JavaScript ones

How did that work?

What about debugging?

Changing mock of non-default `const`

Why import entire module versus just the `const` we need?

Changing mock of `export default const`

Components in MobX - `observers`

Don't Start with Renaming `.js` files into `.ts`