# Log Actions

When building a decentralized application, it's important to remember that it is possible (and ideal) for other developers to want to build on top of it.

Many times, this will require being able to track certain data on front end websites. You will want to have this data available for yourself as well.

While many datapoints can be stored in tables, sometimes it's useful to track certain actions via reading transactions from a state history (SHIP) node.

Let me show you a simple example of what I mean.

```cpp
ACTION mycontract::stake( const name& user, const asset& amount ){
    require_auth( user );
    // perform some calculations and determine the user's new balance
    // update the user's table row here
}
```

When a `stake` transaction is submitted to your contract, off-chain APIs can see this transaction, and see the `user` and `amount` that were passed to the action.

However, they will not necessarily see the outcomes of any calculations that took place, unless they are tracking table deltas directly, which is a bit more complex.

This makes it difficult for people to build APIs around your application, therefore making it difficult for people to create products that are built on top of your contract.

A great solution to this is using a `log` action, like this.

```cpp
inline eosio::permission_level mycontract::active_perm(){
    return eosio::permission_level{ _self, "active"_n };
}

ACTION mycontract::logstake( const name& user, const asset& amount, const asset& new_staked_balance){
    require_auth( _self );
}

ACTION mycontract::stake( const name& user, const name& amount ){
    require_auth( user );
    // perform some calculations and determine the user's new balance
    // update the user's table row here
    
    // log the action so SHIP readers have all the info they need
    action( active_perm(), _self, "logstake"_n, std::tuple{ user, amount, new_balance } ).send();
}
```

Now, people trying to build APIs can have a much easier time without having to either cross-reference against previous records, or look at table deltas to track changes. They can simply look for the `logstake` action, instead of the `stake` action. `logstake` has all the info they need.
