I spent a few hours tinkering with the new (alpha release) version of React which includes the new React Hooks feature. I wanted to experiment with it in a semi-realistic environment (not CodeSandbox). I have built a few chrome extensions in the past and I knew the challenges well so I thought it would be a good scenario to challenge React Hooks and see what it can do.



# TLDR:

The below video is a quick demo of what the chrome extension does.

<iframe width="853" height="480" src="https://www.youtube.com/embed/iydk07TCOOs" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>

The video demonstrates how the state is able to be shared between the background page, child pages and content scripts simultaneously.

The code is available for your perusal here: https://github.com/mikecann/react-hooks-chrome-extension

If you want to hear about some of the issues and their solutions I faced read on..

# The Chrome Extension State Sharing Problem

Over the years I have authored a number of Chrome Extensions. They have been written in all manner of different ways using all manner of languages and libraries; React, Aurelia, Angular, Mobx, Mobx State Tree, Typescript, Redux and plain old JS just to name a few.

One of the problems that I always face with many of the extensions is how to share the state between the various pages in a chrome extension. Chrome Extension's have multiple "entry points"; a content script (injected), a settings page or a browser action page (the popup that you get when you click the button in chrome). These multiple entries means that you need a way of sharing some common state between all the pages.

Fortunately chrome has provided a number of different ways of doing this. Below are my two favorite.

## Storage Sync

