Today I want to try something slightly different.

Over the last few months I have found myself working on a handful of legacy angularjs applications. These applications are typically single-page applications, use some form of database to persist the data and  contain very little in terms of documentation. In this blog series we will review application state, particularly in the context of a legacy application.

Before we go any further let’s take a minute to clarify what state is. To me state represents the application at a particular point in time. For example, say we are registering for an account on a generic website. On initial page load we are presented with a registration form to complete. Once we fill in the form and click the “Sign Up” button a number of things could potentially happen; we may have filled in the form incorrectly in which case some sort of error message should be shown identifying the input field which failed validation or if validation passes we should now be logged in and presented with a homepage. Either way the thing to note here is the state has changed and we need to update the ui to reflect this.

One common problem I have identified with these legacy angularjs applications is they typically manage the application state throughout the application. Lets quickly run through an example;

Our example application consists of a search input and a table. As we type on the search input we send an http get request to the server which responds with results filtered to our search phrase. We then take these results and populate the table. This works well until we are tasked with putting the search input in the sidebar on another page. Say we naively copy our search input and paste it into the sidebar. Now when the user types in the search input the application needs to know the current state in order to update the ui.

We can use a simple javascript object to represent our state:


{
page: ‘search results’,
searchPhrase: ‘testingabc’,
results: [],
…
}


The problem with the legacy applications I’ve been working on is the typical architecture involves services being responsible for executing shared code but not having access to the application state. Given our previous search input as an example an event listener would be registered on the search input which would call a function on the service to fetch the results and update the ui. Typically these applications have a multitude of services such as productService, userService, searchService etc… The problem is that these services are not aware of the state of the application, for example, the searchSearch isn’t aware of the page the user is on. This leads to situations where the ui does not behave as the user expected.

Next in the series…

In the next article in the series we will take a look a javascript library which can help us manage the state of our applications with much more confidence.