console.blog( ,

Game Tracker devlog #1

Thomas Randolph

Thomas Randolph

 

A few months ago, I started working on a new web application.

A commit graph showing many commits in August and September of 2022, but only a few in October.
My commits were pretty strong - almost daily - in August and September. All on this new app.

As with most apps I start building, this new one is to scratch my own itch. I've been using video game tracking (and movie tracking) sites for a long time, but I've never found a video game tracker that felt like the tool I wanted to use.

When I started, I had all of the early-project drive, and I got a lot done (I have 51 cards in my "Done" column!). But then, I came to the first problem: a feature that would allow the user to write their own data back to the application store.

No, I didn't get stuck on content moderation, I got stuck on the ability to submit a star rating.

ENCAPSULATION!

To be clear: I didn't actually get stuck on making a star rating. What I got stuck on is the idea - which I believe in strongly - that UI components should not make network requests.

Of course, network requests have to happen somewhere, so my approach for a long time has been to abstract those type of things (and every other kind of "not UI" action, too) out to another place.
This is super beneficial, because I can generalize any behavior, and I can exercise an event-driven architecture. However, it does have the one downside that I got stuck on: If I want to build an event-driven system and keep UI components clean, how far should I take that?

After all, if it's events all the way up, then I could catch every single event in exactly one place and branch to triggering actual behaviors from there, right?
But, the problem (of course) is that those UI components need to react to events occurring. Obviously, this problem has been solved in the most over-engineered way possible with Flux libraries like Redux and Vuex. You publish an action or you use a getter, and you go through a whole store update cycle, and then that data flows back down into the component. You've heard the story.

I have written - at length - about Flux in the past. As noted in that post, there are good parts to Flux. Namely, the directory full of actions that define how the application behaves.

Where I get stuck, though, is when I have to put this into practice. I don't actually want to abstract everything away from the components. I'm also absolutely loathe to put "business logic" and network calls into a UI element.
Where I'm at - with an architecture like Fluxbus - feels like the best of both worlds: I'm boiling behaviors like data access, network calls, and more to a single event action that can be observed by any actor in the entire application. The component only issues those actions and they are handled elsewhere ("business logic", essentially). I'm not depending on a global object or magical variables just like how the VDOM libraries have done it - badly - for years.
But, I still don't like it.

So that's how I got stuck submitting a numeric star rating on an app I'm working on.

Ultimately - like my refreshed approach to blogging ("just do it and worry about cleaning it up later") - I'm going to just forge ahead and deal with a refactor later.

My concern is not that I may have to refactor, it's that I can't think of the next improvement on top of this to remove all of the annoying bits. I feel nearly paralyzed by imposter syndrome.

Links I've been pondering