This pandemic has been awful for all the obvious reasons. One less-obvious reason is that there is a lot of data we’ll need in order to beat it, but most of that data is unknown, either because

Question: What’s wrong with this code?

A friend of mine who was trying to write custom hooks with useRef mentioned that refs were generally kind of confusing to him. After chatting through the things he wasn’t clear on, I realized that there were a few key concepts that aren’t necessarily obvious, but that give you the fundamental understanding to build on when using refs in other contexts:

How should you keep track of whether a component is mounted when using hooks? I got pretty confused about this, and the answer clarified by mental model of React hooks and I wanted to share.

I’m attending the awesome Write/Speak/Code (thanks Benchling for sponsoring!) and saw twelve talks today. Here were my top talks!

This blog is created with Jekyll using Github Pages. Jekyll has support for tagging blog posts, but Github Pages doesn’t whitelist those plugins, so if you want to use tags with GH Pages, you’ll have to do it yourself. I followed the guidelines on this blog post to get my tags up and running, which worked well, but I also wanted to automate the generation of the tag files in tags/ so I wouldn’t forget to do it.

I’ve been excited about React Hooks ever since I saw Dan Abramov’s intro talk last fall. I’ve been playing around with hooks in my side projects for a few months now, and I LOVE them. Reducing the clutter of JS classes? Great! Eliminating bugs from missed lifecycle hooks? Awesome! Moving to a render-first (rather than a life-cycle-first) mindset? Super duper great! Encapsulating stateful logic? THE BEST!

I got a new job! Well, new as of earlier this spring, anyway. From March 2016 to April of this year (2018), I worked at Mavenlink. In May, I started a new job as a software engineer at Benchling (I took some time off in between to travel to Spain and visit family). I’ll explain why I made the switch below.

At my job, we’re in the process of writing a library of shared React components. (This blog post deals with React, Ruby, and Selenium, but the concepts are applicable to anyone writing integration tests for a shared set of reusable components.) This is awesome, and we’re seeing high rates of adoption and modification among devs. However, when writing our integration specs, we end up writing the same selectors and behavior over and over. I came up with a solution this week for how to help improve some of the pain we’re feeling, and I wanted to share it with you:

Welcome to my blog! I built this using Barry Clark’s excellent repo and blogpost. I’ll be updating the styling on this soon to make it my own, but for now, I’m just looking forward to having a place to host my projects and ramblings. Talk to you soon!