|
| 1 | +# Entrypoints |
| 2 | + |
| 3 | +Entrypoints are where your contract can be called from the outside world. You can equate that to |
| 4 | +your `main` function in C, Rust, Java, etc. However, there is one _small_ difference: in CosmWasm, |
| 5 | +you have multiple of these entrypoints, each one different from the last. |
| 6 | + |
| 7 | +In this section we want to give you a quick overview of all the entrypoints and when they are |
| 8 | +called. |
| 9 | + |
| 10 | +::: tip :bulb: Tip |
| 11 | +In our examples, we will always refer to `StdResult` as the return type (and therefore `StdError` as the error type). |
| 12 | +This is just for convenience since every type that implements the `ToString` type can be used as an error type! |
| 13 | +Meaning, as long as it implements `ToString`, nothing is stopping you from defining `Result<Response, MyError>`. |
| 14 | +This can reduce your code complexity, especially if you want to use the try operator. |
| 15 | +::: |
| 16 | + |
| 17 | +## Defining entrypoints |
| 18 | + |
| 19 | +While you will learn all about entrypoints in the next sections, we want to give you an idea on how |
| 20 | +to define an entrypoint in the first place. |
| 21 | + |
| 22 | +CosmWasm defines the handy `#[entry_point]` attribute macro. You simply annotate a function with it, |
| 23 | +and it automatically generates code that communicates to the VM: "Hey! This is an entrypoint, please |
| 24 | +use it when needed!" |
| 25 | + |
| 26 | +::: tip :bulb: Tip |
| 27 | +When defining an entrypoint, it is important to use the correct types for the parameters and |
| 28 | +return type. Incorrect types will cause errors when trying to call the contract. |
| 29 | + |
| 30 | +In the following sections we will take a look at all possible entrypoints, including the |
| 31 | +correct function signature. |
| 32 | +::: |
| 33 | + |
| 34 | +::: tip :bulb: Tip |
| 35 | +Even though the sections will show you to use `#[entry_point]`, it is recommended to define your |
| 36 | +endpoints as `#[cfg_attr(not(feature = "library"), entry_point)]`. |
| 37 | + |
| 38 | +The reason behind that is that it allows you to reuse your contract as a library. |
| 39 | +::: |
| 40 | + |
| 41 | +```Rust |
| 42 | +#[cfg_attr(not(feature = "library"), entry_point)] |
| 43 | +pub fn instantiate( |
| 44 | + deps: DepsMut, |
| 45 | + env: Env, |
| 46 | + info: MessageInfo, |
| 47 | + msg: InstantiateMsg, |
| 48 | +) -> StdResult<Response> { |
| 49 | + // Do some logic here |
| 50 | + Ok(Response::default()) |
| 51 | +} |
| 52 | +``` |
| 53 | + |
| 54 | +## Entrypoint parameters |
| 55 | + |
| 56 | +Entrypoints have a few parameters (as you can see above), some of them are predefined by |
| 57 | +`cosmwasm-std`, others are defined by the user themselves. |
| 58 | + |
| 59 | +Here we go over the different predefined types the standard library provides, and how you can define |
| 60 | +your own types. |
| 61 | + |
| 62 | +### Predefined types |
| 63 | + |
| 64 | +#### `Deps`/`DepsMut` |
| 65 | + |
| 66 | +These structs provide you access to the: |
| 67 | + |
| 68 | +- Storage |
| 69 | +- VM API |
| 70 | +- Querier |
| 71 | + |
| 72 | +The big difference is that `DepsMut` gives you _mutable_ access to the storage. This design is |
| 73 | +deliberate since you, for example, can't mutate the state in the `query` endpoint. Instead of |
| 74 | +relying on runtime errors, this is made _irrepresentable_ through Rust's type system. |
| 75 | + |
| 76 | +#### `Env` |
| 77 | + |
| 78 | +This struct provides you with some information of the current state of the environment your contract |
| 79 | +is executed in. |
| 80 | + |
| 81 | +The information provided is, for example, the block height, chain ID, transaction info, etc. |
| 82 | +Basically anything you'd ever want to know about the current state of the execution environment! |
| 83 | + |
| 84 | +#### `MessageInfo` |
| 85 | + |
| 86 | +This struct isn't provided to every endpoint, only to a select few. |
| 87 | + |
| 88 | +It provides you with some information that might be crucial to you, depending on the operation you |
| 89 | +want to perform. It contains the sender of the message you just received, and the funds that were |
| 90 | +transferred along with it to your contract. |
| 91 | + |
| 92 | +### Defining your own messages |
| 93 | + |
| 94 | +In our examples, you might have seen messages such as `InstantiateMsg`. These messages are actually |
| 95 | +_user-defined_, meaning each contract developer has to define them themselves. |
| 96 | + |
| 97 | +To make this easier our `cosmwasm-schema` crate provides the `cw_serde` attribute macro, to define |
| 98 | +an instantiate message, you simply write this: |
| 99 | + |
| 100 | +::: code-group |
| 101 | +```Rust [instantiate.rs] |
| 102 | +#[cw_serde] |
| 103 | +struct CustomInstantiateMsg { |
| 104 | + initial_admins: Vec<Addr>, |
| 105 | +} |
| 106 | +``` |
| 107 | +::: |
| 108 | + |
| 109 | +::: tip :bulb: Tip |
| 110 | +This macro actually just expands into a bunch of `derive` attributes. |
| 111 | +We provide this simply for your convenience, otherwise you'd have to keep track of all of these derives yourself. |
| 112 | + |
| 113 | +::: details Without `#[cw_serde]` |
| 114 | + |
| 115 | +::: code-group |
| 116 | +```Rust [instantiate.rs] |
| 117 | +#[derive( |
| 118 | + serde::Serialize, |
| 119 | + serde::Deserialize, |
| 120 | + Clone, |
| 121 | + Debug, |
| 122 | + PartialEq, |
| 123 | + schemars::JsonSchema |
| 124 | +)] |
| 125 | +struct CustomInstantiateMsg { |
| 126 | + initial_admins: Vec<Addr>, |
| 127 | +} |
| 128 | +``` |
| 129 | + |
| 130 | +::: |
0 commit comments