DEV Community: Pearl Zeng-Yoders

Get Started with React Component Testing, Mocking, and Debugging

Pearl Zeng-Yoders — Tue, 29 Nov 2022 01:21:29 +0000

React component testing helps ensure components are performing the expected UI & UX behaviors. This post provides some tips to get started.

Table of Contents:

👉 What to test

👉 The render function, common queries & expects, and triggering events

👉 Mocking data, functions, and libraries (+ special cases for mocking Redux and React Router)

👉 Running the tests & debugging

What to Test

Component testing should cover the component’s UI/UX behavior expectations, including how it handles different props or data input. The key here is testing the behavior, not the implementation. Easiest way to scaffold our tests is taking the product requirements and write them out in plain English that can be easily understood by product or project managers. We can start a testing block with “It should…” or “It should not…” to describe happy paths and fail paths perspectively.

Here’s an example of a scaffolded test file:

// The `describe` blocks are used to explain the testing context,
// and the `it` blocks are used to lay out detailed behaviors
describe('data value is not provided', () => {
    it('should render a text input', () => {
      // test details
    });
};

describe('data value is provided', () => {
    it('should render title if one is provided', () => {
      // test details
    });

    it('should render a picture if one is provided', () => {
    // test details
    })
};

describe('give suggestions for data input', () => {
    it('should render suggestion titles', () => {
        // test details
    });

    it('should not allow users to pick more than one suggested items', () => {
    // test details
    });
}

In general, here are a few things component testing should cover:

The rendering of the intended HTML elements
The rendering of elements based on props
The events being triggered as expected and with intended results
The state of the app, for example loading and error states
For styling, we don’t need to test the exact CSS (that’s a whole other category called visual testing), we should test style changes if it corresponds to prop change or user interaction.

The Render Function and Basic Queries

Let me start with a basic example:

import React from 'react';
import { render } from '@testing-library/react';
import MyComponent from './MyComponent';

const makeProps = () => ({
  content: 'hiking',
});

describe('MyComponent', () => {
  const props = makeProps();

  it('should display content', () => {
    const { container } = render(<MyComponent {...props} />);
    expect(container).toHaveTextContent(props.content);
        expect(container.firstChild.nodeName).toBe('DIV');
  });
});

Here’s what we did:

Use render from @testing-library/react to render the component into the virtual DOM and from there we can get the container, which is the rendered HTML component. We can also get a series of methods like getByTestId, we’ll look at those next.
We use expect to express that we want the container to have the content we passed in as props and that it should be rendered in a div element.
We use a makeProps helper to generate props. This is not required, but it’s helpful as the tests get complicated because we can reuse this helper and pass arguments based on different contexts to get different sets of props.

Common Queries

Now let’s go through some basic queries we can utilize from the render function.

There are three types of queries: get(getAll)By-, query(queryAll)By-, or find(findAll)By-:
- In a lot of cases these three types of queries are interchangeable, however there’re scenarios where one is more suitable. For example accessing an element that may be null, we need to use queryBy because getBy would return error. If we want the error to be returned, we should use getBy. For findBy, it can be used to find the first element when multiple elements exist, it can also be used when needing to await changes in the DOM.
  - Example: Use queryBy to assert an element that should not be in the DOM
```
it('should not display the button', () => {
    const { queryByTestId } = render(<MyComponent {...props} />);
    const theButton = queryByTestId('the-button');

    expect(theButton).toBeNull();
});
```
There are a variety of elements we can query against, including labelText, title, role, testId, etc. Note that using testId should be the last resort because it is the least accessible property by the actual users.
To find multiple elements, should use the -all queries. These queries will return us an array of elements. To access a specific element, we can use their index to access the array, or access them via testId.

To get text content inside an HTML element, use .innerHTML

it('should display value up to 100 characters', () => {
  const { container, getByTestId } = render(<MyComponent {...props} />);
  const display = getByTestId('content').innerHTML;

  expect(container).toHaveTextContent(display);
  expect(display.length).toBe(100);
});

When needing to find elements by partial test, Regex comes in handy. For example, I needed to find by text ‘Worked here for…’ but the exact number of working years is dynamic:
```
const item = getByText(/Worked here for .*/);
```
- We can also use Regex to assess the working years display is of a certain format:
```
expect(item.innerHTML).toMatch(/^Worked here for .*years(?:(.*)months)?/gi);
```

To find an image, we can use -ByAltText, e.g.

it('should render avatar with the given url', async () => {
    const { getByAltText } = await render(<MyComponent />);

    const avatar = getByAltText('avatar');

    expect(image).toHaveAttribute('src', 'the_given_url');
});

Common Expects

Expect to be in the document: expect(element).toBeInTheDocument
Expect to have certain length: expect(items.length).toBe(5)

Expect a link is leading to the right url:

it('should render learn more button with the link to the info site', () => {
    const { getByText } = render(<MyComponent />);
    const link = getByText('Learn more');

    expect(link).toHaveAttribute('href', 'www.info.com');
    expect(link).toHaveAttribute('target', '_blank');
    expect(link).toHaveAttribute('rel', 'noopener noreferrer');
  });

Expect text to be a certain format: expect(text).toMatch(regex)

Expect function to have been called with arguments.

expect(myFunction).toHaveBeenCalledWith({
    argOne: 700,
    argTwo: 'some text',
    callbackArg: expect.any(Function),
});

Expect the rest of props are being called if spreading props via ...restOfProps

it('should pass through other props', () => {
    const { container } = render(<MyComponent data-testid="testID" />);
    expect(container.firstChild).toHaveAttribute('data-testid', 'testID');
});

Expect optional props can be passed in. For example, assert optional style is passed in:

it('should pass through additional style', () => { 
  const { container } = render(<MyComponent style={{ maxWidth: 500 }} />); 
  expect(container.firstChild).toHaveStyle('max-width: 500px'); 
});

Triggering Events

To tigger events, we use fireEvents from the react testing library. Example:

import { render, fireEvent } from '@testing-library/react';

it('should fire authentication function when clicking sign in', () => {
  const { getByTestId } = render(<MyComponent />);
  const signInButton = getByTestId('sign-in-button');

  expect(signInButton).toBeInTheDocument();
  fireEvent.click(signInButton);

  expect(myAuthFunction).toHaveBeenCalled();
});

Mocking

Since React component testing is testing for a certain component, it should be contained within the component’s own context. Therefore the component working as expected should not rely on the inner workings of the outside libraries or external functions utilized by the component. We need to mock those functions out to give expected outcome. Similarly, our tests should not rely on successful data fetching, so we need to mock out the data our tests would receive as well.

Mock Data

‘Faker’ comes in as a handy library when mocking data. You can type data out yourself too, but using ‘faker’ puts the emphasis on the data format rather than the exact data content, which mimics actual user scenarios better. Here are a few handy use cases:

import { faker } from '@faker-js/faker';

// Generate one random word
const word = faker.random.word();

// Generate random text
const content = faker.random.words(50); // optional word count argument

// Generate random image
const image = faker.image.avatar();

// Generate random uuid
const id = faker.datatype.uuid();

// Generate random first and last names
const name = faker.name.firstName(), faker.name.lastName()].join(' ');

// Generate random boolean value
const booleanValue = faker.datatype.boolean();

// Generate random number with precision, for example needing levels 100 | 200 | 300
const level = faker.random.number({ min: 100, max: 300, precision: 100 });

After mocking out the data, we can either feed it directly to our test components as props, or we can feed it as mock API response, to do so, use mockReturnValue or mockReturnValueOnce when needing multiple mock api calls within one test.

Mock Functions

Mock functions let you spy on the behavior of a function our component is using but don’t need to test for its behavior directly.

If the function result doesn’t impact the test, can just do: const myFn = jest.fn()

To mock media functions, use spyOn and then restore it with mockRestore afterwards.

const playSub = jest.spyOn(window.HTMLMediaElement.prototype, 'play').mockImplementation(() => {});

it('should play audio on click', () => {
  const { getByTitle } = render(<MyAudio id={faker.datatype.uuid()} />);
  const playButton = getByTitle('Play');

  fireEvent.click(playButton);
  expect(playSub).toHaveBeenCalled();

  playSub.mockRestore();
});

If need to mock for all tests, do mocks in beforeAll and cleanup in afterAll

beforeAll(() => {
  jest.mock(myFn, arg => ({ key: value }));
});

afterAll(() => {
  jest.restoreAllMocks();
});

Mock Libraries

Similar idea to mocking functions, if we use functions from a library, we want to mock it out so only the function output matters.

Import the library we’re going to mock then use mockImplementation.

import lib from 'lib';

jest.mock('lib');

it('should work', () => {
    lib.mockImplementation(() => 'output');
});

If mocking a module, need to get the path, not the name of the import.

// ❌ don't do this
jest.mock('intersection');

// ✅ do this
jest.mock('lodash/intersection');

If mocking a library function that needs initialization:

// ❌ don't do this
jest.mock('lib', () => ({}));
// ✅ do this
jest.mock('lib', () => () => ({}));

Special case: Mock Redux store

To test with Redux, we need to mock the store and render the test component with the provider and provided store. To solve this, we can a renderWithStore helper that will:

Import our store
Provide our test component with the needed redux provider wrapper
Wraps the render function from the testing library
Then in the testing file, renderWithStore can be used instead of render when needing access to redux

import React from 'react';
import { render } from '@testing-library/react';
import { Provider } from 'react-redux';
import { createStore, combineReducers } from 'redux';
// Add store imports
import myStore from 'store/myStore';

const rootReducer = combineReducers({
  myStore
  // ...and other needed stores
});

const renderWithStore = (
  ui,
  {
    initialState,
    store = createStore(
      rootReducer,
      initialState,
    ),
    ...renderOptions
  } = {},
) => {
  const Wrapper = ({ children }) => {
    return <Provider store={store}>{children}</Provider>;
  };

  return render(ui, { wrapper: Wrapper, ...renderOptions });
};

Special case: Mock React Router

For react router, we need to wrap our test components in the Router and use createMemoryHistory from the ‘history’ library to mock the memory history.

import { Router } from 'react-router-dom'; 
// Note that BrowserRouter ignores history prop, so need to use Router if need to use mockHistory
import { createMemoryHistory } from 'history';
import { render, fireEvent } from '@testing-library/react';

it('should navigate to my_page when the buton is clicked', () => {
  const mockHistory = createMemoryHistory({ initialEntries: ['/home'] });
  const { getByText } = render(
    <Router history={mockHistory}>
      <MyComponent />
    </Router>,
  );

  const button = getByText('Check out my page');

  fireEvent.click(button);
  expect(mockHistory.location.pathname).toMatch(/my_page/);
});

If useLocation from react-router impacts the test, we need to mock it out as well, otherwise we would get error saying max depth call reached.

jest.mock('react-router', () => ({
  ...jest.requireActual('react-router'),
  useLocation: () => ({
    pathname: mockPath,
    key: `${mockPath}-mockKey`,
  }),
}));

Running the Tests & Debugging

To run the tests, do npm test in the command line. This will enter watch mode and automatically run and rerun all new or modified tests.
- You can then press a in the watch mode to run all tests, or f to run only failed tests.
- To run a specific test file, put the file path name into your command line: npm test src/components/MyComponent/MyComponent.test.js
- To run multiple specific test files, do npm test testPath anotherTestPath
  - If you’d like auto completing path name to work in the command line, instead of npm test, you’ll need to do node_modules/.bin/jest
- To run a single test, do .only after it; to skip a test, do x in front of it
```
// Run only this test
it.only('should do something', () => {});

// Skip this test
xit('should not do something', () => {});
```

Use debug to visualize what the render method has created in the virtual DOM

it('should do something', () => {
    const { debug, container } = render(<MyComponent />);
    debug(); // will show the component in html format in the debugger log
});

Use vscode debugger to pause and start to inspect into a test

In the root directory, create .vscode folder, in there, create a launch.json file and put in the following code:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Run React tests",
      "type": "node",
      "request": "launch",
      "runtimeExecutable": "${workspaceRoot}/node_modules/.bin/react-scripts",
      "args": ["test", "--runInBand", "--no-cache", "--env=jsdom"],
      "cwd": "${workspaceRoot}",
      "protocol": "inspector",
      "console": "integratedTerminal",
      "internalConsoleOptions": "neverOpen"
    }
  ]
}

