State, State & More State

In an environment where we continue to drive forward with making more & more complex solutions, whether this is just a single page application or some infrastructure solution. I think it’s reasonable to conclude that we’re all in the same boat, we’re facing the complexity of dealing with state. 🚢

This is an awesome domain if you ask me, I freaking love talking about state. It’s one thing that always seems to annoy me with pretty much all of the front end libraries/frameworks, they try to handle state for you to some degree or another. Now if you’re working on a simple web based application, then this is probably totally irrelevant. Not to mention, lucky you! 😅

But let’s just target front end web based applications a second, by todays standards, they can be so complex, to the point where you’re juggling so many variables that not even Redux or the use of reducers will save you. In my spare time, recently I’ve been cooking up some little side projects, I wouldn’t really call them frameworks in a traditional sense. But technically, you could say that I’m building out my own framework, it doesn’t do much for you at all, if anything it doesn’t really do anything for you, it’s more of a model, a guideline if you will. A means to structure your front end web application.

Did I mention that I’m using TypeScript for this? 🚀 – I know how a lot of the JavaScript developers out there love TypeScript! 😅

Shenanigans aside, it can be so easy to handle state, I know that seems like a contradiction, but please, bear with me a moment. State management typically is hard because we make it harder than what it needs to be, let’s take a typical React application as an example. If you don’t use some way to share state, let’s say between a welcome screen & an account settings screen, ironically it’s pretty difficult to get access to the email address.

That’s kinda hilarious when you sit there & think about it as a rational minded person, forget everything you know about tech for a second. Now explain why we do that to yourself, try explaining to a non technical person why we do that. Personally I have done this & I’ve had some very amusing discussions through this exercise. 😅

We can essentially have a single source of truth, sure it doesn’t need to be global or anything, but you could easily have some ‘state manager’ class that behaves like a singleton. You could wrap that implementation inside of a self invoked function & as if by magic, you’ve blocked off access to that class/function/etc from the global scope. 🧙‍♂️

But let’s look into a case where we have a counter, because everyone knows that in order to have a great web application, you need a button that increases some number by 1 & another button that will decrease that same number by 1. It is the web application to develop, want to work for FAANG? That’s your ticket right there. 🎫

But what about allowing people to undo actions? God forbid that we need them to re-do the same action that they just did, that requires far too much effort, right? 😅 Well here’s a simple idea, why don’t you store previous known points of state? Want a coded example, way ahead of you right there!

That is rocket science right there! 🚀 – But seriously, look at how damn simple that really is, with this solution we can allow people to undo an action & undo an undo, aka a redo. Awesome stuff, right? 😅 In all honesty, I’m not sure you could break that down into a more simplistic solution, I mean sure, it might be different but would it be any more simplistic? 🤔

But in all seriousness, this is just one ‘class’, I only use brackets because I know how anal some people can be because this implementation is using the old school function syntax. But seriously, you can see how this example is a self contained block, we don’t have a component that is leveraging a reducer, it’s just a simple ‘model’ that’s self aware of its state & exposes use cases, in this case the only use case being ‘click’, but it proves a point, this is simple.

Ironically, by using a pattern like reducers, at least in the traditional sense, we’re developing code smells right off the bat. I know that sounds funny, it does. But a lot of people are firm believers that the use of switch statements is in fact a code smell. Personally I’m not saying I agree nor disagree with that, it’s very context specific, but in a number of scenarios, I would agree, this post being a pretty good argument.