DEV Community: Matt Crowder

Optimizing callbacks inside reusable React hooks

Matt Crowder — Thu, 06 Jan 2022 01:40:25 +0000

Problem

You've created a custom react hook, useEventListener:

const useEventListener = (type, callback) => {
  React.useEffect(() => {
    window.addEventListener(type, callback)
    return () => {
      window.removeEventListener(type, callback)
    }
  }, [])
}

Then you realize that you have missed the type and callback dependency, so you add them.

const useEventListener = (type, callback) => {
  React.useEffect(() => {
    window.addEventListener(type, callback)
    return () => {
      window.removeEventListener(type, callback)
    }
  }, [type, callback])
}

Then you wonder to yourself, how often will this useEffect get run?

So you add a couple of console.logs detailing subscribe and unsubscribes.

const useEventListener = (type, callback) => {
  React.useEffect(() => {
    console.log("subscribe")
    window.addEventListener(type, callback)
    return () => {
      console.log("unsubscribe")
      window.removeEventListener(type, callback)
    }
  }, [type, callback])
}

You also implement this hook in another file.

function Simple() {
  useEventListener("resize", () => {
    console.log("hello")
  })
  return <div>hello</div>
}

This useEventListener will call your callback which log "hello" every time the browser resizes.

Also, subscribe will only get called one time.

See it in action here

Sounds great, right? Well not so fast...

If you start adding things other than a console.log inside of your callback, then callback's memory address will start changing, and React will start running your useEffect in useEventListener a lot more than you expected it to.

Let's add a resize count to the resize event listener

function ExternalExample() {
  const [count, setCount] = React.useState(0)
  useEventListener("resize", () => {
    setCount((prev) => prev + 1)
  })
  return (
    <div>
      <p>Count: {count}</p>
    </div>
  )
}

See it in action here

Solution

So what do we do to solve this?

Wrap callback in a useCallback inside of our component
Remove callback from the useEffect
Wrap our callback in a ref

Option 1 is feasible for this use case, but as our code base grows, it's pretty annoying making all of your peers wrap their callbacks in useCallbacks, keep in mind, this callback approach needs to apply to all reusable hooks in our application.

Option 2 is not acceptable because the useEffect could be referencing old versions of callback when it's actually getting invoked. For this use case it's fine, but for other reusable hooks, it could have a stale callback.

Option 3 is our best bet!

Let's update useEventListener to store callback inside of a ref.

const useEventListener = (type, callback) => {
  const callbackRef = React.useRef(null)

  React.useEffect(() => {
    console.log("assigning callback to refCallback")
    callbackRef.current = callback
  }, [callback])
  React.useEffect(() => {
    console.log("subscribe")
    window.addEventListener(type, refCallback.current)
    return () => {
      console.log("unsubscribe")
      window.removeEventListener(type, refCallback.current)
    }
  }, [type])
}

callback is still getting updated on every count update, but only the useEffect that's assigning callback is running. This is avoiding the event listener from subscribing and unsubscribing! We also don't have to add refCallback.current in the dependency array since updating refs do not trigger rerenders, which will not trigger a useEffect execution.

See it in action here

If you are happy with this approach as a reusable way to avoid adding callbacks inside of your useEffect dependency array, then feel free to stop here.

Going the extra mile

In our code base, we have lots callbacks that get passed into reusable hooks.

Our useApi hook which interacts with external apis, accepts several callbacks: onSuccess, onError, api, and validate.

It gets pretty annoying writing this code:

const onSuccessRef = React.useRef(null)
const onErrorRef = React.useRef(null)
const apiRef = React.useRef(null)
const validateRef = React.useRef(null)

React.useEffect(() => {
  onSuccessRef.current = onSuccess
}, [onSuccess])

React.useEffect(() => {
  onErrorRef.current = onError
}, [onError])

React.useEffect(() => {
  apiRef.current = api
}, [api])

React.useEffect(() => {
  validateRef.current = validate
}, [validate])

So with that... I'd like to introduce: useCallbackRef

Which turns this verbose code above into:

const onSuccessRef = useCallbackRef(onSuccess)
const onErrorRef = useCallbackRef(onError)
const apiRef = useCallbackRef(api)
const validateRef = useCallbackRef(validate)