And then can use the play button in the debugger panel to run the test. Running the tests this way will let us step into the breakpoints we add in the code.

Make sure providers are provided when needed — for libraries that consume context, for example styling libraries with a theming object, we should make sure their provider is imported and wrapped around our test components.
If you are using Typescript and getting error that data-testid isn’t a defined prop, you can extend the html element prop the component is consuming so that data-testid is included. Example:
```
interface Props extends React.ComponentProps<'div'>{ // data-testid is an optional prop for the div elments 
  myPropOne: React.ReactNode;
  myPropTwo: string;
}
```

That’s it for now. Hope this post covered some general questions you have when starting with React component testing. You might feel that there are so much to wrap your head around, don’t get intimidated, it will get easier once you get into the groove. Have fun testing!

Fluent UI/react-northstar Theming and Component Styling

Pearl Zeng-Yoders — Sat, 04 Jun 2022 00:57:05 +0000

Fluent UI is a collection of open source user interface components built by Microsoft. It has subsets of libraries for different platforms––React, Windows, iOS––to name a few. To incorporate Fluent UI into a React codebase, it is suggested to use the @fluentui/react package. However, if looking to build a Microsoft Teams app using Fluent UI, the @fluentui/react-northstar package is preferred. At the time of writing, I needed to build an app to upload to Microsoft Teams app marketplace and was exploring v0.62 of @fluentui/react-northstar. Though I was able to find documentation on theming, I wasn’t able to find best practices on consuming the theme and using it in components. Therefore, I created my own solution using React context and I’ll share the gist of my solution in this post.

