Question: I am a JavaScript developer on a journey to up my skills in functional programming. I recently ran into a wall when it comes to managing state. When searching for a solution I stumbeled over the state monad in various articles and videos but I have a really hard time understanding it. I am wondering if it is because I expect it to be something it is not.

### The problem I am trying to solve

In a web client I am fetching resources from the back end. To avoid unnecessary traffic I am creating a simple cache on the client side which contains the already fetched data. The cache is my state. I want several of my modules to be able to hold a reference to the cache and query it for its current state, a state that may have been modified by another module.

This is of course not a problem in javascript since it is possible to mutate state but I would like to learn more about functional programming and I was hoping that the state monad would help me.

### What I would expect

I had assume that I could do something like this:

```
var state = State.of(1);
map(add(1), state);
state.evalState() // => 2 

```

This obviously doesn't work. The state is always 1. 

### My question

Are my assumptions about the state monad wrong, or am I simply using it incorrectly? 

I realize that I can do this:

```
var state = State.of(1);
var newState = map(add(1), state);

```

... and `newState` will be a state of 2. But here I don't really see the use of the state monad since I will have to create a new instance in order for the value to change. This to me seems to be what is always done in functional programming where values are immutable.

Answer: 
It indeed works like your second description where a new immutable state is returned. It isn't particularly useful if you call it like this, however. Where it comes in handy is if you have a bunch of functions you want to call, each taking the state returned from the previous step and returning a new state and possibly another value. 

Making it a monad basically allows you to specify a list of just the function names to be executed, rather than repeating the `newState = f(initialState); newNewState = g(newState); finalState = h(newNewState);` over and over. Haskell has a built-in notation called do-notation to do precisely this. How you accomplish it in JavaScript depends on what functional library you're using, but in its simplest form (without any binding of intermediate results) it might look something like `finalState = do([f,g,h], initialState)`.

In other words, the state monad doesn't magically make immutability look like mutability, but it can simplify the tracking of intermediate states in certain circumstances.
**State** is present everywhere. In class, it could be the value of its properties. In programs it could be the value of variables. In languages like javascript and even java which allow mutability, we pass the state as arguments to the mutating function. However, in languages such as Haskell and Scala, which do not like **mutation**(called as side-effects or impure), the new State (with the updates) is explicitly returned which is then passed to its consumers. In order to hide this explicit state passes and returns, Haskell(and Scala) had this concept of State Monad. I have written an article on the same at <https://lakshmirajagopalan.github.io/state-monad-in-scala/>