Skip to content

Commit 9b15c57

Browse files
committed
apply some suggestions from code review
1 parent 527cd1b commit 9b15c57

File tree

2 files changed

+25
-19
lines changed

2 files changed

+25
-19
lines changed

src/pages/cw-storage-plus.md

Lines changed: 16 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -1,11 +1,14 @@
11
# Introduction
22

33
Not being able to persist data across calls would limit the utility of smart
4-
contracts. How could a smart contract
4+
contracts. Think of these problems:
55

6-
- implement a token if it could not keep track of balances,
7-
- implement a voting system if it could not keep track of votes, or
8-
- implement a game if it could not keep track of scores?
6+
- How could a smart contract implement a token if it could not keep track of
7+
balances?
8+
- How could a smart contract implement a voting system if it could not keep
9+
track of votes?
10+
- How could a smart contract implement a game if it could not keep track of
11+
scores?
912

1013
This is why a _CosmWasm_ smart contract has access to the storage facilities
1114
offered by the _Cosmos SDK_. These facilities are essentially a binary key-value
@@ -16,9 +19,9 @@ store, with records stored on-chain.
1619
While developing smart contracts, it's important to remember on-chain storage
1720
is, as always, pricey. Conventionally, developers often draw the line at a
1821
"small logo image" (think a few KBs). If you need to store bigger things, it's
19-
likely time to consider off-chain storage (like IPFS or some centralized storage).
20-
Techniques for securely and reliably storing large data off-chain are beyond the
21-
scope of this document.
22+
likely time to consider off-chain storage (like IPFS or some centralized
23+
storage). Techniques for securely and reliably storing large data off-chain are
24+
beyond the scope of this document.
2225

2326
Trying to minimize bloat is always good practice when it comes to on-chain
2427
storage.
@@ -31,11 +34,12 @@ storing and retrieving data. If you're curious, you can check it out right
3134

3235
This API is raw in that it exposes the **binary** key-value store. While you're
3336
free to use it directly, you're likely to find that finicky and error-prone.
34-
_cw-storage-plus_ is a library that builds on top of this API to
37+
_cw-storage-plus_ is a library that builds on top of this API to do the
38+
following:
3539

36-
- eliminate the need to manually serialize and deserialize data,
37-
- provide a type-safe interface for storing and retrieving data,
38-
- help manage keys, and
39-
- provide featureful persistent data structures.
40+
- eliminate the need to manually serialize and deserialize data
41+
- provide a type-safe interface for storing and retrieving data
42+
- help manage keys
43+
- provide featureful persistent data structures
4044

4145
Let's explore!

src/pages/cw-storage-plus/basics.mdx

Lines changed: 9 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -5,11 +5,11 @@ import { Callout } from "nextra/components";
55
## Containers
66

77
_cw-storage-plus_ provides a number of storage containers that can be used to
8-
store data on the blockchain. The fundamental ones are
8+
store data on the blockchain. The fundamental ones are:
99

10-
- [`Item`](containers/item),
11-
- [`Map`](containers/map),
12-
- [`Deque`](containers/deque).
10+
- [`Item`](containers/item)
11+
- [`Map`](containers/map)
12+
- [`Deque`](containers/deque)
1313

1414
An [`Item`](containers/item) is a simple container that stores a single value.
1515
The other two are a little more involved - they are collections capable of
@@ -20,7 +20,9 @@ storing multiple values, and provide several methods to interact with them.
2020
One task of a storage library like `cw-storage-plus` is to manage the namespace
2121
of keys provided by the blockchain.
2222

23-
When constructing a container, you must provide a key of type `&'static str`.
23+
When constructing a container, you must provide a key of type `&'static str` (or
24+
use
25+
[`new_dyn`](https://docs.rs/cw-storage-plus/latest/cw_storage_plus/struct.Item.html#method.new_dyn)).
2426
This usually means you'll be providing a string literal or some constant.
2527

2628
In the case of an [`Item`](containers/item), the provided key is the exact key
@@ -49,7 +51,7 @@ better advice.
4951
is saved without any sort of length-prefixing of the key. It is, in theory,
5052
possible for an `Item`'s key to conflict with one of the keys generated by a
5153
`Map` or `Deque`. In practice, this is unlikely unless you use very long
52-
prefixes or start your `Item`'s key with the ␀ ASCII character. Probably don't
54+
prefixes or start your `Item`'s key with the null byte. Probably don't
5355
do that!
5456
</Callout>
5557

@@ -78,5 +80,5 @@ storage, you'll have to derive these traits.
7880
[*serde-json-wasm*](https://github.com/CosmWasm/serde-json-wasm) under the
7981
hood. This provides determinism in some corners -
8082
[*serde_json*](https://github.com/serde-rs/json) would not be suited for the
81-
blockchain world!
83+
blockchain world! On top of that, `serde-json-wasm` is just smaller.
8284
</Callout>

0 commit comments

Comments
 (0)