Set up Theme

In order to use one theme across different components, we need to wrap the components that need theming with Fluent UI’s Provider. Additionally, we can import preset themes to build on top of. The themes available for import include teamsTheme, teamsDarkTheme, and a few other ones, you can refer to their color scheme for colors. I am going to use teamsTheme in my example.

First I created a ThemeProvider to wrap all my components that need to consume the @fluentui/react-northstar library. In my custom theme, I added general theming values under the key siteVariables, and customized component styles under componentVariables and componentStyles, as suggested by the docs.

import React from 'react';
import deepMerge from 'deepmerge'; // a helper to deep merge objects: npmjs.com/package/deepmerge
import {
  Provider,
  teamsTheme,
} from '@fluentui/react-northstar';

interface Props {
  children: React.ReactNode;
}

const customTheme = {
  // Adding a few values that teamsTheme does not include, 
  // for example the spacing variable.
  siteVariables: {
    spacing: {
      unit: 8,
    },
    colorScheme: {
      myCustomBrand: {
        background: '#8662b9',
        label: '#757b94'
      },
    },
  },
  // Customizing the secondary color for all Buttons
  // Use this key to customize the behavior when using the
  // predefined variables, e.g. <Button secondary />
  componentVariables: {
    Button: {
      secondaryColor: 'orange',
    },
  },
  // Customizing the icon size for all MenuButtons
  componentStyles: {
    MenuButton: {
      icon: {
        fontSize: '10px',
      },
    },
  },
};

// Merging my custom theme with the preset teamsTheme
const theme = deepMerge(teamsTheme, customTheme);
export const ThemeContext = React.createContext(theme);

function ThemeProvider({ children }: Props) {
  return (
    <Provider theme={theme}>
      <ThemeContext.Provider value={theme}>{children}</ThemeContext.Provider>
    </Provider>
  );
};

export default ThemeProvider;

There we go, we now have a theme provider that provides theming to all child components and we've made the theme values accessible via React context.

Accessing Theme & Styling Components

Some solutions for accessing theme and styling component are scattered on the Fluent UI official documentation, including using render props and component variables. Here're a couple examples:

