You’re reading an excerpt of my upcoming book on clean code, “Washing your code: write once, read seven times.” Preorder it on Leanpub or read a draft online.

Traditional loops, like for or while, are too low-level for common tasks. They are verbose and prone to off-by-one error. You have to manage the index variable yourself, and I always make typos with lenght. They don't have any particular semantic value except that you're doing some operation probably more than once.

Replacing loops with array methods

Modern languages have better ways to express iterative operations. JavaScript has may useful methods to transform and iterate over arrays, like .map() or .find().

For example, let’s convert an array of strings to kebab-case with a for loop:

const names = ['Bilbo Baggins', 'Gandalf', 'Gollum'];
for (let i = 0; i < names.length; i++) {
  names[i] = _.kebabCase(names[i]);
}

And now with the .map() method:

const names = ['Bilbo Baggins', 'Gandalf', 'Gollum'];
const kebabNames = names.map(name => _.kebabCase(name));

We can shorten it even more if our processing function accepts only one argument, and kebabCase from Lodash does:

const names = ['Bilbo Baggins', 'Gandalf', 'Gollum'];
const kebabNames = names.map(_.kebabCase);

But this may be a bit less readable than the expanded version, because we don’t see what exactly we’re passing to a function. ECMAS cript 6’s arrow functions made callbacks shorter and less cluttered, compared to the old anonymous function syntax:

const names = ['Bilbo Baggins', 'Gandalf', 'Gollum'];
const kebabNames = names.map(function(name) {
  return _.kebabCase(name);
});

Or let’s find an element in an array with a for loop:

const names = ['Bilbo Baggins', 'Gandalf', 'Gollum'];
let foundName;
for (let i = 0; i < names.length; i++) {
  if (names[i].startsWith('B')) {
    foundName = names[i];
    break;
  }
}

And now with the .find() method:

const names = ['Bilbo Baggins', 'Gandalf', 'Gollum'];
const foundName = names.find(name => name.startsWith('B'));

In both cases I much prefer versions with array methods than with for loops. They are shorter and we're not wasting half the code on iteration mechanics.

Implied semantics of array methods

Array methods aren’t just shorter and more readable; each method has its own clear semantic:

• .map() says we're transforming an array into another array with the same number of elements;
• .find() says we're finding a single element in an array;
• .some() says we're testing that the condition is true for some array elements;
• .every() says we're testing that the condition is true for every array element.

Traditional loops don’t help with understanding what the code is doing until you read the whole thing.

We’re separating the “what” (our data) from the “how” (how to loop over it). More than that, with array methods we only need to worry about our data, which we’re passing in as a callback function.

When you use array methods for all simple cases, traditional loops signal to the code reader that something unusual is going on. And that’s good: you can reserve brain resources for better understanding the unusual, more complex cases.

Also don’t use generic array methods like .map() or .forEach() when more specialized array methods would work, and don't use .forEach() when .map() would work:

const names = ['Bilbo Baggins', 'Gandalf', 'Gollum'];
const kebabNames = [];
names.forEach(name => {
  kebabNames.push(_.kebabCase(name));
});

This is a more cryptic and less semantic implementation of .map(), so better use .map() directly like we did above:

const names = ['Bilbo Baggins', 'Gandalf', 'Gollum'];
const kebabNames = names.map(name => _.kebabCase(name));

This version is much easier to read because we know that the .map() method transforms an array by keeping the same number of items. And unlike .forEach(), it doesn't require a custom implementation nor mutate an output array. Also the callback function is now pure: it doesn't access any variables in the parent function, only function arguments.

Dealing with side effects

Side effects make code harder to understand because you can no longer treat a function as a black box: a function with side effects doesn’t just transform input to output, but can affect the environment in unpredictable ways. Functions with side effects are also hard to test because you’ll need to recreate the environment before each test and verify it after.

All array methods mentioned in the previous section, except .forEach(), imply that they don't have side effects, and that only the return value is used. Introducing any side effects into these methods would make code easy to misread since readers wouldn't expect to see side effects.

.forEach() doesn't return any value, and that's the right choice for handling side effects when you really need them:

errors.forEach(error => {
  console.error(error);
});

for of loop is even better:

• it doesn’t have any of the problems of regular for loops, mentioned in the beginning of this chapter;
• we can avoid reassignments and mutations, since we don’t have a return value;
• it has clear semantics of iteration over all array elements, since we can’t manipulate the number of iterations, like in a regular for loop. (Well, almost, we can abort the loops with break.)

Let’s rewrite our example using for of loop:

for (const error of errors) {
  console.error(error);
}

Sometimes loops aren’t so bad

Array methods aren’t always better than loops. For example, a .reduce() method often makes code less readable than a regular loop.

Let’s look at this code:

const tableData = [];
if (props.item && props.item.details) {
  for (const client of props.item.details.clients) {
    for (const config of client.errorConfigurations) {
      tableData.push({
        errorMessage: config.error.message,
        errorLevel: config.error.level,
        usedIn: client.client.name
      });
    }
  }
}

My first reaction would be to rewrite it with .reduce() to avoid loops:

const tableData =
  props.item &&
  props.item.details &&
  props.item.details.clients.reduce(
    (acc, client) => [
      ...acc,
      ...client.errorConfigurations.reduce(
        (inner, config) => [
          ...inner,
          {
            errorMessage: config.error.message,
            errorLevel: config.error.level,
            usedIn: client.client.name
          }
        ],
        []
      )
    ],
    []
  );

But is it really more readable?

After a cup of coffee and a chat with a colleague, I’ve ended up with a much cleaner code:

const tableData =
  props.item &&
  props.item.details &&
  props.item.details.clients.reduce((acc, client) =>
    acc.concat(
      ...client.errorConfigurations.map(config => ({
        errorMessage: config.error.message,
        errorLevel: config.error.level,
        usedIn: client.client.name
      }))
    )
  );

