State

If you’ve been working in JavaScript within modern day applications, then you might have heard of the concept of state. If you haven’t then I suggest your familiarize yourself with it - modern day applications are all incorporating this concept into their applications and it’s an emerging category in JavaScript. Some people say it’s not necessarily something every developer needs a tool to work with, but if you’ve been following along with industry news then you’d want to understand the basic concepts behind state management in an application.

We’ll explore they why we need to touch three files to get a simple feature working in upcoming posts.

What is State?

State in an application can be described as any data that can change. For several years, this was overly complex in JavaScript because the only thing we could really track was function calls, so early versions of libraries included requiring all state changes to be invoked via calls to get and set methods. Early implementations of watching and observing property changes were cumbersom and often brittle. Native getters and setters eventually arrived to the language which made this a bit easier to manage. Later a proposal was made for Object.observe, but it was withdrawn as a proposal as it had too many issues. In parallel, as reactive programming emerged, the ES8 Observables feature has become the standardized form of RxJS Observables, providing a very efficient way to track changes.

React and first Flux and then Redux have recently got everyone thinking about how to manage state in a predictable manner for JavaScript applications. Angular 2 can be used with Redux, there’s a version of Redux for Vue.js users. Whether you follow this approach or one of many others, it’s become clear that state is a big challenge to get right in application architecture, and we’re still in the early stages of having an approach that makes a lot of sense. We’re at the point of having some very nice native language improvements, coupled with strong influences from other functional languages like Elm and PureScript.

Community Interest

That being said, developer interest is pretty high in all of these tools, especially Redux (81% of people who know about it wanting to try it), which fits the narrative of increasingly complex front-end applications. Given most of these tools didn’t exist two years ago, it’s clearly a rapidly changing landscape. It’s especially interesting seeing the high level of interest in Redux, given that Redux creator Dan Abramov repeatedly stresses that not every app needs it, and that users should wait until they run into problems before building an app with Redux.

Overall, Redux users are happy users with one of the highest satisfaction ratings of any library; MobX and Relay are middling in this respect and we can perhaps expect to see other competitors emerge in the months to come in this rapidly changing area.
I’m betting that we’ll see a big difference in interest and usage in the future.