import React from 'react';
import { Provider, Flex, Header, Text, Button } from '@fluentui/react-northstar';

// Example for using Provider.Consumer and render props
export function Component() {
  return (
    <Provider.Consumer
      render={theme => {
        return (
          <Flex wrap gap="gap.smaller">
            <Header as="h2" content="Happy Summer"/>
            <Text content="It's watermelon time!"/>
          </Flex>
        );
      }}
    />
  );
}

// Example for using component level styling
export function AnotherComponent() {
    return (
    <div>
        <Text>Get cool!</Text>
        <Button
            content="Unlock the summer"
            variables={{
              color: 'watermelon',
              backgroundColor: 'green',
              paddingLeftRightValue: 30,
            }}
        />
    </div>
    )
}

I find the render prop API not as composable, and mixing it with the hook interface and passing theme into styles are messy. As for using the component level variables, it doesn’t automatically give us access to the theme, unless we wrap that component inside the theme consumer render props, which is again, not as neat.

Therefore, I created theme context in the ThemeProvider above. Then in my component, I can use React.useContext to access the theme.

For styling my components, I’m using the useStyles pattern to apply styles using CSS-in-JS inside each component and allow passing theme as argument. The advantage of this solution is that accessing theme and passing it for styling is easy, and we can extend the useStyles pattern to accept other props and have business logic impact component styling if needed.

// Example component
import React, { useContext } from 'react';
import { Provider, Flex, Header, Text } from '@fluentui/react-northstar';
import { ThemeContext } from './ThemeProvider'; // This is the ThemeProvider I created up top

function Component() {
  const themeContext = useContext(ThemeContext);
  const styles = useStyles(themeContext);

  return (
    <Flex wrap gap="gap.smaller" style={styles.root}>
      <Header as="h2" content="Happy Summer" style={styles.header}/>
      <Text content="It's watermelon time!" style={styles.description}/>
    </Flex>
  );
}

const useStyles = (theme) => ({
  root: {
      padding: theme.siteVariables.spacing.unit * 2
  },
  header: {
      backgroundColor: theme.siteVariables.colorScheme.myCustomBrand.background
  },
  description: {
      marginTop: theme.siteVariables.spacing.unit
  },
});

export default Component;

That’s it! Let me know what you think :)

Eight (Groups of) Lodash Functions I Reach for the Most

Pearl Zeng-Yoders — Tue, 01 Mar 2022 01:38:39 +0000

Wanted to share some Lodash functions that I reach out to a lot either in our React frontend or Node backend. I find them handy and that they improve code readability.

1. `lodash/get`

Use case: Get a property or nested property from an object when the object or its properties are potentially undefined. Can also provide a default value if needed.

// Examples: get company and department properties of a person,
// variable `person` has the following type interface:
interface Person {
    firstName: string;
    lastName: string;
    company?: {
        name: string;
        // ...other company props
        department?: {
            name: string;
            // ...other department props
        }
    }
}

// Example 1: Get the name of the person's company, 
// if undefined, give it ‘Company S’;
// Using syntax 1: use string to express props to look up
const companyName = get(person, 'company.name', 'Company S');

// Example 2: Get the name of the person's department, 
// if undefined, give it ‘Department E’;
// Using syntax 2: use array of strings to express props to look up
cont departmentName = get(person, ['company', 'department', 'name'], 'Department E');

Both syntax allow the use of variables if the look up property name is a variable:

// syntax 1:
const somePropOfCompany = get(person, `company[${propName}]`);

// syntax 2: 
const somePropOfCompany = get(person, ['company', propName]);

2. `lodash/partition`, `lodash/difference`, & `lodash/intersection`

Use case: I reach for these functions when needing to handle parts of an array differently.

`lodash/partition`

// Example: Given an array of items, handle featured items and the rest of the items differently,
// variable `item` has the following type interface:
interface Item {
    name: string;
    isFeatured: boolean;
    category: 'Hobby' | 'Skill' | 'Other';
};

const itemList: Item[] = [
    {
        name: 'my hobby 1',
        isFeatured: false,
        category: 'Hobby',
    },
    {
        name: 'my hobby 2',
        isFeatured: true,
        category: 'Hobby',
    },
    {
        name: 'my skill 1',
        isFeatured: true,
        category: 'Skill',
    },
    {
        name: 'my item 100',
        isFeatured: false,
        category: 'Other',
    }
  // ... more items like the above
];

// Use partition to get a list of featured items and a list of the rest of the items
const [featuredItems, restOfItems] = partition(itemList, { isFeatured: true });

// The second argument can also be a function instead of a property object,
// for example, partition a list of featured hobby items from the rest of the items
const [featuredHobbyItems, restOfItems] = partition(itemList, 
    item => item.isFeatured && item.category === 'Hobby');

`lodash/difference`

// Example: Given a list of incoming members and a list of members from user input,
// get the members to add
const currentMembers = [
  // ...an array of existing members from the API
]; 
const incomingMembers = [
    // ...an array of new members from the form input
]; 
const membersToAdd = difference(incomingMembers, currentMembers);

`lodash/intersection`

// Example: given the same member list from the above, get the members to remove
const membersToRemove = intersection(currentMembers, incomingMembers);

3. `lodash/keyBy` & `lodash/groupBy`

Use case: Build a lookup – keyBy uses one object property as the key, and groupBy groups array items with the same keys into an array under that key.

