From 76b11c0c1d15ee1147aba0eb16367330a14aa2cc Mon Sep 17 00:00:00 2001 From: Hack666r Date: Mon, 3 Feb 2025 21:08:12 +0100 Subject: [PATCH] Fix typos in docs/learn/tutorials/storage/storage.md --- docs/learn/tutorials/storage/storage.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/learn/tutorials/storage/storage.md b/docs/learn/tutorials/storage/storage.md index dbe2b53..7bbc6b3 100644 --- a/docs/learn/tutorials/storage/storage.md +++ b/docs/learn/tutorials/storage/storage.md @@ -177,7 +177,7 @@ Storage data is always encoded with the `[SCALE](https://docs.substrate.io/refe ### Packed vs Non-Packed layout -Types that can be stored entirely under a single storage cell are considered `[Packed](https://docs.rs/ink_storage_traits/4.0.0/ink_storage_traits/trait.Packed.html)`. By default, ink! tries to store all storage struct fields under a single storage cell. Consequentially, with a `Packed` storage layout, any message interacting with the contract storage will always need to operate on the entire contract storage structure. +Types that can be stored entirely under a single storage cell are considered `[Packed](https://docs.rs/ink_storage_traits/4.0.0/ink_storage_traits/trait.Packed.html)`. By default, ink! tries to store all storage struct fields under a single storage cell. Consequently, with a `Packed` storage layout, any message interacting with the contract storage will always need to operate on the entire contract storage structure. If we have a few tiny fields in storage it’s not a problem to load all of them in every message, but if we have a large field with `Packed` type and if it’s not used in every message, it’s not rational to load this field every time.