This component went through many iterations to get to the final shipped version.

I felt more comfortable using hooks to get the component to do the things it had to do. For example, here are a few things it needed to do under the hood:

1. It had to know what to do with a text input
2. It had to know when to open and close a dropdown
3. It had to know when to display tags
4. It had to know how to display selection to the user
5. It had to be keyboard accessible

This made the first version a little heavy on the JavaScript side for Phoenix Liveview.

When Phoenix Liveview detects a change in the DOM, it sends a message to the server. The server processes the diff and returns the least amount of code back to keep the rendered view up to date; hence the name Liveview. As a result, which happens with as little as a keypress, the page in the DOM is updated.

When using JavaScript that begins to work on mount, this causes an issue as the update in this framework does not retain the previous mounted variables, because the elements of the page that received a change are actually re-rendered altogether. Therefore, although the JavaScript has been running since mount, parts of the component are new renders and JavaScript functions break. In order to combat that, I was using the attribute phx-update="ignore", which prevents the update behavior on that element.

In doing so, I inadvertently created a state where updates that did not originate from user interaction were also being ignored, creating a component with a funky state.

The developers pointed these things out as points of concern for robust components that had to work in all the apps, so I embarked on rewriting the whole thing as a LiveComponent.

The result was that as soon as it was rewritten and could handle state without any crutches, it evolved from a simple typeahead to also include a variant that could easily handle multiple selections, display tags, and more.