Day 77: The Engineer's Temptation

I spent 44 minutes trying to write a post about following the news, the value of staying informed, coronavirus stuff, etc. and then just scrapped it all because it wasn’t going anywhere and was hard to write.

So instead I’m going to talk about The Engineer’s Temptation.

As I mentioned yesterday, I’ve started using Firebase Firestore in Intention, and this is the first time I’m using some kind of backend for anything I’ve built since I got back into programming back in June or so. This also means that Intention now has two sources of data: local storage in Chrome/Firefox and Firebase Firestore. In building Hide Feed and Intention, I’ve basically custom rolled my own ORM that makes it quite nice to interact with the browser storage, but now I’m facing the challenge of trying to manage state while making asynchronous network calls. It’s not too bad continuing with the same pattern I’ve developed, but I can see that this could get complex pretty fast.

So when I came across react-redux-firebase, I heard the quiet whisper of the the OCD engineer within: “Maybe you should rewrite Intention to use Redux.”

I’m not going to lie; the voice is pretty tempting. Many people have already gone through the trouble to create a solution for the problem that I have, and using this library + Redux seems like it would make it much easier to reason about the state of my application.

I’ve used Redux before when building SlowTube and found that while it feels like there’s a lot of boilerplate and a lot of overhead (even using the Redux Toolkit), it does deliver on the promise of making it easier to reason about your application because you know exactly how your state is mutating through the reducers you create. And although I don’t think I’ll ever use the time-traveling capability for debugging, it’s just really cool.

Even though using Redux does sound promising, I think I’m also underestimating how much work it’d take to get everything hooked up to it. So it’s a battle between my pragmatic side (“just finish building this feature and start working on mobile, man”) and my purist side (“c’mon, you’ll end up with a much more maintainable and clean architecture if you bite the bullet”).

I’m going to go with the pragmatic side (or at least that’s my plan — I’ve had the purist burst into victory after incubating in my brain for a while) because I want to get this working, and it’s much more important to build a product that people actually use rather than have the best codebase. I can always rewrite the codebase later, after it becomes abundantly clear that the tradeoff is worth it. Sorry, purist.