`lodash/keyBy`

// Example: Given a list of people with the following type interface,
// get a lookup of people by id
interface Person {
    id: string;
    firstName: string;
    lastName: string;
    companyName: string;
};

const people: person[] = [
    // ...list of people
];

const peopleLookup = keyBy(people, 'id');

// Resulting interface:
interface PeopleLookup {
    [id: string]: Person;
};

`lodash/groupBy`

// Example: Given a list of people like the above,
// get a lookup of people by company name
const peopleByCompany = groupBy(people, 'companyName');

// Resulting interface:
interface PeopleByCompany {
    [companyName: string]: Person[];
};

4. `lodash/compact` & `lodash/isEmpty`

Use case: Make sure intended operations don’t happen on falsey items.

`lodash/compact`

// Example: Given a list of people with the following interface,
// get a list of profile photo urls
interface Person {
    firstName: string;
    lastName: string;
    profilePictureUrl?: string;
};

const people: Person[] = [
    // ...list of people
];

const profilePictureUrls = compact(people.map(p => p.profilePictureUrl));
// Using compact here will get rid of any undefined, null, or empty values

`lodash/isEmpty`

// Example 1: Given the people list like the above,
// call the API to upload the photos if profilePictureUrls is not empty
if (!isEmpty(profilePictureUrls)) {
    // call the API
}; // Can also be accomplished by checking array length

// Example 2: Given an object of props to update for a person,
// call the person update endpoint if there are items to update
interface PersonUpdate {
    email?: string;
  phoneNumber?: string;
    company?: {
        name?: string;
        department?: string;
    };
  // ...many more properties
}

if (!isEmpty(PersonUpdate)) {
    // call the person update endpoint
}

5. `lodash/pick`, `lodash/omit`, `lodash/uniq`, & `lodash/isEqual`

Use case: Grab intended properties to send to the API or for display on the UI.

// Examples: Given updatePersonRequest,
const validPersonProps = ['firstName', 'lastName', 'email', 'number'];
// Use pick to grab valid props to send to the updatePerson API endpoint
await updatePerson(pick(updatePersonRequest, validPersonProps));

const propsToSendSeparately = ['profilePhotoUrl', 'coverPhotoUrl'];
// Use omit to omit properties that are handled via a different endpoint
await updatePerson(omit(updatePersonRequest, propsToSendSeparately));

// Use isEqual to decide whether to call the updateEndpoint,
// it performs a deep comparison
if (!isEqual(currentPersonValue, editedPersonValue)) {
    // call the update endpoint
};

// Let's say for every companyName, we need to create a company profile page
const personList = [
    {
        firstName: 'John'
        lastName: 'Doe',
        companyName: 'Company A'
  },
    {
        firstName: 'Sara'
        lastName: 'Smith',
        companyName: 'Company A'
  },
    {
        firstName: 'James'
        lastName: 'Bond',
        companyName: 'Company B'
  },
  // ...more person objects like the above
];
// Use uniq to avoid duplicated company page creation
const namesForCompanyPageCreation = uniq(personList.map(p => p.companyName));

6. `lodash/sortBy` & `lodash/orderBy`

Use case: Sort and order array items.

sortBy sorts items in ascending order, and orderBy allows specifying the sort order.

// Examples:
// Use sortBy to sort timezones in UTC offset, 
// and if offset is the same, sort by displayName
const timezonesOrderedByUtcOffset = sortBy(timezones, [
    tzItem => tz.utcOffect,
    'displayName'
]); // This array accepts both a callback and a property name

// Get the latest blog post by first using orderBy to order posts in descending order
const [latestBlogPost] = orderBy(blogposts, 'createdAt', 'desc');
// The second and third arguments can both be arrays as well, e.g.
// Order the blog posts by descending order for creation date, 
// and ascending order for edited date
const orderedPosts = orderBy(blogposts, ['createdAt', 'editedAt'], ['desc', 'asc']);

7. `lodash/chunk`

Use case: Chunk items when inserting into the sql database to avoid inserting a big amount of data at once.

// Example: Insert over 10,000 people into the person table.
// Chunk the data into 500 chunks first and then insert with a custom insertMany function
const chunkedPeopleData = chunk(peopleData, 500);
await Promise.all(chunkedPeopleData.map(data => 
    insertMany('person', data)
));

8. `lodash/sumBy`

Decided to use sumBy to wrap up the post ;)

Use case: Get the sum.

// Example: Get total post reads
interface Post {
    name: string;
    viewCount: number;
}

const posts: Post[] = [
    // ...a list of posts
];

const totalPostReads = sumBy(posts, 'viewCount');

That’s It

Those are the Lodash functions I normally reach for, along with their examples. There are debates on whether to use Lodash, given the weight it adds to the application. Additionally, newer versions of Javascript can accomplish a lot more functions that Lodash was trying to simplify. One thing came to mind was flat() that was introduced with ES2019. It handles deep flatten nicely:

const arr = [0, 1, 2, [[[3, 4]]], [[[[5, 6]], [7, 8]]]];
// To turn the above array into [1, 2, 3, 4, 5, 6, 7, 8]:
// Flat deep with ES2019
const flatArr = arr.flat(Infinity);
// Flat deep with lodash
const loFlatArr = flattenDeep(arr);

