# Actions

### Introduction

Actions build up the API that will shape how to interact with your Conan State.

{% hint style="warning" %}
Actions & Reducers are concepts strongly interlinked with each other, we would strongly recommend to be familiar with the [general concepts](https://docs.conanjs.io/data/conan-state/actions) as for most use cases you **won't** need to create [custom actions](#custom-actions).
{% endhint %}

ConanJs provides automatically with an action for each [reducer](https://docs.conanjs.io/data/conan-state/actions/reducers), and two out of the box actions **update** and **updateAsap** to deal with sync and async updates (explained in further detail later)

Actions are defined when [creating state](https://docs.conanjs.io/data/conan-state/creating-state) via a function that

* Receives a [thread](https://docs.conanjs.io/api/conan-state-classes/thread) to allow you accessing the reducers and other useful resources to describe your actions

{% hint style="info" %}
A Thread is like a Conan State half baked, it has all you need to add additional logic to your actions, like the getData method, the monitor and the reducers already defined. Everything available from a thread is [documented in the API](https://docs.conanjs.io/api/conan-state-classes/thread) 
{% endhint %}

* Returns the actual actions.

Imagine that you want to add an async action in your Conan State using the monitor, this could retrieve an authentication token and then you want to set the property of your state authenticated to the response

{% tabs %}
{% tab title="Js" %}

```javascript
thread => ({
    authenticate(authenticationUrl) {
        return thread.monitor(
            Asaps.fetch (authenticationUrl),
            (response, reducers)=> reducers.$update(current=>({
                ...current,
                authenticated: response.authenticated
            }))
        );
    },
})
```

{% endtab %}
{% endtabs %}

Note that this action is handling async operation with the monitor, which is further explained below.

### The Actions Interface

Following the same principles as to the [reducers interface](https://docs.conanjs.io/data/conan-state/reducers#the-reducers-interface), having the Actions described as a function that takes a thread and returns the actual Actions was also a meditated decision.

The result of this is that you can define a clear business interface that describes the actions that can be performed against your state, so a little bit of boiler plate upfront saves a lot of boilerplate down the line.

You can access all the actions through the 'do' property of your Conan State

```typescript
stockPrices$.do.refresh();
shoppingBasket$.do.addItem(itemToAdd);
```

### Chaining Actions

Another property of an action in ConanJs is that they are chainable, they return an [ASAP](https://docs.conanjs.io/asaps) of the state this action is going to generate.

Note that this is the case no matter if doing async or sync operations  (as long as you use the monitor or other async techniques, like auto-binding)

This helps solving complex logic, for instance

```typescript
stockOrders$.do.increaseBuyingLimitBy(1000).then(newLimit=>
    stockMarket$.do.getPriceFor('AAPL').then (applPrice=>
        stockOrders$.do.tryToBuy ('AAPL', applPrice / newLimit)
    )
);

```

{% hint style="warning" %}
Typescript users should note that they are likely going to have to create two interfaces one for the Reducers and for the Actions.
{% endhint %}

### �The default actions

Each Conan State alway has two actions:

* **update** For sync updated
* **updateAsap** For async updates

**update** is the counter part of the [default reducer](https://docs.conanjs.io/data/conan-state/reducers#default-reducer) $update

**updateAsap** uses a monitor and the default reducer $update to let you update the Conan State async

{% hint style="info" %}
For an example that uses a the default actions, check [Hello Wow!](https://docs.conanjs.io/tutorials/conan-state-demos/hello-wow)
{% endhint %}

### Reducer actions

This are generated automatically by the framework for each reducer, the generated actions will have

* The same name as the reducer but dropping the initial '$'
* Will return an [ASAP](https://docs.conanjs.io/asaps) of the state that this action will generate

{% hint style="info" %}
For an example that uses reducer actions, check [Todos](https://docs.conanjs.io/tutorials/conan-state-demos/todos/todos-sync#creating-the-todos-state)
{% endhint %}

### Auto-bind actions

This is the simplest way to generate [asynchronous](https://docs.conanjs.io/data/conan-state/life-cycle/async-handling) actions, it works by name convention. It will match your provided actions and the already existing reducers following this rules

* It will find you actions which name matches the underlying reducer
* It will assume that the matching provided action returns an ASAP that needs to be resolved for the state to change.
* It will create a monitor on that ASAP and will pass the resulting value to the reducer which this action matches its name into.

{% hint style="info" %}
For an example that uses auto bind, check [Todos - Async](https://docs.conanjs.io/tutorials/conan-state-demos/todos/todos-async#creating-the-state)
{% endhint %}

### Monitor actions

If auto-bind is not an option, you can use a monitor (monitors are further explained in the [async section](https://docs.conanjs.io/data/conan-state/life-cycle/async-handling))

{% hint style="info" %}
For an example that uses monitor actions, check [Github issues viewer](https://docs.conanjs.io/tutorials/conan-state-demos/github-issues-viewer#fetching-the-issues)
{% endhint %}

### Custom actions

You can also create your completely custom actions if none of the previous options work for you.