Week 16: A Recap
React & Development
I am beyond the point where I would take some time to complain about React. Truth be told, I like the way that React Hooks work, because they encourage lean and DRY code. Hooks are a smart response to some of the pain points in React’s old ecosystem and it’s obvious that they are the result of smart people thinking about a problem that they were very familiar with.
Hooks for React heavily rely on functional programming principles. I’m pretty happy that I fully understand closure, otherwise Hooks would probably feel like complete magic to me. Still, as someone who is not used to functional programming in his everyday coding life, thinking in terms of pure function constructs does not come easy.
Hooks are also deceptively simple at first glance. The by far most often used ones are
useEffect and in Tutorial Land, they are easy to grok. One is for managing state inside a functional component, the other is for managing any side effects. The remaining available hooks are used mostly in special circumstances, which leaves the eager React learner with custom hooks, the extraction of functionality into hooks that can be reused.
Once I have left the happy path of Tutorial Land, I ran into many issues. I have seen tutorials for writing a custom hook that fetches data from an API, probably the most common task for React. But I did not know how to handle all the small details that were necessary for my use cases: how do I control when the data gets fetched, instead of just the obvious way when a component is mounted to the DOM? How do I refetch data after the initial run? Why is my data suddenly stale and not up-to-date? Now how can I use this concept for server-sent events instead of normal API calls? And why exactly do I have to invoke hooks only on the top level of my function component (which has a very easy answer, but felt unintuitive at first)?
Frontend is hard. For the backend API portion, I could anticipiate most user actions, and if it didn’t match, I would send a 500 response. Frontend requires visual feedback and proper error handling to not result in a frustrating user experience. That takes time and consideration, and it lead to quite a few wasted hours. I should have kept track on how much time I have already spent on giving the user pretty-printed JSON for any custom route responses. It still doesn’t work in a satisfying way, and just a few minutes ago I completely broke the system again and now only get the dreaded
[object Object] inside of the text input fields.
It’s a cumbersome process, and this shows in my slow progress with the custom route behavior functionality. I knew beforehand that this was the largest piece of functionality left, but implementing the backend code for it was almost too easy, so grinding to a halt in my progress was a surprise. I am also still unhappy with the inability to properly debug my Preact components, but I’m too stubborn to change that now.
There is no way around the remaining issues (and they become less with each day), but until I fixed at least the glaring UI/UX bugs in the custom route module, I will not update the live version on 200ok.app.