diff options
| author | Alex Houseago <41902631+ahouseago@users.noreply.github.com> | 2024-03-18 22:05:29 +0000 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2024-03-18 22:05:29 +0000 |
| commit | 19a6bab853c5360d7a114eada66467967e1f9997 (patch) | |
| tree | fda5f902aaeac60446e0258bc65e575377ee6455 | |
| parent | e0b63ce3f04709fa8f37ace60c849852b29a281d (diff) | |
| download | lustre-19a6bab853c5360d7a114eada66467967e1f9997.tar.gz lustre-19a6bab853c5360d7a114eada66467967e1f9997.zip | |
🔀 Fix a few typos in state management guide. (#66)
| -rw-r--r-- | pages/guide/02-state-management.md | 8 |
1 files changed, 4 insertions, 4 deletions
diff --git a/pages/guide/02-state-management.md b/pages/guide/02-state-management.md index 2c9b641..a5d1bf5 100644 --- a/pages/guide/02-state-management.md +++ b/pages/guide/02-state-management.md @@ -61,7 +61,7 @@ to get used to, but it brings a number of benefits: - State updates are **pure**. We will learn more about this in the [next guide](./03-side-effects), but for now it is enough to know that this means testing your state changes is - much easier because mocking messages is simpler tham mocking side effects! + much easier because mocking messages is simpler than mocking side effects! The rest of this guide contains some learned-wisdom and best practices for managing state in Lustre applications. @@ -89,8 +89,8 @@ type PublicModel { } ``` -Here, we a model that represents our application as either having a logged in user -or just one of the public routes. This pushes us towards the great practice of +Here, we have a model that represents our application as either having a logged in +user or just one of the public routes. This pushes us towards the great practice of [making impossible states impossible](https://github.com/stereobooster/pragmatic-types/blob/master/posts/making-impossible-states-impossible.md). Now, we can write separate update and view functions that only handle the states they care about. @@ -182,7 +182,7 @@ there are some tangible benefits to this approach: Imagine you have a table component with tabs to switch between different views. If some time in the future you decide to pull the tabs out so they can be rendered elsewhere on the page you'll discover that the tabs' state was tightly - couple to the table. Now we are forced to refactore the table component so the + couple to the table. Now we are forced to refactor the table component so the tab state can be passed in as an attribute. We'll also need to refactor the _parent_ to contain the state of the tabs so it can be passed down to both components. |