I think I still prefer the double for version, but I'll be happy with both versions, the original and the second rewrite, if I had to review such code.

(Though tableData is a really bad variable name.)

Iterating over objects

There are many ways to iterate over objects in JavaScript. I equally dislike them all, so it’s hard to choose the best one. Unfortunately there’s no .map() for objects, though Lodash does have three methods for object iteration, so it's a good option if you're already using Lodash in your project.

const allNames = {
  hobbits: ['Bilbo', 'Frodo'],
  dwarfs: ['Fili', 'Kili']
};
const kebabNames = _.mapValues(allNames, names =>
  names.map(name => _.kebabCase(name))
);

If you don’t need the result as an object, like in the example above, Object.keys(), Object.values() and Object.entries() are also good:

const allNames = {
  hobbits: ['Bilbo', 'Frodo'],
  dwarfs: ['Fili', 'Kili']
};
Object.keys(allNames).forEach(race =>
  console.log(race, '->', allNames[race])
);

Or:

const allNames = {
  hobbits: ['Bilbo', 'Frodo'],
  dwarfs: ['Fili', 'Kili']
};
Object.entries(allNames).forEach(([race, value]) =>
  console.log(race, '->', names)
);

I don’t have a strong preference between them. Object.entries() has more verbose syntax, but if you use the value ( names in the example above) more than once, the code would be cleaner than Object.keys(), where you'd have to write allNames[race] every time or cache this value into a variable at the beginning of the callback function.

If I stopped here, I’d be lying to you. Most of the articles about iteration over objects have examples with console.log(), but in reality you'd often want to convert an object to another data structure, like in the example with _.mapValues() above. And that's where things start getting uglier.

Let’s rewrite our example using .reduce():

const kebabNames = Object.entries(allNames).reduce(
  (newNames, [race, names]) => {
    newNames[race] = names.map(name => _.kebabCase(name));
    return newNames;
  },
  {}
);

With .forEach():

const allNames = {
  hobbits: ['Bilbo', 'Frodo'],
  dwarfs: ['Fili', 'Kili']
};
const kebabNames = {};
Object.entries(allNames).forEach(([race, names]) => {
  kebabNames[race] = names.map(name => name.toLowerCase());
});

And with a loop:

const kebabNames = {};
for (let [race, names] of Object.entries(allNames)) {
  kebabNames[race] = names.map(name => name.toLowerCase());
}

And again .reduce() is the least readable option.

In later chapters I’ll urge you to avoid not only loops but also reassigning variables and mutation. Like loops, they often lead to poor code readability, but sometimes they are the best choice.

But aren’t array methods slow?

You may think that using functions is slower than loops, and likely it is. But in reality it doesn’t matter unless you’re working with millions of items.

Modern JavaScript engines are very fast and optimized for popular code patterns. Back in the day we used to write loops like this, because checking the array length on every iteration was too slow:

var names = ['Bilbo Baggins', 'Gandalf', 'Gollum'];
for (var i = 0, namesLength = names.length; i < namesLength; i++) {
  names[i] = _.kebabCase(names[i]);
}

It’s not slow anymore. And there are other examples where engines optimize for simpler code patterns and make manual optimization unnecessary. In any case, you should measure performance to know what to optimize, and whether your changes really make code faster in all important browsers and environments.

Also .every(), .some(), .find() and .findIndex() will short circuit, meaning they won't iterate over more array elements than necessary.

Start thinking about:

• Replacing loops with array methods, like .map() or .filter().
• Avoiding side effects in functions.

If you have any feedback, tweet me, open an issue on GitHub, or email me at artem@sapegin.ru. Preorder the book on Leanpub or read a draft online.

Originally published at https://blog.sapegin.me on May 7, 2019.

The conference

React Finland is one of my favorite conferences. It was my second time and both times I felt good as a speaker. Talks were great: two days with big breaks to have enough time to talk to your friends. I liked the selection of talks: design systems, animation, architecture. The venue (a building with a tower on a photo above) was also good.

The talks

MobX — The Journey by Michel Weststrate

Slides, video.

• If you can’t sell the library, sell the problem.
• “MobX […] tries to enable you to go home early each day.”
• Always keep learning: stay slightly out of your comfort zone.
• Open source good parts: learning, happy users, core contributors, beautiful conferences, awesome people, video tutorials, workshops, book, getting a raise, seeing others succeed.
• Open source bad parts: making your library work with all other libraries, no holidays, now you have two jobs.
• When filing issues, remember: you are asking for free help on something you are being paid for.
• Guard your heart and live a balanced life.

Artem Sapegin ☕ on Twitter

First #ReactFinland talk by @mweststrate.

Append-only development with React: An intro to Behavioral programming by Luca Matteis

Slides, video.

• “Programming language are practically irrelevant in making products.”
• Code maintenance is the root of the problem.
• Make changes without having to read and maintain the code.
• Newly added code can change how old code is executed.
• Behavioral programming for JavaScript.

Mind-Reading with Adaptive and Intelligent UIs in React by David Khourshid

Slides, video.

• Adapt to people, not just devices.
• Microsoft Clippy is the first adaptive UI.
• A/B tests are ineffective.
• Collect stats on state changes and optimize flows.

Artem Sapegin ☕ on Twitter

Clippy in @DavidKPiano talk at #ReactFinland.

A Common Design Language. Let Designers and Developers talk to each other by Andrey Okonetchnikov

Slides, video.

• Design: typography, color and spacing.
• Developers talk in code.
• Designers talk in UI primitives.
• Design tools talk in shapes, like arrow and triangles.
• Common language: UI primitives.
• component-driven.io: component-driven design & development for the modern web.

Artem Sapegin ☕ on Twitter

That guy again! @okonetchnikov at #ReactFinland.