And many of the above use cases can be achieved by Javascript native function reduce, but I find the Lodash functions provide more communicative APIs. And to reduce (😉) the impact of library weight, I would only import the needed modules:

// Instead of this:
import { isEmpty } from 'lodash';

// Do this:
import isEmpty from 'lodash/isEmpty';

Let me know your thoughts in the comments. Happy Lodashing!

Code Review for React Projects

Pearl Zeng-Yoders — Wed, 26 Jan 2022 14:45:43 +0000

Happy New Year!

On my first day back to work at the end of 2021 after being on maternity leave for three months, I was handed a few PRs to review. I started jotting down my list of things to look out for during code reviews as it was a perfect way for me to get back up to speed. Decided to share these in case they would be helpful to others.

In this post, I’ll be sharing my code review lookout points for our React/TypeScript web frontend projects, for which, we also use material-ui as the styling library. Please comment to let me know your thoughts on doing code reviews for React projects!

General

Whether the code is expressive and communicates its intent. For example:
- If there’s mysterious naming, I would suggest renaming them into something more descriptive; it can be generic or context-specific based on the usage of the variable or the function.
- If there are implicit constants or magic numbers, I would suggest lifting them as constants to the top of the file, or extracting them into a separate file if being shared.
- Is there’s misuse for const and let—use const in most cases unless the variable gets updated later. Note that for array that’s being pushed to later, we should still use const instead of let.
- Whether the code can be refactored to be more clean, readable, or efficient. For example:
  - Whether function shorthands, object destructing, or lodash helper can be applied.
  - Whether long if statements may be split, or refactored using case & switch statements.
  - Whether code conditionals make sense and if falsey checks cover the intended use cases.
How the new code would impact the overall codebase. For example:
- Does the folder structure and file naming follow our convention?
- Is there unnecessary repetition and duplications? Could we delete some code via reusing existing functionalities or extracting some helpers?
- Is complicated code logic accompanied by comments? (If hard to grasp even after proper abstraction is applied.)
- Whether abstractions make sense.
- Whether typings are defined and aligned with feature requirements and if there are proper component tests & cypress integration tests in place.

React Specific

If component composition makes sense, specifically:
- Is business logic and styling mixed?
  
  I find it helpful to extract stylistic components so business logic is apparent.
  - On the root level, I like to create reusable Atom- and Molecule- components based on our design system. (See here for atomic design philosophy.) Some atoms and molecules can be created from scratch, others can be wrapper components of material-ui components, for which I have an example in the section below.
  - On a feature level, we can have smaller components that accept styling props, and have an overall component handle business logic and pass down styling if styling is impacted by business logic. It’s not one rule applies to all, when components are smaller and simpler, I think business logic, data fetching, and styling can co-locate. But for more complicated components, I find locating business logic in one overall file improves readability.
- Is data fetching and component mixed?
  
  Our codebase follows a containerized structure–data fetch happens in an index.tsx file, and then that fetched data gets passed in as a prop into the component file. We don’t follow this pattern strictly, if the data fetch is simple, then the container file can be index.ts with default export. Though the container pattern comes in handy when handling loading state. For example:
```
// index.tsx
function Container({
 // some props
}) {
    const data = [someDataFetcher];

    useEffect(
        // use the data fetcher to fetch data based on fetch conditions
    )

    if (!data || isLoading(status)) { 
    // isLoading & status comes from our data fetcher
       return <div>Loading</div>; // or other loading UI such as a spinner
    }

    return (
      <Component data={data}/>
    }
}
```
  - Along the lines of loading state, code splitting with suspense + lazy loading is nice to group things that need loading state and error boundaries together.
- Whether props make sense
  - Naming: props should be named according to the use case that’s understandable by this component as opposed to assumed context. In a piece of code I reviewed recently, a table row is clickable if the data is not managed by synced client data, then instead of naming the prop syncManaged, it would make more sense to name it clickable or editable as the table row component itself only needs to know how to behave, the overall component can handle the why and that the row component is more adaptable if the conditions for clickable change in the future.
Whether the component is composed in a way that considers changeability and maintainability.
- For components with strict contracts, I would define every single prop. Otherwise I would opt in for a {children} prop to make the component more extensible.
- Prop drilling v.s. global state v.s state co-location
  - Whether the state is located closest to where it’s relevant–in the component itself, or in the closest parent that makes sense to have the shared state.
  - Whether React context can be used to avoid prop drilling, though should still put the context close to where it’s most relevant.
  - Global context would makes sense for things that apply to the whole app to avoid having to pass props down every single level, for example themed styles.
- Whether a set of hooks can be abstracted into a custom hook that describes the purpose of the code better and can be used and changed easier.
Whether useEffects are done right, as it’s one of the most reached hook:
- Is it kept simple—if one big effect hook can be broken down into multiple ones so when to re-render is more manageable.
- Are the dependencies all necessary. The linter can make sure all dependencies needed are included, but it won’t tell us what’s extra. Additionally:
  - Functions and variables only needed for the useEffect should live inside instead of outside the effect block to reduce the need of being included in the dep array.
  - Should include the specific property on an object instead of the whole object in the dep array–e.g. use item.name instead of item will prevent object equality comparison return false or the change of other properties of item unrelated to this effect causing unnecessary re-renders.
  - Things like useCallback and setState don’t need to be in the dep array.
  - ref shouldn't be in the dep array. Here’s how I would use the useRef hook