One way of sharing state is via the [chrome sync storage](https://developer.chrome.com/extensions/storage) mechanism. Whenever the state changes on one of your pages you write those changes to `chrome.storage.sync`. Other pages listen for changes to storage and subsequently update their own internal state.

This method is okay but it has its limitations which include storage size limits (5mb unless you give unlimited storage permission), rate limiting and other potential permission issues.

## Message Passing

A second method for syncing state is involves each page passing messages to each other. Using `chrome.runtime.connect` a page can connect to the background page and inform each other of when the state changes.

This method however works well but only if you have a central storage of state and are able to detect changes to that state in a unified way.. enter react-hooks...

# React Hooks

[React Hooks](https://reactjs.org/docs/hooks-intro.html) is a brand new feature (currently in alpha) for [React](https://reactjs.org/). When I heard about it I got excited because it looked like the React guys were once again going to blow my mind by exploring a wholely new way of building apps.

The full details on how hooks work are in [the excellent docs](https://reactjs.org/docs/hooks-intro.html) but the idea is is fairly simple: allow users to write functional style components while allowing state to be managed in a composable, reusable way.

I knew that there was only so much I was going to be able to understand about the technology from reading about it. I was going to have to dig in there and tinker with it a little bit.

## The Event Listener Array Issue

One issue I faced early one with React Hooks was a fundamental "stale state" issue when dealing with event listeners. To demonstrate the issue take the following example:

```typescript
export function useRuntimePorts() {
  const [ports, updatePorts] = useState<chrome.runtime.Port[]>([])

  function onPortConnected(port: chrome.runtime.Port) {
    console.log("port connected", ports.length)
    updatePorts([...ports, port])
  }

  useEffect(() => {
    chrome.runtime.onConnect.addListener(onPortConnected)
    return () => {
      chrome.runtime.onConnect.removeListener(onPortConnected)
    }
  })

  return ports
}
```

This is a custom react hook that's job is to manage the state of connected "ports" from other pages in the extension. It listens to the chrome runtime api for connections from other pages and updates its state (array of ports) which it then exposes to consuming code by returning the ports.

When a new connection is made, we get a console message that tells us a port was connected. We are also given the number of currently connected ports. As expected the number of ports increases as we open more connections from other pages.

The keen eye will notice that the `effect` is re-executed every time that the hook is re-executed on each re-render. This means the event listener is continually being added and removed. This seems wasteful and luckily the React API has a solution in the form of a ["third" parameter](https://reactjs.org/docs/hooks-reference.html#conditionally-firing-an-effect) that you can pass to `useEffect`, an array that indicates only run the effect on the update if one of the the elements in the array has changed.

So if I simply supply an empty array it means that the effect will only be run once:

```typescript
  ...

  useEffect(() => {
    ...
  }, []);

  ...
```

This is great, it now means we dont wastefully attach and detach the listener every time the component is re-rendered.

When we try this out in out extension however a problem has arisen. The console message that tells us that a port has connected now no longer counts up the number of ports, it stays at 0. Why is this?

Well if you think about it, it makes sense, we arent re-attaching the event listener on each time the hook is executed. That means that the `ports` variable inside of the `onPortConnected` handler is always going to be the original array the first time that this hook was run. So doing an immutable append `[...ports, port]` is always just going to append the latest port to an empty array.

I struggled with this issue for quite some time. I tried quite a few different things including trying out `useRef` to hold a mutable array, but that seemed hacky. There must be a better way I thought to myself.

Eventually I decided to pose the question on the [Reactiflux discord chat](https://discordapp.com/channels/102860784329052160/103696749012467712). A fine fellow by the name of Kingdaro responded with:

> Try using the callback in the update function
> `updatePorts(ports => [...ports, port])`. In theory that'll make it so that the port will reliably always be added to the end of whatever's there, as opposed to using what's in scope

Bingo! That was the missing link. I hadn't realized you could pass a function to the state update function instead of the next state ([despite it clearly mentioned in the docs](https://reactjs.org/docs/hooks-reference.html#functional-updates)). With that subtle change and my hook now looked like:

```typescript
export function useRuntimePorts() {
  const [ports, updatePorts] = useState<chrome.runtime.Port[]>([])

  function onPortConnected(port: chrome.runtime.Port) {
    updatePorts(prev => {
      console.log("port connected", prev.length)
      return [...prev, port]
    })
  }

  useEffect(() => {
    chrome.runtime.onConnect.addListener(onPortConnected)
    return () => {
      chrome.runtime.onConnect.removeListener(onPortConnected)
    }
  }, [])

  return ports
}
```

And huzah! The console message logged out incrementing port count as expected.

## Testing

One other major question I had for React Hooks was how does one go about testing them?

Fortunately wiser folks (in the form of the prolific Kent Dodds) had already thought long an hard on this and created this excellent video: https://egghead.io/lessons/react-test-react-components-that-use-react-hooks and wrote this blog post: https://blog.kentcdodds.com/react-hooks-whats-going-to-happen-to-my-tests-df4c2b4d67b7

So armed with these I began testing.

```typescript
let state: ReturnType<typeof usePorts> | undefined

function SomeComponent() {
  state = usePorts(jest.fn())
  return <div>hello</div>
}

it("should add a port when one connects", () => {
  const { rerender } = render(<SomeComponent />)
  rerender(<SomeComponent />)
  const port = portFactory()
  chrome.runtime.onConnect.addListener.mock.calls[0][0](port)
  expect(state).toEqual({
    ports: [port],
    lastConnected: port,
    lastDisconnected: undefined,
  })
  expect(state!.ports[0].id).toEqual(0)
})
```

The above is a sample of my test for the `usePorts` hook. You will note that I include the hook inside a component `SomeComponent` with which I use to interrogate the state returned from the hook each render. I do this rather than calling the function directly because although hooks look pure they aren't actually pure. They require that they are run within the context of a rendering Component to work.

The `rerender()` call is necessary because hooks that use `useEffect` by their nature are asynchronous, thus to force React to apply the effect of the hook before we run out testing logic, we must re-render the component.

I am really quite happy with how easy they are to test and how little mocking there is. The only mocks I am using are the chrome API calls because they dont exist inside the testing environment. This means I am not testing the implementation and just the result which makes the tests far less brittle to refactors.

## The Performance Question

I only have one outstanding concern about Hooks, does re-defining then re-executing the scoped functions each render create extra memory on the heap?

What I mean is given my `useRuntimePorts`example from above, each time this hook is run is a new scoped `onPortConnected` function placed on the heap? If so, wouldnt this create a lot of extra memory and thus pressure on the garbage collector?

Basically, I would love to know what are the performance implications, specifically memory / garbage collection, of hooks?

# Conclusion

All in all im very impressed with React Hooks. The code that it produces is clean, easy (ish) to understand and is very testable. No proxys or magic is needed (sorry mobx, I love you but I hate the proxy magic), just plain old Javascript objects.

I cant wait to use hooks in a production app.

If you want to checkout the code then its all up on my repo: https://github.com/mikecann/react-hooks-chrome-extension

Its been a while since I wrote about my Chrome extension Trello Tasks but thats not for lack of interest in the project. At the moment it has 3,546 users and I have had innumerable requests for new features so seeing as I had to update it to comply with GDPR anyways, I thought it was time to give it some love.



# What does it do?

Well its pretty much exactly the same as Trello Tasks in functionality, so ill copy the description [from that post](/posts/trello-tasks-a-new-chrome-extension/):

![](https://www.mikecann.blog/wp-content/uploads/2015/11/screenshot-01-640x400.png)

The TLDR; of Trello Tasks is: it augments Trello by turning Cards into “completable” tasks.

One of the most common ways to use Trello is in the "ToDo" style. In this style you have three lists, ToDo, Doing and Done:

![2015-11-25_08-28-57](https://www.mikecann.blog/wp-content/uploads/2015/11/2015-11-25_08-28-57.png)

In this style, when you start work on something, you move it from the "ToDo" List to "Doing" List then when its complete you move it to "Done" List.

This is all well and good but what if you use a different system of organisation such as arranging the items by category:

![2015-11-25_08-31-45](https://www.mikecann.blog/wp-content/uploads/2015/11/2015-11-25_08-31-45.png)

Now if you want to indicate that you have read a book or watched a movie you would have to either drag it into the "Done" list (and loose the categorisation) or create a "Done" list for each category. One other option is to "Archive" the card but doing this removes it from the list altogether.

![2015-11-25_08-36-50](https://www.mikecann.blog/wp-content/uploads/2015/11/2015-11-25_08-36-50.gif)

So I decided to try and solve this very particular but annoying problem. My solution is to add a checkbox to each card. Now cards can be marked "complete" and "uncomplete" by simply checking the checkbox.

![2015-11-25_08-41-18](https://www.mikecann.blog/wp-content/uploads/2015/11/2015-11-25_08-41-18.png)

The extension works by piggybacking on Trello's comments system. So each time you complete or uncomplete a task the extension adds a comment to the card.

![2015-11-25_08-43-25](https://www.mikecann.blog/wp-content/uploads/2015/11/2015-11-25_08-43-25.png)

This means that in a multi-user board you can tell who completed or uncompleted a task and syncing "just works":

![2015-11-25_08-47-32](https://www.mikecann.blog/wp-content/uploads/2015/11/2015-11-25_08-47-32.gif)

# Whats different?

Well apart from 99% of the source code being different I changed the browser action to be clearer:

![](./browser-action.png)

I also upgraded the options significantly in anticipation of adding a bunch more settings in here:

![](./general-options.png)

I also gave the logging section an overhaul so you can see whats being logged and crucially download the log to send to me for analysis:

![](./logging-options.png)

Under the covers everything is syncing to the chrome cloud store so it should work across browsers without any private servers or privacy issues to me.

# Why change the Name?

The reason why I changed the name and created a whole new extension rather than upgrading of Trello Tasks was because when I reached out to Trello to see if I could get official approval from for the extension they told me that I would have to rename the extension to "X for Trello" to comply with their branding guidelines. Well I didnt want to do that at the time as I had just spent ages getting everything setup with the name "Trello Tasks" so I decided to keep it as it was.

So this time around I decided if I was going to do a rewrite, I might as well rename the extension at the same time and hopefully finally get Trello's approval.

# Rewrite?

So the decision to do a rewrite rather than an upgrade was partly because of the name and partly because I was going to have to make changes to Trello Tasks for GDPR compliance. I also realised that Trello Tasks was built using (what seems like) ancient coding practices so I decided in my typical naïve way that I should just start again, it shouldnt take too long, right?

Well it took about twice as long as I was expecting, but I am happy with the way it turned out.

# Open Source

I decided to do this rewrite on a public Github repo. This is because a great many extensions these days are doing very shady things such as crypto mining, ad injection, ad replacement, privacy violation and other things. I wanted to be able to avoid all of that by pointing to the source and saying; "here, look at the source, you can see im not doing anything shady".

I do intend to add "donation" features in the future to help with the costs of continued work on the extension but im trusting that most people wont then download the source and create their own extension from the source.. would they?

Anyway you can check it out here: [https://github.com/mikecann/tasks-for-trello](https://github.com/mikecann/tasks-for-trello)

# Using Trello for Support

So I decided this time around to use Trello itself as the hub for the project.

![](./support-ss.png)

People can leave comments, suggestions and error reports on that board which I will receive notifications for then update the board. Its a quick and simple way of managing the project.

# Trello Tasks Depreciation

So I also made a very small update to Trello Tasks at the same time to ad a message informing my users that Trello Tasks will be no more in a few weeks and to go download Tasks for Trello instead. I hope they all get the message!

# Download

If you are interested then you can go grab Tasks for Trello now from the chrome store: [https://chrome.google.com/webstore/detail/tasks-for-trello/cdbbpbodmdnhmbpnnmlpboepefbhiefp](https://chrome.google.com/webstore/detail/tasks-for-trello/cdbbpbodmdnhmbpnnmlpboepefbhiefp)