Welcome! This is part of a somewhat lengthy (and slow) series of posts on building React applications. If you don’t want to start back at Part I, you should know I’m a firmly in the “Hooks are evil” camp, and React should be limited to just rendering your application state, which should be managed outside of React. In fact, We are on part eight of the series and haven’t even installed React yet.

Back to: Part I Motivation There’s a couple of (perhaps minor) things we can clean up from the PR on effects. Take a closer look at how effects are triggered: subscribe((state) => { let newState = state; for (const effect of effects) { newState = effect(newState); } if (newState !== state) { setState(newState); } }); The logic for most effects is: “Is the UI in a state where something needs to happen?

Back to: Part I Now we get a chance to demonstrate the “effects based on state” idea. Our state is a discriminated union of: type State = ConnectedState | DisconnectedState | ConnectingState; so the (simplified) logic is: “When we are disconnected, we attempt a Websocket connection”. Attempting the connection is the “effect”. The key point is we don’t do this based on any event, we do it based on the state.

Back to: Part I Meta: I’m going to start doing pull requests, please feel free to make comments on the PR. The first PR is kind of big, and this post is just a small part of it. I guess at this point the blog is like extended PR commentary, but let’s see how that format works. Immutable.js Records I immediately regretted my earlier decision to go with immutable.js over immer.

Back to: Part I Orientation In the previous post I said there would be three main pages: The player. The queue. The library. We only got to talking about the state for the player. This post should be simpler: I’m only going to implement the handler’s needed. Recall, our “handlers” are roughly an action builder and a reducer, for those familiar with Redux. They handle events in the browser, and update the state.

Back to: Part I The design will be personal, as this app has a target audience of one. I see three main pages: The player: Current song, basic controls. The queue: Upcoming songs. The library: Search and browse. In this post I will focus on the Player, and furthermore, modeling the state needed for the player. The Player Here we need information about the current track: Title Artist Album Track number Track position Track length As well as some basic controls:

Back to: Part I The Way Every non-trivial frontend application needs to deal with state and side effects, (and I’m sure a few other concerns). I’m proposing and experimenting with a particular pattern, but I want to emphasize the particulars of this pattern are not as important has having some established pattern. Even a small team of developers will inevitably choose several different patterns if there is not guidance on how to approach these concerns.

I’ve been meaning to write a post on “How I wish people made React apps” for a while now. Today I got annoyed by some HN discussion on React hooks. So that pushed me over the edge and figured I’d write something. This will be a multi-part series and part of the fun is discovering where we will end up. I’ve really only been involved in one production React app, so I’ll solicit feedback as we go along.

There’s a lovely old blog post What Color is Your Function (WCIYF). If you haven’t read that, please do so instead of reading this one. Since you are here, you should understand the colored function problem described in that post. I’d like to explore how that problem generalized beyond async concerns and how it connects to the much bemoaned monad. You don’t really need to know what a monad is to start reading this post, but you should understand the colored function problem described in the linked post.

Hi, I’ve been programming for about a decade and wanted to share some of my thoughts.