Today I Learned

I put this blog together at a time when I was learning modern React based web development and trying to better myself. This was largely driven by my personal interest, but I also saw React as a good career opportunity. Writing a personal blog helped in that process.

Fast-forward almost two years and I am working as a Software Developer, developing with React daily and learning TypeScript as well. This blog has sadly been put on the back-burner for quite a while and I am not happy about that.

I have limited personal development opportunity at the moment, being a father and working in a new-ish role in lockdown has meant personal projects have had to be put aside or even sunsetted.

Today I learned a lesson that Hugo definitely wants your content in the content/posts directory. I learnt this by needing to make an addition to my Hugo theme that themes this site.

As I am now working from home, and have recently set my personal Mac up for local development, I used Homebrew to install Hugo. Previously I often used Hugo on my work PC. I then navigated to the local version of my TIL repo, ran hugo server and navigated to localhost:1313. What I saw was that my site was really broken.

I previously wrote a post about using Lodash debounce with a React component. I recently had to use a controlled input, that needed a debounce effect on it. But the difference between this new component and the one in my previous post was this new component was written in a functional way, using React hooks.

So the scope for this component would be to take an initial value from it’s parent, handle changes in state, and then when the user has stopped typing, after a short delay, to lift the state up to the parent so that the input value can trigger something in the parent.

Immediate problems

After writing the new component to use Lodash debounce, and taking advantage of useEffect to trigger side effects based on the input value changing I immediately saw a problem. I have increased the debounce “delay” to two seconds to exaggerate the effect.

Today I learned more about controlling Tailwindcss output CSS. Based on my previous post I am now in a position to use Tailwindcss on a client project. That means I have been digging into the documentation and that has revealed to me a few more intricacies of the tailwind.config.js.

I started off by adding only the corePlugins I wanted to use to the config. But as that list grew it became clear that selectively disabling corePlugins was going to be simpler than adding the ones I wanted to use.

So I got a list of all the corePlugins, processed it in my text editor and used that to generate some boilerplate configs. Those configs are meant to be edited to taste and not used as they are.

I put this together in a new GitHub repo with some explanations of the configs and examples of their output CSS.

Today I learned more about the subtle art of javascript performance. I have been doing a few algorithm challenges on freeCodeCamp, which is a great resource. Whilst completing one titled “Intermediate Algorithm Scripting: Smallest Common Multiple” I had a look at what other solutions people had posted, and how they compared to mine. A user had put together a CodePen running BenchmarkJS that contained about four solutions. I added my solution (below) to the benchmark test and the results were surprising.

Following on from my previous post, I am going to show a real example of asynchronous redux. The pattern below is used in many places in the app I am working on. It provides control for what is going to happen when the app needs to request/interact with data from the API.

This is not a traditional “Today I learned” post. It is more like a “Recently I learned”. I have been using Redux as a system to control state across an app that has a lot of state. Once you get used to the actionType, action, reducer and selector pattern it really provides a deep level of control.

State complexity

It was not long before the need for complex redux actions became clear when the app required data from APIs. That data needed to be requested, processed and added to the redux store before other components could consume it.

This lead me to Redux Thunk as a way to define actions that were more complex than simply returning a plain object. Often these actions would need to execute promises. So a need to control the sequence of these actions was becoming a priority for the app.