> For the complete documentation index, see [llms.txt](https://akhilgangula.gitbook.io/mock-json-response/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://akhilgangula.gitbook.io/mock-json-response/state-management.md).

# State management

Most of the backend services tend to have some state, which changes as user interact with it. So to be able to simulate this, mock JSON response introduces scenario-based mapping.

#### How to adjust your stub to make it stateful.

Just add scenario and state attributes to the request object in the stub. 

1. scenario (required): this attribute helps to classify the group of stubs together for state management.
2. state (required):  attribute defines the state of the stub.
3. targetState (optional): attribute that defines the next state of the stub 

when the program is initialized, the state of a scenario will always be 'init'.

In State management, MJR will divide the scenario further into stages. During a stage, the response belonging to that stage is mapped. Then how would the state progress? On request like POST, PUT, DELETE, the stage will be changed (with the value of the matched stub's state).

For example:

{% code title="pre\_list.js" %}

```javascript
request: {
        scenario: "shopping list",
        state: "init",
        method: "GET",
        urlPath: "/mock/list",
        headers: {
            "x-route": {
                equalTo: "items-list"
            }
        },
    },
    response: {
        status: 200,
        inlineData: { 
            list: ['Furits','Veggies']
        }
    }
```

{% endcode %}

{% code title="add\_to\_list.js" %}

```javascript
request: {
        scenario: "shopping list",
        state: "init",
        targetState: "state_2",
        method: "POST",
        urlPath: "/mock/list",
        headers: {
            "x-route": {
                equalTo: "items-list"
            }
        },
    },
    response: {
        status: 200,
        inlineData: {
            message: "Item Added"
        }
    }
```

{% endcode %}

{% code title="post\_list.js" %}

```javascript
request: {
        scenario: "shopping list",
        state: "state_2",
        method: "GET",
        urlPath: "/mock/list",
        headers: {
            "x-route": {
                equalTo: "items-list"
            }
        },
    },
    response: {
        status: 200,
        inlineData: { 
            list: ['Furits','Veggies','Bread']
        }
    }
```

{% endcode %}

In the above example, all the 3 stubs are bind via "shopping list" scenario. When a first GET request is called, MJR will scan for the match request and get 2 requests, but selects pre\_list request, since the state value is 'init', which indicates that the stage is initial. When POST request is received it's processed and the stage is set to the targetState of that selected stub. In this case, "state\_2". Now when GET request, post\_list request is selected as presetStage of the stub is "state\_2".

```http
//stage: init
GET http://localhost:3000/mock/list
{ "list": ['Furits','Veggies'] }


//stage: init -> state_2
POST http://localhost:3000/mock/list
{ "message": "Item Added" }


//stage: state_2
GET http://localhost:3000/mock/list
{ list: ['Furits','Veggies','Bread'] }
```

To reset the scenario, one can POST a request to <http://localhost:3000/\\_\\_admin/:scenario\\_name/reset>, setting "add" as scenarion\_name will reset all the scenarios.&#x20;