A practical guide to building your design system infrastructure by Varya Stepanova

Slides, video.

• Design system is shared practices, tools, processes and community.
• Living style guides: React Styleguidist, Storybook.
• Visual regression tests.
• Uses Styleguidist to document plain HTML components.
• Design system site: single source of truth.
• Automate everything.
• Welcome contributions: edit on GitHub button, list of contributors.
• Blogging with WordPress as a backend and Gatsby.

Artem Sapegin ☕ on Twitter

@varya_en @varya_en is using @styleguidist to generate documentation for plain CSS/HTML components with @styleguidist.

12 Tips for More Accessible React Apps by Manuel Matuzovic

Slides, video.

1. Create a sound document outline: start with h1 and don't skip levels.
2. Hide content correctly: display: none, visibility: hidden and hidden are hiding content from screen readers, use a combination of CSS properties that hides content only visually or VisuallyHidden component from Reach UI.
3. Use <button> if you need a button: they are focusable by default and support keyboard events.
4. Use fragments to avoid invalid HTML: <tr><div><td> → <tr><><td>.
5. Take care of focus management: can be a problem for modals, put focus inside a modal on open and don’t let it leave the modal.
6. Make notifications accessible to everyone: use role="alert" or role="status" to make screen readers announce notifications.
7. Announce page changes: on single page applications screen readers should read the page title on navigation. Check out Reach Router.
8. Test your React code automatically: use React-Axe and eslint-plugin-jsx-a11y.

Artem Sapegin ☕ on Twitter

@mmatuzo Automating heading levels, @mmatuzo at #ReactFinland.

Delightful UI animations by understanding the brain by Bruno Lourenço

Video.

• Animation — an illusion of movement.
• React Morph: morphing UI transitions.
• Creates a clone of an element and uses FLIP technique to do the morphing animation.

Artem Sapegin ☕ on Twitter

@brunnolou I'm definitely going to try react-morph, it looks incredible! #ReactFinland

Custom CSS is the path to inconsistent UI by Artem Sapegin

Slides, video.

• We use custom styles mostly for typography, whitespace and layout.
• This leads to inconsistent UI because CSS is too expressive.
• Design tokens are the first step to achieve UI consistency.
• But not all combinations of design tokens are good: you may create unreadable text for example.
• UI primitives (primitive components) is the solution.
• Text and Heading components to render all text in an application.
• Box, Flex and Grid (Stack) components to define whitespace and layouts.
• Use styled-system to create such components: works with any CSS in JS library.

James Stone on Twitter

CSS is too expressive" - @iamsapegin #ReactFinland

Creating layouts that last by Artem Zakharchenko

Video.

• Spacing is important to build maintainable layout.
• Defining margins and padding directly on components isn’t the most maintainable way.
• Atomic layout is a library to create declarative layouts with CSS Grid.
• Define layout areas as a string template.
• Responsive props.
• Render areas using a render prop.

Artem Sapegin ☕ on Twitter

More layouts, more spacing by @kettanaito at #ReactFinland.

Scalable (Design) Systems with TypeScript by Tejas Kumar

Slides, video.

• TypeScript is a good choice for design systems: enforces contracts, confidence to make changes, allows you to scale.
• Uses React Styleguidist and TypeScript for their design system.
• Hacked Styleguidist to use TypeScript and Monaco editor in component examples.

Artem Sapegin ☕ on Twitter

@TejasKumar_ TypeScript editor with autocomplete in @styleguidist by @TejasKumar_ at #ReactFinland - super cool!

Building resilient frontend architecture by Monica Lent

Slides, video.

• Refactoring only temporarily helps with technical debt.
• Second system effect: the tendency of small, elegant, and successful systems to be succeeded by over-engineered, bloated systems because of inflated expectations and overconfidence.
• “‘Legacy code’” often differs from its suggested alternative by actually working and scaling.” — Bjarne Stroustrup.
• The real cost of software is not the initial development, but maintenance over time.
• Architecture as enabling constraints: constraints about how we use data and code that help us move faster over time.
• Shared dependencies: add them to the design system or copy-paste.
• Decoupled code is better than DRY.

Three constraints you can use today for more resilient frontend architecture:

1. Source code dependencies must point inward: don’t depend on other team’s code.
2. Be conservative about code reuse: avoid coupling code that diverges over time.
3. Enforce your boundaries: don’t let people depend on your code (with dependency-cruiser).

Artem Sapegin ☕ on Twitter

@monicalent Monica's @monicalent talk was my favorite at #ReactFinland - really resonates with me 🤓

“Intuitive” Tooling by Carolyn Stransky

Slides, video.

• Hard to learn things: TypeScript, Redux, GraphQL, Gatsby, Flexbox.
• “We mistake familiarity for simplicity” — Jim Fisher.
• Spiral of silence.
• Empathy matters more in education.
• Start an internal mentorship program.
• Ban words like “easy” from your vocabulary.
• Just because you understand something doesn’t mean that someone else will too.

Artem Sapegin ☕ on Twitter

@carolstran Flexbox is hard to learn - definitely agree with @carolstran #ReactFinland.

Links

• Sketch notes by Patrick Hund
• The first day and the second day notes by Boris Serdiuk (includes lightning talks)
• My photos
• Shared photo album

Subscribe to my newsletter: https://tinyletter.com/sapegin

React Finland 2019 was originally published in component-driven on Medium, where people are continuing the conversation by highlighting and responding to this story.

Developers and code reviewers have seemingly conflicting goals: developers want to ship their code fast, reviewers want high code quality. But in my opinion these are two sides of the same goal: keep development velocity high by shipping high quality and maintainable code. Reviewers want to help developers to ship less bugs to production and make code easier to understand so feature improvements can be done faster.

By following these recommendations you’ll be able to reduce number of code review iterations and ship code faster.

