Sylvia tutorial first message

Author: jawoznia

src/pages/sylvia/macros/generated-types/message-types.mdx

@@ -21,7 +21,7 @@ be called depending on the enum variant. This is described in the example below
 
 The following code:
 
-```rust, template="sylvia-empty"
+```rust template="sylvia-empty"
 #[cw_serde]
 pub struct SomeResponse;
 

src/pages/tutorial/sylvia-contract/_meta.json

@@ -1,3 +1,4 @@
 {
-  "contract-creation": "Contract creation"
+  "contract-creation": "Contract creation",
+  "first-messages": "First messages"
 }

src/pages/tutorial/sylvia-contract/entry-points.mdx

@@ -0,0 +1,80 @@
+# Entry points
+
+Typical Rust application starts with the `fn main()` function called by the operating system. Smart
+contracts are not significantly different. When the message is sent to the contract, a function
+called "entry point" is executed. Unlike native applications, which have only a single `main` entry
+point, smart contracts have a couple of them, each corresponding to different message type:
+`instantiate`, `execute`, `query`, `sudo`, `migrate` and more.
+
+To start, we will go with three basic entry points:
+
+- **`instantiate`** is called once per smart contract lifetime; you can think about it as a
+  constructor or initializer of a contract.
+- **`execute`** for handling messages which can modify contract state; they are used to perform some
+  actual actions.
+- **`query`** for handling messages requesting some information from a contract; unlike
+  **`execute`**, they can never alter any contract state, and are used in a similar manner to
+  database queries.
+
+## Generate entry points
+
+^Sylvia provides an attribute macro named
+[`entry_points`](https://docs.rs/sylvia/latest/sylvia/attr.entry_points.html). In most cases, your
+entry point will just dispatch received messages to the handler, so it's not necessary to manually
+create them, and we can rely on a macro to do that for us.
+
+Let's add the **`entry_points`** attribute macro to our contract:
+
+```rust,noplayground
+use cosmwasm_std::{Response, StdResult};
+use sylvia::types::InstantiateCtx;
+use sylvia::{contract, entry_points};
+
+pub struct CounterContract;
+
+#[entry_points]
+#[contract]
+impl CounterContract {
+    pub const fn new() -> Self {
+        Self
+    }
+
+    #[sv::msg(instantiate)]
+    pub fn instantiate(&self, _ctx: InstantiateCtx) -> StdResult<Response> {
+        Ok(Response::default())
+    }
+}
+```
+
+Note that **`#[entry_points]`** is added above the **`#[contract]`**. It is because
+**`#[contract]`** removes attributes like **`#[sv::msg(...)]`** on which both these macros rely.
+
+Always remember to place **`#[entry_points]`** first.
+
+^Sylvia generates entry points with
+[`#[entry_point]`](https://docs.rs/cosmwasm-std/1.3.1/cosmwasm_std/attr.entry_point.html) attribute
+macro. Its purpose is to wrap the whole entry point to the form the Wasm runtime understands. The
+proper Wasm entry points can use only basic types supported natively by Wasm specification, and Rust
+structures and enums are not in this set. Working with such entry points would be overcomplicated,
+so CosmWasm creators delivered the `entry_point` macro. It creates the raw Wasm entry point, calling
+the decorated function internally and doing all the magic required to build our high-level Rust
+arguments from arguments passed by Wasm runtime.
+
+Now, when our contract has a proper entry point, let's build it and check if it's correctly defined:
+
+```shell
+contract $ cargo build --release --target wasm32-unknown-unknown --lib
+    Finished release [optimized] target(s) in 0.03s
+
+contract $ cosmwasm-check target/wasm32-unknown-unknown/release/contract.wasm
+Available capabilities: {"stargate", "cosmwasm_1_3", "cosmwasm_1_1", "cosmwasm_1_2", "staking", "iterator"}
+
+target/wasm32-unknown-unknown/release/contract.wasm: pass
+
+All contracts (1) passed checks!
+```
+
+## Next step
+
+Well done! We have now a proper `CosmWasm` contract. Let's add some state to it, so it will actually
+be able to do something.

src/pages/tutorial/sylvia-contract/first-messages.mdx

@@ -0,0 +1,88 @@
+# Generating first messages
+
+We have set up our dependencies. Now let's use them to create simple messages.
+
+## Creating an instantiation message
+
+For this step we will create a new file:
+
+- `src/contract.rs` - here, we will define our messages and behavior of the contract upon receiving
+  them
+
+Add this module to `src/lib.rs`. You want it to be public, as users might want to get access to
+types stored inside your contract.
+
+```rust copy filename="src/lib.rs"
+pub mod contract;
+```
+
+Now let's create an `instantiate` method for our contract. In `src/contract.rs`
+
+```rust copy filename="src/contract.rs" template="sylvia/empty"
+use sylvia::cw_std::{Response, StdResult};
+use sylvia::contract;
+use sylvia::ctx::InstantiateCtx;
+
+pub struct CounterContract;
+
+#[contract]
+impl CounterContract {
+    pub const fn new() -> Self {
+        Self
+    }
+
+    #[sv::msg(instantiate)]
+    pub fn instantiate(&self, _ctx: InstantiateCtx) -> StdResult<Response> {
+        Ok(Response::default())
+    }
+}
+```
+
+So what is going on here? First, we define the `CounterContract` struct. It is empty right now but
+later when we learn about states, we will use its fields to store them. We mark the `impl` block
+with [`contract`](../../sylvia/macros/contract) attribute macro. It will parse every method inside
+the `impl` block marked with the [`sv::msg(...)`](../../sylvia/macros/attributes/msg) attribute and
+create proper messages and utilities like
+[MultiTest helpers](../../sylvia/macros/generated-types/multitest) for them. More on them later.
+
+CosmWasm contract requires only the [instantiate](../../core/entrypoints/instantiate) entry point,
+and it is mandatory to specify it for the [`contract`](../../sylvia/macros/contract) macro. We have
+to provide it with the proper context type
+[`InstantiateCtx`](https://docs.rs/sylvia/latest/sylvia/ctx/struct.InstantiateCtx.html).
+
+Context gives us access to the blockchain state, information about our contract, and the sender of
+the message. We return the
+[`StdResult`](https://docs.rs/cosmwasm-std/latest/cosmwasm_std/type.StdResult.html) which uses
+standard CosmWasm error
+[`StdError`](https://docs.rs/cosmwasm-std/latest/cosmwasm_std/enum.StdError.html). It's generic over
+[`Response`](https://docs.rs/cosmwasm-std/latest/cosmwasm_std/struct.Response.html). For now, we
+will return the `default` value of it.
+
+I recommend expanding the macro now and seeing what Sylvia generates. It might be overwhelming, as
+there will be a lot of things generated that seem not relevant to our code, so for the bare minimum
+check the [`InstantiateMsg`](../../sylvia/macros/generated-types/message-types#contract-messages)
+and its `impl` block.
+
+## Next step
+
+If we build our contract with command:
+
+```shell copy filename="TERMINAL"
+cargo build --release --target wasm32-unknown-unknown --lib
+```
+
+and then run:
+
+```shell copy filename="TERMINAL"
+cosmwasm-check target/wasm32-unknown-unknown/release/contract.wasm
+```
+
+The output should look like this:
+
+```shell filename="TERMINAL"
+Available capabilities: {"stargate", "staking", "cosmwasm_1_3", "cosmwasm_2_0", "cosmwasm_1_1", "cosmwasm_1_2", "cosmwasm_1_4", "iterator"}
+
+target/wasm32-unknown-unknown/release/contract.wasm: pass
+
+All contracts (1) passed checks!
+```