Everything’s Related, Redux, and Time

For quite a long time, I’ve wanted to share a decent number of thoughts on a multitude of topics relating to software engineering. However, I’ve found writing these ideas tends to be pretty difficult, the reason why is because everything relates to everything else. So, I start trying to explain one topic, but then realise that it may not make sense given this other topic which in turn relates to another topic which may need explaining.

This piece ends up getting pretty off-topic, and I’ll probably just use this as a place to write about a whole bunch of semi-related things.

This is probably not the most easily read piece of writing I’ve ever produced.

Reasoning behind Simple Actions in Redux

The reason I argue for simple, serialisable actions in Redux is because I see crossovers between redux and other technologies or concepts that I’ve come across whilst being a software engineer. For instance, the concept of Time, the concept of Event Sourcing, my knowledge of distributed systems (this includes microservices), and my thoughts on clear debuggable code.

In our applications, whether they’re for the web or a native environment (desktop or mobile), there’s usually a lot of things happening: user interactions, data loading, complex user interfaces, etc. This results in needing to coordinate a large number of things continuously.

In our applications, we also have the concept of Time (see below), in applications using Redux, we can measure Time as being the number of actions dispatched, as state in Redux is the reduction of actions that are dispatched, over time since our application started.

If we log out the actions dispatched from our application, then it’s easy to reason about what is the state of the application at a given time. For example, we dispatch actions A, B, C, and D, they might be the same action, or they might be different actions, but we know that they happened in that exact order, then we can talk about the state of our application as being State at Time 0, State at Time 1, …, State at Time 3.

All of the Redux powered applications rely this idea, that state is just the reduction of actions that have happened up until a given point in time: this makes the whole thing easier to reason about.

Like wise, simple actions are easy to reason about: if you need more complex actions, most likely what you want to do are side-effects to actions, which should be handled through middleware, sagas or observables.

Time

If you look at wikipedia for what “Time” is, it starts the article with a rather philosophical sentence, describing time as:

the indefinite continued progress of existence and events that occur in apparently irreversible succession from the past through the present to the future

To the everyday people, time is pretty simple: You look at a clock and go “oh, it’s 7:55pm” and realise that you’re late for dinner.

However, this assumes that the time which your clock shows is correct, generally through manually synchronising our clock with another clock, which in turn is synchronised with another clock, and so on, until we get to a clock that has an internationally or globally agreed value — in the case of time on Earth, this is Temps Atomique International, which is an atomic clock that everyone has agree should be the source of truth for time. (See also: clock synchronisation and single sources of truth)

That clock, is known as a physical clock, as it’s basing time on the continual physical events related to atomic matter.

In programming and computers, that time is known as “wall-clock time”. There’s also another type of time, known as CPU time, which is derived from the number of CPU Cycles taken to complete a certain task.

In distributed programming, there’s yet another idea of time, one that I was first introduced to back in 2011 thanks to a talk by Jack Moffit at Keeping it Realtime Conference. This is vector clocks, which represent time as a shared values, which change based on events. There’s also Lamport timestamps which are part of an algorithm to define the order in which a set of events happened.

Later on, I learned of another way of representing time, which is to talk about time in an abstract sense. That is, rather than event A happening at 8:55pm and event B happening at 9:00pm, we can just say that event A happened at time zero, and event B happened at time one. This removes the value of time, and instead just says that these events happened in this given order.

This idea of representing time as an abstract concept is particularly useful when talking about events that happen in a given order, and when trying to communicate that order to other people or systems. Here’s a good set of slides about Time in distributed systems.

This article was written with the support of donations to Emelia Smith. At present, you cannot hire her, however, you can donate to her and ask her a question on Twitter. She will also be at React-Europe in May.