Before you start

Every team has its own standards and best practices. In good teams they are well documented. Reading such documentation in advance will save you many code review iterations.

If you’re new to a team, technologies or an area of the codebase, pairing with someone more experienced could be a great way to learn and complete your task faster.

Split big tasks into several diffs. Just reading 1000 lines of code will take a reviewer more than an hour and a cup of coffee. And each iteration will require another hour. It’s hard to say when a diff becomes too big, but the general rule of thumb is: the less experience you have, the smaller your diffs should be.

By splitting a big task into smaller ones, you’ll get feedback faster, before you’ve spent too much time on a less than ideal implementation. Even better if you discuss, how you’re going to implement a complex feature, with a more experienced developer before you start working.

Make sure your code is ready

Before sending your code to review, check it for debug code, commented out code and TODO comments, make sure all kinds of automated tests, type checks and linters are passing. Make sure there are no new lint warnings, and code is formatted, if you’re using a tool like Prettier.

Manual code reviews are great for improving readability, architecture or accessibility. When reviewers are distracted by catching typos and minor issues that could have been caught by automated checks, they’ll be more likely to miss important problems.

Do a self review

Think what may be unclear to a person reading the code, what kind of questions they may have, if they don’t know everything you know about the task. Answer these questions by making code more clear or by adding comments explaining why some code was written and why it was written in a certain way.

If there are obvious simpler alternatives that won’t work for your case, explain why.

These kinds of changes and comments will help everyone who’s going to read the code, not only code reviewers. Good comments may also save your code from accidental “refactoring” that makes code simpler but removes important functionality, when it’s not clear why this “extra” code is needed.

Show what you’ve done

It helps a lot to see what the code in the diff is actually doing. Mention related tickets, add screenshots or even GIFs for all UI changes.

Tip: Kap is a nice free app to record GIFs on macOs.

Ask questions

Code review is a great way of sharing knowledge between developers. It works in both directions: from a reviewer to a developer and from a developer to a reviewer. Code review is a dialog where two, or sometimes more, people are working together on improving a piece of code. To make it work, you need to understand each comment and the reasoning behind it.

Keep asking questions until everything is clear: why something is a problem and what is the proposed solution. Code review comments aren’t always the best place to have long discussions, sometimes it’s better to talk to your reviewer in Slack or even better in person. It’s a good idea to add a short summary of such discussion as a comment to your diff.

Live review can be another way to improve communication. In that case the developer and the reviewer will sit together and go though the code. The reviewer will explain all the problems in details and make sure there’s no misunderstanding.

Don’t do changes for the sake of changes

Reviewers don’t know as much as you do about your task, so some of their suggestions will not make any sense for what you’re doing. There’s no rule that code reviewer is always right, unless it’s a team standard, and even standards have exceptions sometimes. Sometimes suggestions sound good but don’t work in reality.

Use your own judgement, don’t do changes if you see that they aren’t improving the code. Explain why you think that the suggestion doesn’t work for you.

Even if you’ve done the change but don’t like the result, revert it before the next review iteration. A good reviewer will likely notice this too, and asks you to revert the change.

Don’t ignore comments

You don’t have to agree with everything code reviewer is saying or to apply all their suggestions, but if you just ignore some comments, a code reviewer will likely write it again.

If you’re not going to do a particular suggestion or have tried and it didn’t work, reply to a review comment with a short explanation to avoid any possible misunderstanding.

Make it clear when you’re done with the changes

Every developer works differently: some will commit all the changes at once, some will commit each change separately. It’s hard for reviewers to know when you’re done with all their feedback and ready for another iteration.

Writing a short comment like “Ready for another iteration” will make it clear, and you’ll get that another iteration sooner.

Make the next step

Development is an iterative process, so is code reviewing. Code review suggestions are possible improvements to the current state of the code, not it’s final state. Often one improvement makes another improvement obvious, and a good code reviewer will let you know about it.

But you don’t have to wait and loose another iteration: do one more self-review and see what could be the next thing.

For example a reviewer has asked you to simplify three functions and make code more consistent. But after you’ve done it, it’s now clear that all three functions are doing the same thing, and you can replace them with a single function.

Conclusion

Don’t treat code reviews as a distraction. They are here to help you ship better code and spend less time on future changes. Help reviewers help you.

Start reviewing someone else’s code yourself, even if you can’t approve it. You’ll improve your own coding skills by reading more code and thinking how to make it better.

Subscribe to my newsletter: https://tinyletter.com/sapegin

Thanks to Anita Kiss, Oliver Joseph Ash, Matt Hamlin, Oleg Isonen, Alex Orange.

️How to get your code reviewed faster was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

When Jest announced snapshot tests in 2016, I was very excited. It felt like a perfect solution for testing React component. Since then I’ve written fewer and fewer snapshot tests. In this article I’ll try to explain why.

I’ll talk mostly about testing React components, because that’s where I’ve used or have seen snapshots the most, but the same can be said about testing other things.

So, why snapshots are problematic?

Easy to commit snapshots with bugs

When you write expect(mycomponent).toMatchSnapshot(), Jest creates a snapshot file, like mytest.spec.js.snap, with all snapshots of your test file. You don’t see this file unless you really want to.

That’s a problem: you don’t know if your code is correct yet and, unless you carefully read each line of your snapshot file, you may commit code with a bug and a snapshot that ensures that the bug is still there.

Failures are hard to understand

It’s often hard to see what changed by looking at the snapshot failure diff: did the snapshot fail because of your intended changes or because you’ve introduced a bug?

We tend to update snapshots without thinking

On a big project a simple change can lead to failures in dozens of snapshots in different parts of the codebase. Understanding each failure takes a lot of time, so often developers just update snapshots without looking at them at all, especially if it’s not their code.

Coupling with low level modules