useCallbackRef is written as follows:

const useCallbackRef = (callback) => {
  const callbackRef = React.useRef(null)

  React.useEffect(() => {
    callbackRef.current = callback
  }, [callback])
  return callbackRef
}

But the problem with this approach is eslint will complain about callbackRef, it doesn't know that it's a ref!

To solve this, we need to patch eslint-plugin-react-hooks to let eslint know that our useCallbackRef returns stable values.

We need to install patch-package and postinstall-postinstall

yarn add -D patch-package postinstall-postinstall

Once we have that installed, open up node_modules/eslint-plugin-react-hooks/cjs/eslint-plugin-react-hooks.development.js

Go to line 907 where it has:

if (name === 'useRef' && id.type === 'Identifier') {

And update that to be

if ((name === 'useRef' || 'useCallbackRef') && id.type === 'Identifier') {

Once that is updated, run patch-package:

node_modules/.bin/patch-package eslint-plugin-react-hooks

After that runs, you should have a patch file created in a patches folder, which contains the patch that will run on postinstall.

Add the following script in package.json:

"postinstall": "patch-package"

And now the warning in the dependency array is gone.

Long term it would be great if eslint-plugin-react-hooks was updated to support this functionality, but for now it doesn't, so that's why we're patching it. There is an open PR to add this functionality: https://github.com/facebook/react/pull/20513

You still have this warning from eslint:

ESLint: The ref value 'callbackRef.current' will likely have changed by the time this effect cleanup function runs. If this ref points to a node rendered by React, copy 'callbackRef.current' to a variable inside the effect, and use that variable in the cleanup function.(react-hooks/exhaustive-deps)

But that can be solved by assigning callbackRef.current to another variable such as callback. You only have to do this when you're setting up subscriptions and unsubscribing from them in useEffects.

See it in action here

This is part one of this blog post, in the next part, I'll write about a custom eslint rule that marks the callback passed into useCallbackRef as "dirty", and it complains if you try invoke it.

Creating a node script that can write to google docs

Matt Crowder — Mon, 07 Oct 2019 22:21:02 +0000

My wife and I use a shared google doc for our grocery list, and I often find myself forgetting to add groceries to our list which then results in us forgetting to buy things at the grocery store.

So I setup an automation when I tell google to add "something", IFTTT knows that when I say that, it sends a web request to my heroku server which then uses the google javascript api to update my google doc. I am happy with this setup and want to share with you all how I did it!

So this is Part 1 of a multi-part blog series on how to accomplish what I mentioned above! Stay tuned for the next parts!

Go to https://docs.new in your browser, and that will create a new google doc.
Title it Groceries (or whatever you want).

Note the id of the doc. It's between d/ and /edit in the url.

Mine is 1OvhQtG2WYagqI-zBk_IXTRWhLijCu2_hB-ExdyCYI54

Creating oauth tokens with google nodejs apis

Run the following commands.

We'll be using yarn from here on out.

mkdir grocery-adder && cd grocery-adder
yarn init -y
git init
touch .gitignore
yarn add googleapis
mkdir src && touch src/index.js

Add the following to your .gitignore file:

.idea
node_modules

Keep in mind that I will have credentials.json and token.json ignored in my final example so I don't compromise my google account to you all :)

For the rest of the oauth setup, I'm really just summarizing the following tutorial: https://developers.google.com/gmail/api/quickstart/nodejs

Go to https://console.developers.google.com/apis/library/docs.googleapis.com
Click Enable
Go to https://developers.google.com/gmail/api/quickstart/nodejs
Click Enable the Gmail API
Save credentials.json to grocery-adder
Paste the following code into src/index.js

const fs = require("fs");
const readline = require("readline");
const { google } = require("googleapis");

// If modifying these scopes, delete token.json.
const SCOPES = ["https://www.googleapis.com/auth/documents"];
// The file token.json stores the user's access and refresh tokens, and is
// created automatically when the authorization flow completes for the first
// time.
const TOKEN_PATH = "token.json";

// Load client secrets from a local file.
fs.readFile("credentials.json", (err, content) => {
  if (err) return console.log("Error loading client secret file:", err);
  // Authorize a client with credentials, then call the Gmail API.
  authorize(JSON.parse(content), () => console.log("authorized!"));
});

/**
 * Create an OAuth2 client with the given credentials, and then execute the
 * given callback function.
 * @param {Object} credentials The authorization client credentials.
 * @param {function} callback The callback to call with the authorized client.
 */
function authorize(credentials, callback) {
  const { client_secret, client_id, redirect_uris } = credentials.installed;
  const oAuth2Client = new google.auth.OAuth2(
    client_id,
    client_secret,
    redirect_uris[0]
  );

  // Check if we have previously stored a token.
  fs.readFile(TOKEN_PATH, (err, token) => {
    if (err) return getNewToken(oAuth2Client, callback);
    oAuth2Client.setCredentials(JSON.parse(token));
    callback(oAuth2Client);
  });
}

/**
 * Get and store new token after prompting for user authorization, and then
 * execute the given callback with the authorized OAuth2 client.
 * @param {google.auth.OAuth2} oAuth2Client The OAuth2 client to get token for.
 * @param {getEventsCallback} callback The callback for the authorized client.
 */
function getNewToken(oAuth2Client, callback) {
  const authUrl = oAuth2Client.generateAuthUrl({
    access_type: "offline",
    scope: SCOPES
  });
  console.log("Authorize this app by visiting this url:", authUrl);
  const rl = readline.createInterface({
    input: process.stdin,
    output: process.stdout
  });
  rl.question("Enter the code from that page here: ", code => {
    rl.close();
    oAuth2Client.getToken(code, (err, token) => {
      if (err) return console.error("Error retrieving access token", err);
      oAuth2Client.setCredentials(token);
      // Store the token to disk for later program executions
      fs.writeFile(TOKEN_PATH, JSON.stringify(token), error => {
        if (error) return console.error(error);
        console.log("Token stored to", TOKEN_PATH);
      });
      callback(oAuth2Client);
    });
  });
}

Run node src/index.js
Follow the prompts on the terminal
You'll get a warning saying This app isn't verified, that's ok! You are the app!!
Great now you have token.json stored at the root of grocery-adder
Run node src/index.js and you'll see that authorized! is printed on the terminal
Now we can delete a lot of that setup code and write to your google doc!

Your file should look like the following:

const { google } = require("googleapis");
const token = require("../token.json");
const credentials = require("../credentials.json");

function authorize() {
  const { client_secret, client_id, redirect_uris } = credentials.installed;
  const oAuth2Client = new google.auth.OAuth2(
    client_id,
    client_secret,
    redirect_uris[0]
  );
  oAuth2Client.setCredentials(token);
  return oAuth2Client;
}

async function main(YOUR_DOCUMENT_ID) {
    const auth = await authorize();
    const docs = google.docs({
      version: "v1",
      auth
    });
    await docs.documents.batchUpdate({
      auth,
      documentId: YOUR_DOCUMENT_ID,
      requestBody: {
        requests: [
          {
            insertText: {
              location: {
                index: 1
              },
              text: "hello!\n"
            }
          }
        ]
      }
    });
}

main("YOUR_DOCUMENT_ID");

If you see text: "hello!\n", you'll see what will be getting written to our doc!

Replace "YOUR_DOCUMENT_ID" with your document id and run it!

Now, if you go to your new google doc, you'll see hello! printed there! If you keep running this, hello! will continue getting added.

The code to generate the token can be found here

The code to write to the google doc can be found here

I've been using cat and vim for the wrong reasons for so long...

Matt Crowder — Sun, 28 Apr 2019 19:17:32 +0000

My situation: I have a file that I need to copy the entire contents of it.

In the terminal, I type: cat file.txt, then copy the terminal output.

The easy solution:

pbcopy < file.txt

And now the contents are saved in my clipboard.

Then, if I had to paste those contents somewhere else, I would use vim to create a file and paste those contents in there, and if I was lucky, I wouldn't have to restart my computer from getting stuck in vim.

Instead, the easy solution:

pbpaste > file-two.txt

And now, all of the contents from my clipboard are saved in file-two.txt!

What other bash commands have you found useful? Let me know in the comments!

How to disable in browser linter errors in an ejected create-react-app application

Matt Crowder — Sun, 14 Apr 2019 01:31:09 +0000

So, you've ejected your app that was created with create-react-app, and you're using your own linter, and now all of a sudden, when a linter error occurs, you get an error screen. This may be a good thing, but what if have no-console as error, and you want to log things while doing development, but not in production.

Open up config/webpack.config.js, and delete these lines 293-310:

// First, run the linter.
// It's important to do this before Babel processes the JS.
{
  test: /\.(js|mjs|jsx)$/,
  enforce: "pre",
  use: [
    {
      options: {
        formatter: require.resolve("react-dev-utils/eslintFormatter"),
        eslintPath: require.resolve("eslint"),
        failOnError: false,
        failOnWarning: false,
      },
      loader: require.resolve("eslint-loader")
    }
  ],
  include: paths.appSrc
},

We just removed the linter check that gets done when you run your application in development mode, and when your application gets built for production.
It doesn't make sense to run the linter for either of these scenarios.

It does, however, make sense to run the linter while running npm test or yarn test.

In package.json, change "test": "node scripts/test.js" to "test": "yarn linter && yarn jest".

And add the following scripts:

"linter": "eslint src --ext .js,.jsx",
"jest": "jest"

Now, when you run npm test or yarn test, it will run your linter and your jest unit tests!

Configuring your mac to display the wifi name on the menu bar

Matt Crowder — Sat, 13 Apr 2019 19:33:53 +0000

If you find yourself wondering how to have the name of the network you're connected to on your menu bar, then follow these instructions.

We'll be using an application called hammerspoon, which allows your computer to run lua scripts in the background!

Go to hammerspoon's github releases and install the latest one. You'll find something like this:

Click the first choice, Hammerspoon-0.9.73.zip
Once downloaded, unarchive the zip to your Downloads
Drag the Hammerspoon application to your Applications
Once in applications, open Hammerspoon with spotlight (press command and space, and type in Hammerspoon, then press enter)
Once Hammerspoon has been opened for the first time, you should see a security prompt:
Click Open
Check Launch Hammerspoon at login
Great, now we can add our init script!
Open your terminal and enter, touch ~/.hammerspoon/init.lua,
Now open init.lua, (located at ~/.hammerspoon/init.lua)
Paste in the following code:

wifiMenu = hs.menubar.newWithPriority(2147483645)
wifiMenu:setTitle(hs.wifi.currentNetwork())

wifiWatcher = nil

function ssidChanged()
    local wifiName = hs.wifi.currentNetwork()
    if wifiName then
        wifiMenu:setTitle(wifiName)
    else
        wifiMenu:setTitle("Wifi OFF")
    end
end

wifiWatcher = hs.wifi.watcher.new(ssidChanged):start()

Quit hammerspoon using cmd+q, (not just pressing the red x)
Reopen hammerspoon

And voila! We now have the name of our network on our menu bar!

Writing a custom react hook that persists to local storage

Matt Crowder — Fri, 05 Apr 2019 21:34:04 +0000

So, you're writing some react hooks, and you say to yourself, "I'd love for this local state to persist on refreshes".

Let's write a custom hook that persists to localStorage!

Setup

$ create-react-app local-storage-hook
$ cd local-storage-hook
$ yarn eject # accept all of the prompts
$ yarn add -D jest-localstorage-mock react-testing-library jest-dom
$ touch src/use-local-storage-set-state.js && touch src/use-local-storage-set-state.test.js && touch src/setupTests.js

Then, open up package.json, and edit the jest config,

add "jest-localstorage-mock" to the setupFiles section.

So now it looks like this:

"setupFiles": [
   "react-app-polyfill/jsdom",
   "jest-localstorage-mock"
]

Then, add the following property to the jest config,

"setupTestFrameworkScriptFile": "<rootDir>/src/setupTests.js"

Make src/setupTests.js the following:

import "react-testing-library/cleanup-after-each";
import "jest-dom/extend-expect";

(Before proceeding, if you are getting a weird error while running yarn test, then please do rm -rf node_modules && yarn and then this will solve those issues).

Alright! Let's write some tests!

// use-local-storage-set-state.test.js
import React from "react";
import { useLocalStorageSetState } from "./use-local-storage-set-state";

test("throws when name is not provided", () => {
  expect(() => useLocalStorageSetState(0)).toThrow();
});

When running yarn test, this fails, so let's implement the source code:

// use-local-storage-set-state.js
export const useLocalStorageSetState = (initialValue, name) => {
  if (!name) {
    throw new Error("Name must be provided to persist to localStorage");
  }
};

Now, when running yarn test, this test passes!

Unfortunately, this doesn't do much. Let's add extra tests to show what we're going for!

// use-local-storage-set-state.test.js
import React from "react";
import { render, fireEvent } from "react-testing-library";
import { useLocalStorageSetState } from "./use-local-storage-set-state";

test("throws when name is not provided", () => {
  expect(() => useLocalStorageSetState(0)).toThrow();
});

test("persists on component unmounts and rerenders", () => {
  function Comp() {
    const [value, setValue] = useLocalStorageSetState(0, "value");

    return (
      <div>
        {value}
        <button onClick={() => setValue(value + 1)}>Add value</button>
      </div>
    );
  }
  const { getByText, rerender, unmount } = render(<Comp />);
  expect(getByText(/0/i)).toBeInTheDocument();
  fireEvent.click(getByText(/add value/i));
  expect(getByText(/1/i)).toBeInTheDocument();
});

Now let's add the source code:

// use-local-storage-set-state.js
import React from "react";

export const useLocalStorageSetState = (initialValue, name) => {
  if (!name) {
    throw new Error("Name must be provided to persist to localStorage");
  }

  const [value, setValue] = React.useState(initialValue);

  return [value, setValue];
};

Now, when running yarn test, the tests pass!

Let's add more to the tests to show what more functionality we want, add the following:

unmount();
rerender(<Comp />);
expect(getByText(/1/i)).toBeInTheDocument();

We're back to failing again! Let's add the proper source code.

Let's think about this before writing some random code.
When value changes, we want to persist that value into localStorage. So, value changes, function needs to fire.. This is exactly what useEffect is for!
Before we proceed, let's install the store npm module for efficient cross browser localStorage support:
yarn add store

Here is the source code with useEffect:

// use-local-storage-set-state.js
import React from "react";
import store from "store";

export const useLocalStorageSetState = (initialValue, name) => {
  if (!name) {
    throw new Error("Name must be provided to persist to localStorage");
  }

  const [value, setValue] = React.useState(initialValue);

  React.useEffect(
    () => {
      store.set(name, value);
    },
    [value]
  );
  return [value, setValue];
};

yarn test is still failing, we're almost there! We need to read from localStorage for the initial value.

// use-local-storage-set-state.js
import React from "react";
import store from "store";

export const useLocalStorageSetState = (initialValue, name) => {
  if (!name) {
    throw new Error("Name must be provided to persist to localStorage");
  }
  const actualInitialValue =
    store.get(name) !== undefined ? store.get(name) : initialValue;
  const [value, setValue] = React.useState(actualInitialValue);

  React.useEffect(
    () => {
      store.set(name, value);
    },
    [value]
  );
  return [value, setValue];
};

And now, yarn test is passing!

Now, there are a couple extra edge cases that we missed here, let me know in the comments if you would like those covered, but, you should be able to implement those yourself!

Source code available here: https://github.com/mcrowder65/local-storage-hook

What's the difference between an action creator and a action?

Matt Crowder — Thu, 04 Apr 2019 01:00:07 +0000

An action is simply an object that has two things: a type, and a payload.

An action creator is simply a function, that just returns an action.

Why do we care about action creators? I don't think one should care to correct people who don't differentiate between actions and action creators, but it is a good thing to make action creators, because it provides a way to have reusable actions that you can use all throughout your code base.

Also, you can add logic in there that you may not want to have to remember to do each time you use an action.

My favorite example is when you have to create a uniquely generated id.

import shortid from "shortid";

export const addPost = ({ title, body }) => {
    return {
        title,
        body,
        id: shortid.generate()
    };
};

What do you like to do with your action creators?

What happens when you only write try/finally

Matt Crowder — Mon, 01 Apr 2019 22:42:21 +0000

I thought to myself today, hm, what happens when you do try/finally, and don't have a catch clause, so, what is the output here?

const errorThrower = () => {
  throw new Error("i am an error");
};

const errorInvoker = () => {
  try {
    errorThrower();
    console.log("errorInvoker");
  } finally {
    console.log("finally");
  }
};

const catcher = () => {
  try {
    errorInvoker();
    console.log("catcher");
  } catch (error) {
    console.log("catcher caught the error");
  }
};

catcher();

I thought that the output would be:

finally
catcher

But actually the output is:

finally
catcher caught the error

In errorInvoker, the try block executes, and errorThrower() throws an error, and then immediately after the error is thrown, the finally executes, then catcher catches the error that errorThrower threw, and logs catcher caught the error.

JavaScript object spread explained

Matt Crowder — Mon, 01 Apr 2019 00:50:38 +0000

If you want to update a piece of an object while creating a new object, then the spread syntax is the way to go.

When you see ..., you should just think of flattening the object.

When you see this:

const metadata = {
  first: "Matt",
  last: "Crowder"
};

const updatedMetadata = {
  ...metadata,
  last: "Jenkins"
};

You should just see updatedMetadata as such:

const updatedMetadata = {
  first: "Matt",
  last: "Crowder",
  last: "Jenkins"
};

Key/value assignments are read from top to bottom, so the last key's value will take priority in setting the value.

And now updatedMetadata will have the value of:

{
  first: "Matt",
  last: "Jenkins"
}

So the spread flattens out the object wherever you place it, so if we had placed the spread metadata after last: "Jenkins", then we would get no updates!

const metadata = {
  first: "Matt",
  last: "Crowder"
};

const updatedMetadata = {
  last: "Jenkins",
  ...metadata
};

// results in 

const updatedMetadata = {
  last: "Jenkins",
  first: "Matt",
  last: "Crowder"
};

// which gives us nothing

So be careful where you place your spread syntax!

How to test implementation details with react-testing-library

Matt Crowder — Sun, 31 Mar 2019 03:00:31 +0000

If you are using enzyme to test your react components, you should consider switching to react-testing-library as soon as possible, its API is intuitive, easy to use, and it encourages writing tests in a way that your end users use your application.

With that being said, when you write tests with react-testing-library, it does not directly expose a way to test the implementation details of a component, because your users do not care if you're using a stateless functional component, a stateful functional component (a component with hooks), or a class component. With enzyme, it's easy to test implementation details, which then encourages engineers to ... test implementation details.

I had the odd scenario where it made sense to test implementation details, but I only knew how to do so with enzyme, so I made a tweet listing my concerns, to which react-testing-library's author, Kent C. Dodds, promptly replied saying that I can test implementation details by using refs. Tweet available here: https://twitter.com/mcrowder65/status/1100587157264187392

So I set out to find out how to accomplish this!

The specific use case I was having at work was with ag-grid, so I wanted to reproduce here as well, let's render a simple grid with the following code:

import React from "react";
import { AgGridReact } from "ag-grid-react";
import "ag-grid-community/dist/styles/ag-grid.css";
import "ag-grid-community/dist/styles/ag-theme-balham.css";
import CellEditor from "./custom-cell";

function App() {
  const columnDefs = [
    {
      headerName: "Make",
      field: "make",
      cellEditorFramework: CellEditor,
      editable: true
    },
    {
      headerName: "Model",
      field: "model",
      cellEditorFramework: CellEditor,
      editable: true
    },
    {
      headerName: "Price",
      field: "price",
      cellEditorFramework: CellEditor,
      editable: true
    }
  ];
  const rowData = [
    {
      make: "Toyota",
      model: "Celica",
      price: 35000
    },
    {
      make: "Ford",
      model: "Mondeo",
      price: 32000
    },
    {
      make: "Porsche",
      model: "Boxter",
      price: 72000
    }
  ];

  return (
    <div
      className="ag-theme-balham"
      style={{
        height: "130px",
        width: "600px"
      }}
    >
      <AgGridReact columnDefs={columnDefs} rowData={rowData} />
    </div>
  );
}

export default App;

This produces the following:

If you look at columnDefs, you'll notice that I added cellEditorFramework, this allows me to add my own, custom cell editor here. Let's look at that custom cell editor.

import React from "react";
import { TextField } from "@material-ui/core";

class CellEditor extends React.Component {
  state = {
    value: this.props.value
  };
  getValue() {
    return this.state.value;
  }

  handleChange = event => {
    this.setState({ value: event.target.value });
  };

  render() {
    return <TextField value={this.state.value} onChange={this.handleChange} />;
  }
}

export default CellEditor;

You'll notice here, that we are just setting local state values which takes the initial prop value and syncs to local state. But one thing you'll notice here if you look closely, getValue is completely unnecessary, it does not provide any value! Let's look at what ag-grid does now when I start editing with getValue removed:

The value disappears once we're done editing! This is because ag-grid calls getValue to get the final value once we're done editing, it doesn't know that the value is stored in state. So, there are three things one must do to ensure that this code works.

Add getValue back.

Add a jsdoc like so:

/**
* Ag-grid calls this function to get the final value once everything is updated.
* DO NOT DELETE
* @returns {String|Number} this.state.value
*/
getValue() {
return this.state.value;
}

Create a unit test that tests that getValue() returns this.state.value
Let's write that unit test!

If you read the tweet, you noticed that Kent said, "You can do that with with react-testing-library using a ref in what you render in your test.", then let's do that.

In custom-cell.test.js:

import React from "react";
import { render } from "react-testing-library";
import CustomCell from "../custom-cell";

test("that getData returns this.state.data", () => {
  const ref = React.createRef();
  render(<CustomCell ref={ref} />);
  expect(ref.current.getValue()).toEqual(ref.current.state.value);
});

Now we know, if someone gets rid of getValue for some reason, it will fail, and you are protected.

Again, there are VERY rare cases where you need to do this, so please think twice, maybe even thrice, whether or not you should be doing this.

Source code available here: https://github.com/mcrowder65/rtl-testing-implementation-details

You've been doing mapDispatchToProps wrong this entire time

Matt Crowder — Sat, 30 Mar 2019 18:08:34 +0000

Do this:

const mapDispatchToProps = {
  decrement: () => ({ type: "DECREMENT" }),
  increment: () => ({ type: "INCREMENT" })
};

instead of this:

const mapDispatchToProps = dispatch => {
  return {
    decrement: () => dispatch({ type: "DECREMENT" }),
    increment: () => dispatch({ type: "INCREMENT" })
  };
};

The difference is that we rely on react-redux to inject dispatch on each value that is a function in our mapDispatchToProps object, rather than relying on react-redux to inject dispatch into our mapDispatchToProps function.

If you are not effectively testing your code, then this is an easy way to increase code coverage, but it will also prevent bugs, because then you don't have to worry about forwarding extra arguments.

For a working example on github, see this repo: https://github.com/mcrowder65/map-dispatch-to-props

How to center elements vertically on a create-react-app project

Matt Crowder — Fri, 29 Mar 2019 21:08:40 +0000

TLDR: Just add the following to public/index.html

<style>
  html, body, #root, #root>div {
    height: 100%;
    margin: 0;
  }
</style>

You've just run create-react-app my-app, and now you edit your App.js file to include a centered button:

import React, { Component } from "react";

class App extends Component {
  render() {
    return (
      <div
        style={{
          display: "flex",
          justifyContent: "center",
          alignItems: "center"
        }}
      >
        <button onClick={() => alert("hello")}>alert hello</button>
      </div>
    );
  }
}

export default App;

But, oh no! It is only centered horizontally, and not vertically!

To look further, add a background color to your div there, like so:

<div
  style={{
    display: "flex",
    justifyContent: "center",
    alignItems: "center",
    backgroundColor: "blue"
  }}
>

You will notice that the blue background does not take up the entire screen, even though this div is the only thing in the application at the moment.

In order to fix this, add the following to public/index.html:

<style>
  html, body, #root, #root>div {
    height: 100%;
    margin: 0;
  }
</style>

Source code available here: https://github.com/mcrowder65/centered-cra-example