```
const someRef = useRef(null);

useEffect(() => {
  const someRefElement = someRef.current;

  if (someRefElement !== null) {
    // some logic here
  }

  // some other logic for when ref is null when first rendered

  return () => {
    // some clean up function
  };
}, [
// neither ref nor ref.current should to be in here
]);
```
    - Another way is to not use effect and just use a callback ref. This post does a great job explaining it.
Whether things are “cached” properly
- Whether fetched data has been “cached” properly and only re-fetch when needed in useEffect.
- Whether useMemo has been applied to cache expensive calculations.
- Whether memo has been used to cache components that don’t need to be re-rendered when the parent component changes and if useCallback has been used in the parent component for the functions being passed to the memoized child components.
Other bits to look out for:
- Whether keys in a mapped component array are unique and stable–should avoid using object or pure indices as keys.
- Use React.Fragment instead of html element tag if a tag is not needed. Note that though the Fragment can be shorthanded into <></>, when needing to apply key, should do <React.Fragment key='some key'>.

Material UI & Styling Specific

We are on v4 of material UI and use the createTheme API for overall theming and the useStyles/makeStyles API for component styling. We allow clients to customize the application with their brand colors. Therefore, When reviewing the styling side of things, I mainly pay attention to theming and design system implications. Specifically:

Whether or not a component styling has taken theming into consideration, for example:
- If themed colors are used instead of arbitrary colors.
- If margins and paddings are specified with theme.spacing() instead of random numbers.
- If SVG icons have been converted using the mui SvgIcon API and stripped off the fill property—I normally use the SVGR playground to convert the SVG file first, then replace the outside tag of the converted result with SvgIcon tag and take out any fill properties since those will be passed in via the component and be populated via theming.
- If any !important overrides supposed to be applied to the whole theme or if there’s a color, typography, spacing, or shadow that’s not within our design system–should make sure to have checked with our product designer so that the design system updates in Figma and the update to the theming files in our codebase are aligned. In our overall theme file, we have imports of our custom palette and typography files, in addition to spacing, shadow, and component specific overrides. So where to make the update would be based on the impact of this override.
  - If it’s a global theming property on mui default theme, we can use global theming override instead of adding new properties, otherwise add the property to the global theme.
  - If it’s global to a specific mui component, we use component style override, e.g. here’s the style props to look for when overriding a DialogContent component.
  - If it’s a set of components from a feature that has specific theming requirements, we can extract a shared styles file.
Whether the place for applying styles makes sense–I would go with this order: included material ui props → classes in the useStyles block → and then if the style is impacted by component props, I would first consider passing it down to the useStyles block as custom style props, while sometimes it makes more sense to apply the variables directly inline, for example, when using the width css prop directly.

When the stylistic part of the component is being shared amongst multiple components, it can be extracted into an atom or molecule. When using material ui for atom and molecule components, I like to create wrapper components–see below for example–I think these wrapper components provides flexibility as the component API is defined by us and not confined by the mui props, so we can switch out the mui component used without impacting the components using this atom or molecule.

// atoms/PaperCard.tsx
import React, { forwardRef } from 'react';
import makeStyles from '@material-ui/styles/makeStyles';
import classNames from 'classnames';

interface Props extends React.ComponentProps<'div'> {
  children: React.ReactNode;
}

const PaperCard = forwardRef((props: Props, ref: React.Ref<any>) => {
  const classes = useStyles();
  const { className, children, ...restOfProps } = props;

  return (
    <div ref={ref} className={classNames(classes.root, className)} {...restOfProps}>
      {children}
    </div>
  );
});

const useStyles = makeStyles(theme => ({
  root: {
    // our custom styles
  },
}));

export default PaperCard;

Whether responsive design and accessibility (we also use Lighthouse to audit) are considered.
Finally, see if there are anything that needs documenting and communicating further.

That’s it for Now

These are what I have had a chance to jot down in the bits of time after work and between caring for my adorable baby 😆

By no means is this list meant to be comprehensive, hopefully it serves more as a general guide for things of note. And of course, the most important thing is that the feature should work per product requirements–which requires pulling the feature, testing it, and checking product specs and collaborating with the product team as a whole.

Please comment to let me know if I missed anything. I look forward to continuing to get back up to speed and sharing my follow up thoughts in future posts.

Change target API level to 30 for React Native 0.62.2

Pearl Zeng-Yoders — Tue, 28 Dec 2021 23:09:58 +0000

TL;DR

Two simple steps solved this issue for me.

Step 1:
In 'android/build.gradle' file, update the ext block in the buildscript block to the following:

    ext {
        buildToolsVersion = "30.0.2"
        minSdkVersion = 21
        compileSdkVersion = 30
        targetSdkVersion = 30
        ndkVersion = "20.1.5948944"
    }

Step 2:
Update the "react-native-community/netinfo" package to the latest version (v5.9.10 at the time of writing) by running npm update @react-native-community/netinfo.

Optional Next Step:
Build the app and run it to make sure all packages used are running as expected in case some libraries lack support for SDK 29+.

[Update]
Later we noticed app crashing on Android 11, after digging, it's a special crashing case with Android 11 and targetSdkVersion 30. And these two steps fixed it for us:
(1) Update okhttp version to the latest

// android/app/build.gradle

dependencies {
    // ...other dependencies
    implementation("com.squareup.okhttp3:okhttp:4.9.2")
    implementation("com.squareup.okhttp3:okhttp-urlconnection:4.9.2")
}