Snapshots — especially if you don’t use shallow rendering — often break on changes in low level components or on third-party packages updates.

A little change in a Button component may lead to a failure of hundreds of snapshots, even when everything works fine. A Button component is an implementation detail, and tests should pass if a button still behaves like a button.

Test intentions are hard to understand

Snapshot tests like “should render the default state of a component” are common but don’t really explain what exactly, if anything, they’re testing.

Such snapshots will break on any change to the markup, even if the behavior remains the same.

A false sense of security

Snapshots offer no guarantees that component appearance or behavior is correct. Despite this it’s easy to believe that they do, and write tests that don’t actually test anything, but give you high test coverage.

Snapshots only verify that the component renders (meaning its HTML, not how it looks in the browser) the same thing, which is rarely important knowledge.

Hint: visual snapshot testing is a way to verify that your component’s appearance is the same as before. There are many tools, like Percy, Chromatic or Shutter, to do that.

What to use instead of snapshots

Let’s look at a typical test (I’ve written similar tests myself):

test('show a success message after submission', () => {
  const { getByText } = render(<Form />);
  expect(wrapper).toMatchSnapshot();
  fireEvent.click(getByText('Send an owl'));
  expect(wrapper).toMatchSnapshot();
});

We have two snapshots here: both will break on any markup change. Intention of both isn’t clear. The first is likely covered by other test cases, so we can remove it. In the second we likely want to know if the success message was shown instead of a form, which isn’t at all clear from the code. We can test exactly that:

test('show success message after submission', () => {
  const { getByText, getByTestId } = render(<Form />);
  fireEvent.click(getByText('Send an owl'));
  // The form has gone
  expect(getByTestId('message-form')).not.toBeDefined();
  // The success message is here
  expect(
    getByTestId('message-alert').textContent
  ).toMatchInlineSnapshot(`Owl has been sent!`);
});

The test intention is now clear: we click the submit button and instead of a form we see a success message. This test won’t fail because of primitive components or third-party dependencies updates. This test won’t fail because of the layout changes that don’t affect the behavior.

Hint: I’m using the react-testing-library by Kent C. Dodds in this example.

When to use snapshots

I think snapshots are still useful in some cases:

• Very short output with clear intent, like class names or error messages:

expect(className).toMatchInlineSnapshot(
  `Box Text Text--align-center Text--variation-warning`
);

• When you really whant to verify that the output is the same:

Babel plugins are a good example of that, see babel-plugin-tester:

exports[`macros basic usage: basic usage 1`] = `
"
import wcImport from \\"../macro\\";
const asyncModule = wcImport(\\"./MyComponent\\");

      ↓ ↓ ↓ ↓ ↓ ↓

const asyncModule = import(/* webpackChunkName: MyComponent */ \\"./MyComponent\\");

"
`;

Snapshot dos

• Use inline snapshots to make snapshots visible inside the test file and to help you to keep them small.

expect(error).toMatchInlineSnapshot(`Error: Out of cheese!`);

• Use snapshot property matchers to avoid storing generated values, like dates or IDs.

expect(user).toMatchSnapshot({
  createdAt: expect.any(Date),
  id: expect.any(Number)
});

Hint: eslint-plugin-jest have two rules, prefer-inline-snapshots and no-large-snapshots, that may help you keep your snapshots healthy.

Snapshot don’ts

• Avoid snapshotting file paths: they’ll fail on other platforms because of different delimiters (\ vs /).
• Avoid snapshotting dates and times: even if the date depends only on the input, it may be different in another time zone, and your tests will fail.

Conclusion

Snapshots are very useful in some rare cases, but often they give you a false sense of security while making the codebase harder to change.

Check out the Effective Snapshot Testing article by Kent C. Dodds for more ideas on how to use snapshot tests.

P. S. Jest cheat sheet and React Testing Examples will answer most questions you may have when writing Jest tests.

Subscribe to my newsletter: https://tinyletter.com/sapegin

❤️ Thanks to Oliver Joseph Ash, Ovidiu Cherecheș, Manjula Dube, Matt Hamlin, Patrick Hund, Oleg Isonen, Morgan Packard, Oliver Turner and Andy Wermke for their feedback.

This story is published in Noteworthy, where 10,000+ readers come every day to learn about the people & ideas shaping the products we love.

Follow our publication to see more product & design stories featured by the Journal team.

This is a short cheat sheet for developers migrating from React 15 to React 16, or from earlier 16.x versions to 16.6. It focuses on features you’ll use often.

Returning multiple elements from components with fragments

Splitting UI into small reusable components may lead to creation of unnecessary DOM elements, like when you need to return multiple elements from a component. React 16 has several options to avoid that:

// React 15: extra wrapper element
const Breakfast = () => (
  <ul>
    <li>Coffee</li>
    <li>Croissant</li>
    <li>Marmalade</li>
  </ul>
);

// React 16.0: array (note that keys are required)
const Breakfast = () => [
  <li key="coffee">Coffee</li>,
  <li key="croissant">Croissant</li>,
  <li key="marmalade">Marmalade</li>
];

// React 16.2: fragment
const Breakfast = () => (
  <React.Fragment>
    <li>Coffee</li>
    <li>Croissant</li>
    <li>Marmalade</li>
  </React.Fragment>
);

// React 16.2: fragment (short syntax)
const Breakfast = () => (
  <>
    <li>Coffee</li>
    <li>Croissant</li>
    <li>Marmalade</li>
  </>
);

// React 16: fragments composition
const Meals = (
  <ul>
    <Breakfast />
    <Lunch />
    <Dinner />
  </ul>
);

Note that the short syntax may not be supported by the tools you’re using.

Returning strings and numbers from components

In React 16 components can return strings and numbers. This is useful for components that don’t need any markup, like internationalization or formatting:

// React 15
const LocalDate = ({ date }) => (
  <span>
    {date.toLocaleDateString('de-DE', {
      year: 'numeric',
      month: 'long',
      day: 'numeric'
    })}
  </span>
);

// React 16
const LocalDate = ({ date }) =>
  date.toLocaleDateString('de-DE', {
    year: 'numeric',
    month: 'long',
    day: 'numeric'
  });

Cancelling setState() to avoid rerendering

In React 15 it wasn’t possible to cancel setState() and avoid rerendering, if your next state was based on the previous state. In React 16 you could return null in setState()’s callback:

// React 16
handleChange = event => {
  const city = event.target.value;
  this.setState(
    prevState => (prevState.city !== city ? { city } : null)
  );
};

In this example calling handleChange() with the same city name as in the state won’t cause a rerender.

Avoiding prop drilling with the official context API (16.3)

Prop drilling is when you’re passing some data to a deeply nested component using a prop, so you have to add this prop to each layer of your React component tree between a component that owns the data and a component that consumes it.

class Root extends React.Component {
  state = { theme: THEME_DARK };
  handleThemeToggle = theme =>
    this.setState(({ theme }) => ({
      theme: theme === THEME_DARK ? THEME_LIGHT : THEME_DARK;
    }));
  render() {
    return (
      <Page
        onThemeToggle={this.handleThemeToggle}
        {...this.state}
        {...this.props}
      />
    );
  }
}

// Each layer will have to pass theme and theme toggle handler props
<SomeOtherComponent
  onThemeToggle={props.onThemeToggle}
  theme={props.theme}
/>;

// Many layers below
const Header = ({ theme, onThemeToggle }) => (
  <header className={cx('header', `header--${theme}`)}>
    ...
    <button onClick={onThemeToggle}>Toggle theme</button>
  </header>
);

That’s a lot of boilerplate code! With the context API we can access our theme props anywhere in the component tree:

const ThemeContext = React.createContext(THEME_DARK);

// We should wrap our app in this component
class ThemeProvider extends React.Component {
  state = { theme: THEME_DARK };
  handleThemeToggle = theme =>
    this.setState(({ theme }) => ({
      theme: theme === THEME_DARK ? THEME_LIGHT : THEME_DARK
    }));
  render() {
    return (
      <ThemeContext.Provider
        value={{
          onThemeToggle: this.handleThemeToggle,
          theme: this.state.theme
        }}
      >
        {this.props.children}
      </ThemeContext.Provider>
    );
  }
}

// And then use theme consumer anywhere in the component tree
const Header = () => (
  <ThemeContext.Consumer>
    {({ theme, onThemeToggle }) => (
      <header className={cx('header', `header--${theme}`)}>
        ...
        <button onClick={onThemeToggle}>Toggle theme</button>
      </header>
    )}
  </ThemeContext.Consumer>
);

Check out an example on CodeSandbox.

Updating state based on props with getDerivedStateFromProps() (16.3)

The getDerivedStateFromProps() lifecycle method is a replacement for componentWillReceiveProps(). It’s useful when you have a prop with a default value for a state property, but you want to reset the state when that prop changes. For example, a modal that has a prop that says if it’s initially open, and a state that says if a modal is open now:

// React 15
class Modal extends React.Component {
  state = {
    isOpen: this.props.isOpen
  };
  componentWillReceiveProps(nextProps) {
    if (nextProps.isOpen !== this.state.isOpen) {
      this.setState({
        isOpen: nextProps.isOpen
      });
    }
  }
}

// React 16.3
class Modal extends React.Component {
  state = {};
  static getDerivedStateFromProps(nextProps, prevState) {
    if (nextProps.isOpen !== prevState.isOpen) {
      return {
        isOpen: nextProps.isOpen
      };
    }
  }
}

The getDerivedStateFromProps() method is called when a component is created and when it receives new props, so you don’t have to convert props to state twice (on initialization and in componentWillReceiveProps()).

Rerendering function components on props change with React.memo() (16.6)

React.memo() does the same for function components as PureComponent does for class components: only rerenders the component if its props change.

const MyComponent = React.memo(props => {
  /* Only rerenders if props change */
});

Easier access to context in class components with contextType (16.6)

Class.contextType simplifies access to the React context in class components:

class App extends React.Component {
  static contextType = ThemeContext;
  componentDidMount() {
    const { theme } = this.context;
    /* ... */
  }
  componentDidUpdate() {
    const { theme } = this.context;
    /* ... */
  }
  componentWillUnmount() {
    const { theme } = this.context;
    /* ... */
  }
  render() {
    const { theme } = this.context;
    return (
      <h1>
        {theme === THEME_DARK
          ? 'Welcome to the dark side!'
          : 'Welcome to the light side!'}
      </h1>
    );
  }
}

Other new features

React 16.x has many other useful features:

• error boundaries;
• portals;
• forwarding refs (16.3);
• the new context API (16.3);
• getSnapshotBeforeUpdate() lifecycle method (16.3);
• StrictMode component (16.3);
• pointer events (16.4);
• profiler (16.5);
• React.lazy (16.6);
• static getDerivedStateFromError() (16.6).

I also highly recommend Nik Graf’s course on React 16 at Egghead.

Subscribe to my newsletter: https://tinyletter.com/sapegin

React 16.0–16.6 new features for every day use was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

👋 Support Styleguidist on Open Collective 👋

I’m happy to announce a new major release of React Styleguidist.

Webpack 4 support

Webpack 3 is still supported too.

Node.js 6 is the lowest supported version

Styleguidist won’t work with Node.js 4 anymore.

Examples are wrapped in React.Fragment

You don’t need to wrap multiple JSX tags in a div anymore.

// 6.x
<div>
  <Button primary>Primary button</Button>
  <Button secondary>Secondary button</Button>
</div>


// 7.x
<Button primary>Primary button</Button>
<Button secondary>Secondary button</Button>

