Rewrite the rewrite

March 09, 2020

My last post was discussed my own personal realization of how important it is to spend the time to fully understand your problem rather than diving in and trying to hack your way out from the middle. The learnings from this post could not have happened at a better time.

In my part time I’ve been building my own React library from scratch as a learning project. I started without thinking too much about the big picture, and I relied on my memory of how React works at an API level. The code ended up being fairly clean, but it had some fundamental flaws that resulted from a lack of planning. Namely, the library would not be able to support re-renders without unmounting and remounting components. Not only is this a major performance problem, but it also makes components that rely on focus, such as a text input, impossible to use. Worst of all, I didn’t realize this flaw until the code was built.

After a few dozen failed attempts at converting the existing code to support the proper re-rendering feature, I gave up on my constraint and decided to look at the React Implementation Notes to figure out what I was missing.

It turned out that my attempts were quite close to the original React implementation, but they were built upon a foundation that wouldn’t allow for clean updates. I spent a few days thinking about the React implementation, and let myself internalize the actual React implementation.

I started with an empty text file again, and after a few hours I had a much better solution than before: A simple React implementation that supports props, useState hook, and a small suite of tests to validate the behaviour. I won’t do another deep dive into the code here as it has a lot of the same concepts for what we’ve already gone over. For the full source code, check out the github repo.