(2) Update Sentry to v2+ in package.json and npm i (see explanation here.)

// package.json

"dependencies": {
    // ...other dependencies
    "@sentry/react-native": "^2.0.0"
}

Details

Google play store is giving this message when I uploaded our .apk file:

Your app currently targets API level 29 and must target at least API level 30 to ensure it is built on the latest APIs optimized for security and performance. Change your app's target API level to at least 30.

Here's a detailed explanation of the requirement and I found this Github thread particularly helpful on understanding the issue.

The main takeaway was that, newer React Native versions have SDK target updated to 30. If we don't want to update React Native, directly updating SDK target in the build file is a solution, however, we need to be cautious on library compatibility.

By checking the React Native Upgrade Helper, I found that the earliest version with SDK targeting 30 is v0.65.0 and spent some time trying to update the React Native version in our project. I ran into quite a few issues and after solving a few, I got caught up on one that has implicit error messages. In order to hit this project deadline, I had to give up updating React Native this time around. I can share issues and solutions in a future post when I get to updating it.

Therefore, for the workaround for this project, I pulled out the ext block in the buildscript block from 0.65.0's 'android/build.gradle' file and used it in our 'build.gradle' file.

After that, the build failed with this error resource android:attr/lStar not found. I referred to this post and updated the "react-native-community/netinfo" package, then our project was able to build as expected.

Potential trouble shoot
I was messing around with the gradle files while trying to upgrade React Native and had some gradle inconsistency issues. If you have faced similar issues, here're a couple ways for cleaning the restarting the build in Android Studio:

File -> Invalidate Caches/Restart
Build -> Clean Project; Build -> Rebuild Project

Unable to use Fastlane on macOS Monterey 12.1

Pearl Zeng-Yoders — Mon, 27 Dec 2021 22:51:15 +0000

TL;DR

These are the steps that solved it for me:

Install rvm using curl -sSL https://raw.githubusercontent.com/rvm/rvm/master/binscripts/rvm-installer | bash -s stable
Reload terminal
Upgrade xcode to latest version
Run rvm install ruby-2.7
Run rvm use ruby-2.7.5
Run bundle update
Fastlane should work as expected

Steps explained

Below I noted detailed error messages and solutions:

We use Fastlane to help Android build on our React Native project. After upgrading my macOS to Monterey 12.1, my bundle exec fastlane commands no longer work, and I was prompted to update my bundler. But when I ran bundle update, I got this error:

An error occurred while installing unf_ext (0.0.7.7), and Bundler cannot continue.
Make sure that `gem install unf_ext -v '0.0.7.7' --source 'https://rubygems.org/'` succeeds before bundling.

However, running the suggested command didn't work. After digging around, I found that I needed to upgrade my ruby version to v2.7, for which I ended up using rvm. Note that after installing rvm, the rvm commands won't be available until the terminal has been restarted.

Then, when I first used rvm install ruby-2.7, it wasn't successful due to this error Error running '__rvm_make -j16'. After checking the 'make.log' file, I found this error, use of undeclared identifier RUBY_FUNCTION_NAME_STRING. Updating my xcode to the latest version ended up getting rid of the error.

Finally, I was able to use ruby v2.7.5 with rvm use ruby-2.7.5. (You can check that your ruby version is successfully updated using ruby -v). And bundle update ran successfully and my Fastlane commands started working as expected.

Hopefully this post can be of help to people who're searching for solutions to make Fastlane work with macOS Monterey!

DEV Community: Pearl Zeng-Yoders

Get Started with React Component Testing, Mocking, and Debugging

What to Test

The Render Function and Basic Queries

Common Queries

Common Expects

Triggering Events

Mocking

Mock Data

Mock Functions

Mock Libraries

Special case: Mock Redux store

Special case: Mock React Router

Running the Tests & Debugging

Fluent UI/react-northstar Theming and Component Styling

Set up Theme

Accessing Theme & Styling Components

Eight (Groups of) Lodash Functions I Reach for the Most

1. lodash/get

2. lodash/partition, lodash/difference, & lodash/intersection

lodash/partition

lodash/difference

lodash/intersection

3. lodash/keyBy & lodash/groupBy

lodash/keyBy

lodash/groupBy

4. lodash/compact & lodash/isEmpty

lodash/compact

lodash/isEmpty

5. lodash/pick, lodash/omit, lodash/uniq, & lodash/isEqual

6. lodash/sortBy & lodash/orderBy

7. lodash/chunk

8. lodash/sumBy

That’s It

Code Review for React Projects

General

React Specific

Material UI & Styling Specific

That’s it for Now

Change target API level to 30 for React Native 0.62.2

TL;DR

Details

Unable to use Fastlane on macOS Monterey 12.1

TL;DR

Steps explained

1. `lodash/get`

2. `lodash/partition`, `lodash/difference`, & `lodash/intersection`

`lodash/partition`

`lodash/difference`

`lodash/intersection`

3. `lodash/keyBy` & `lodash/groupBy`

`lodash/keyBy`

`lodash/groupBy`

4. `lodash/compact` & `lodash/isEmpty`

`lodash/compact`

`lodash/isEmpty`

5. `lodash/pick`, `lodash/omit`, `lodash/uniq`, & `lodash/isEqual`

6. `lodash/sortBy` & `lodash/orderBy`

7. `lodash/chunk`

8. `lodash/sumBy`