Fragment JSX syntax also works:

// 7.x
<>
  <Button primary>Primary button</Button>
  <Button secondary>Secondary button</Button>
</>

New format of the template option

We’re now using mini-html-webpack-plugin and @vxna/mini-html-webpack-template instead of html-webpack-plugin. This will make things like adding a favicon or fonts from Google Fonts much easier.

If you’re using a custom HTML template, you need to update your style guide config. Instead of:

// 6.x
module.exports = {
  template: './styleguie/template.html'
}

You need to use something like this:

// 7.x
module.exports = {
  template: {
    favicon: 'https://assets-cdn.github.com/favicon.ico'
  }
}

Or like this:

// 7.x
module.exports = {
  template: {
    head: {
      links: [
        {
          rel: 'stylesheet',
          href: 'https://fonts.googleapis.com/css?family=Roboto'
        }
      ]
    }
  },
  theme: {
    fontFamily: {
      base: '"Roboto", sans-serif'
    }
  }
}

There are a few more changes, see a full change log.

❤️ Huge thanks to Andrey Okonetchnikov, Nikolay Burlov, Rubén Moya and others for help with this release️! ❤️

React Styleguidist 7.0.0- hello webpack 4, goodbye Node.js 4 was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

I love the open source community, especially the React ecosystem. Most of the folks there are supernice and helping each other. But sometimes something goes wrong.

I value my time and even more I value my mental health. I want to continue contributing to open source and avoid burnout. I try to be nice and helpful to every user of my projects. But sometimes it’s hard.

Every time I see or feel that someone is complaining about my project or my actions, or any unhealthy behavior towards me or other users, I immediately lock the conversation, or even block the user. I see it as the only way to continue working on open source.

There are many ways you can make folks in the open source community happier:

• new feature specs (better than just ideas because they’re often not actionable);
• detailed easily reproducible bug reports;
• any maintenance help, like answering questions on GitHub, Stack Overflow or Twitter.
• bugfixes;
• new features;
• docs improvements.

Other people are experiencing similar issues:

• The Dark Side of Open Source by Karolina Szczur
• Dear JavaScript by James Kyle
• The Reality of Developer Burnout by Kenneth Reitz

Let’s keep this community healthy and friendly!

No complaints policy was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

What’s the problem

The only thing that many times was preventing me from extracting some generic function to a separate package is a need to copy and modify a dozen of config files — all that .somethingrcs — just to publish a 50-line function.

These support files are usually only slightly different in all your projects. For example, a .gitignore file has node_modules and editor artifacts that you want to share between all your projects, but some projects have extra lines there that you don’t want in other projects. We need a way to keep in sync the common parts but allow per-project customizations.

Template-based tools, like Yeoman, are good for initial project bootstrapping but don’t work well for updates: they would overwrite a file with a new version and you’ll lose your customizations.

What’s Mrm

Mrm takes a different approach. It works similar to codemods: instead of a template that would overwrite everything, you’re describing in code how to modify or create files to achieve the desired state of the file.

Minimal changes

Mrm tries to do minimal changes by inferring indentation style or reading it from the EditorConfig, and keeping comments in JSON files.

Minimal config

It has minimal required configuration: it’ll use values from the project itself or from the environment, like reading your name and email from your Git or npm configs.

Focused but rich API

Mrm has utilities to work with popular config file formats: JSON, YAML, INI and new line separated text files; install npm packages; and file operations.

This allows you to create smart tasks, so the result depends on your project needs.

Available tasks

Mrm has many tasks out of the box: CodeCov, EditorConfig, ESLint, .gitignore, Jest, lint-staged, Prettier, semantic-release, React Styleguidist, stylelint, Travis CI, TypeScript, package.json, contributing guidelines, license and readme file. You can create your own task or combine multiple tasks using aliases.

For example, the Jest task:

• adds npm scripts to run Jest;
• adds configuration to package.json if needed;
• updates .gitignore, .npmignore, .eslintignore with common patterns;
• installs Jest, babel-jest, ts-jest or Enzyme if needed;
• tries to get rid of Mocha and AVA configs and dependencies;
• suggests to us jest-codemods if projects used other test frameworks.

Or the gitignore task that will add new lines to the .gitignore file but won’t remove per-project customizations:

Installation and usage

Install Mrm from npm:

npm install -g mrm

And run like this:

mrm gitignore
mrm license --config:licenseFile LICENSE

Or run Mrm via npx without installation:

npx mrm gitignore
npx mrm license --config:licenseFile LICENSE

Optionally, create a config file at ~/.mrm/config.json or ~/dotfiles/mrm/config.json instead of passing values via command line:

{
  "github": "sapegin",
  "eslintPreset": "airbnb",
  "aliases": {
    // Aliases to run multiple tasks at once
    "node": ["license", "readme", "editorconfig", "gitignore"]
  }
}

See more usage examples and options in the docs.

Creating your own tasks

The real power of Mrm is in custom tasks and mrm-core library that gives you tools to work with config files, dependencies, file operations, etc.

The simplest task could look like this:

// Mrm module to work with new line separated text files
const { lines } = require('mrm-core');

function task() {
  // Read .gitignore if it exists
  lines('.gitignore')
    // Add lines that do not exist in a file yet,
    // but keep all existing lines
    .add(['node_modules/', '.DS_Store'])
    // Update or create a file
    .save();
}

task.description = 'Adds .gitignore';
module.exports = task;

See more examples in the docs.

You can save your tasks locally, publish them on npm or combine multiple tasks in a preset.

Conclusion

If you have many projects with a similar stack or a big multi-repository project, Mrm may be a good way to manage their configuration and could save your time.

Start with default tasks and then write your own or create a preset for your project or organization.

The project is still young — let me know what you think in comments or GitHub issues.

P.S. Check out our new book on JavaScript projects maintenance.

Thanks to Anna Gerus, Karl Horky, Andrey Okonetchnikov, Oleg Slobodskoi, Olga Sylenko, Juho Vepsäläinen.

Automating open source project configuration with Mrm was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

1. injectIntl higher-order component will break shallow rendering because it will render a wrapper component instead of your component.
2. An intl prop will make snapshot testing useless because each snapshot will contain all your messages.

The solution is based on React Intl’s wiki:

1. Add two new helper functions to your Jest setup file (setupFiles):

import { IntlProvider, intlShape } from "react-intl";

// Create IntlProvider to retrieve React Intl context
const intlProvider = new IntlProvider(
  {
    locale: "en",
    messages: {
      message1: "Hello world"
    }
  },
  {}
);
const { intl } = intlProvider.getChildContext();

// `intl` prop is required when using injectIntl HOC
const nodeWithIntlProp = node => React.cloneElement(node, { intl });

// shallow() with React Intl context
global.shallowWithIntl = (node, { context, ...options } = {}) => {
  return shallow(nodeWithIntlProp(node), {
    ...options,
    context: {
      ...context,
      intl
    }
  });
};

// mount() with React Intl context
global.mountWithIntl = (
  node,
  { context, childContextTypes, ...options } = {}
) => {
  return mount(nodeWithIntlProp(node), {
    ...options,
    context: {
      ...context,
      intl
    },
    childContextTypes: {
      intl: intlShape,
      ...childContextTypes
    }
  });
};

2. Export your component with and without injectIntl:

import React, { Component } from "react";
import { injectIntl } from "react-intl";

export class Pony extends Component {
  /* _ */
}

export default injectIntl(Pony);

3. Write test cases almost as usual, using the shallowWithIntl and mountWithIntl helpers:

import React from "react";
import { Pony } from "./Pony";

test("pink pony", () => {
  const wrapper = shallowWithIntl(<Pony color="pink" />);
  expect(wrapper).toMatchSnapshot();
  expect(wrapper.find(".tail").prop("value")).toBe("pink");
});

P. S. You may also enjoy my more generic article on testing React components with Jest and Enzyme and Jest cheat sheet.

I used to think that a personal code style is a good thing for a programmer. It shows you are a mature developer who knows what good code should look like.

My college professors told me that they knew when some of my classmates used my code in their work because of the different code style. Now I think it was because my code was at least somehow formatted and everyone else’s was a mess.

Since then I’ve spent a lot of time arguing code style and configuring tools to enforce it. It’s time for a change.

A few examples

After reading the The Programmers’ Stone I put braces like this for a long time:

if (food === 'pizza')
{
    alert('Pizza ;-)');  
}
else
{  
    alert('Not pizza ;-(');
}

But then I realized that I may be the only one who did it that way in the front-end community. Everybody else uses this style:

if (food === 'pizza') {
    alert('Pizza ;-)');  
} else {
    alert('Not pizza ;-(');
}

Or this:

if (food === 'pizza') {
    alert('Pizza ;-)');  
}
else {  
    alert('Not pizza ;-(');
}

So I’ve changed my style to the last one.

I like this style for chaining very much:

function foo(items) {
  return items
    .filter(item => item.checked)
    .map(item => item.value)
  ;
}

I see the same refactoring benefits as for trailing commas:

const food = [
  'pizza',
  'burger',
  'pasta',
]

But I’m probably even more lonely with this style than I was with braces. Nobody would ever send me code for review with this style, no linter can enforce it. So I have to stop using it too to be closer to the real world.

There’s another thing that nobody else does except me . I always put two spaces before end-of-the-line comment:

const volume = 200;  // ml

I thought it improves readability. But it actually makes the codebase inconsistent because other developers only put one space.

What JavaScript developers do

Unfortunately JavaScript has no official code style. There are a few popular code styles like Airbnb or Standard. You could use them to make your code look familiar to other developers.

You could use ESLint to enforce code style and even autoformat code in some cases. But it won’t make your code base 100% consistent. ESLint with Airbnb config would normalize only my first example and allow inconsistency in the other two examples.

What JavaScript developers should do

Some languages have strict code styles and tools to format code. So developers don’t waste time arguing code style. Look at Refmt for Reason and Rustfmt for Rust.

It looks like JavaScript finally has a solution to this problem. A new tool called Prettier will reformat your code using its own rules. It completely ignores how the code was written in the first place.

Let’s try Prettier on my examples:

if (food === 'pizza') {
  alert('Pizza ;-)');
} else {
  alert('Not pizza ;-(');
}

function foo(items) {
  return items.filter(item => item.checked).map(item => item.value);
}

const volume = 200; // ml

You can disagree with this style. For example I don’t like the else placement and writing function chains in one line is questionable. But I see huge benefits in adopting Prettier:

• Almost no decisions to make — Prettier has few options.
• No arguing about particular rules if you’re working in a team.
• No need to learn your project’s code style for contributors.
• No need to fix style issues reported by ESLint.
• Possible to set up autoformat on file save.

Conclusion

Prettier has been already adopted by some popular projects like React and Babel. And I’m starting to convert all my projects from my custom code style to Prettier. I will recommend it instead of the Airbnb code style.

At first I had a lot of “Ugh, that’s ugly” moments with Prettier. But when I think that I’d have to, for example, manually reformat JSX code from a single-line to multi-line when I add another prop and it doesn’t fit on one line — I realize that it’s totally worth it.

Read how to set up Prettier in your project.

P. S. Have a look at my new tool that will simplify adding ESLint, Prettier, and other tools to your project, as well as keeping their configs in sync.

Subscribe to my newsletter: https://tinyletter.com/sapegin

Why robots should format our code for us was originally published in We’ve moved to freeCodeCamp.org/news on Medium, where people are continuing the conversation by highlighting and responding to this story.