GitBook: [master] 44 pages and one asset modified

Author: christianalfoni

.gitbook/assets/image (1) (1) (1).png

@@ -8,7 +8,7 @@ This data structure is called **the configuration** of your application. If it i
 
 ## Namspaces
 
-![](../.gitbook/assets/image%20%281%29.png)
+![](../.gitbook/assets/image%20%281%29%20%281%29.png)
 
 As your application grows you start to separate it into different namespaces. A namespace might be closely related to a page in your application, or maybe it is strictly related to managing some piece of data. It does not matter. You define the namespaces of your application and they probably change over time as well. What matters in the context of Overmind though is that each of these namespaces will contain their own state, actions and effects. So imagine a file structure of:
 

core/structuring-the-app.md

@@ -331,7 +331,7 @@ Our todo has been added and we can even see how the derived state was affected b
 
 ## Managing complexity
 
-![](.gitbook/assets/image%20%281%29.png)
+![](.gitbook/assets/image%20%281%29%20%281%29.png)
 
 Overmind gives you a basic foundation with its **state**, **actions** and **effects**. As mentioned previously you can split these up into multiple namespaces to organize your code. This manages the complexity of scaling. There is also a complexity of reusability and managing execution over time. The **operators** API allows you to split your logic into many different composable parts. With operators like **debounce**, **waitUntil** etc. you are able to manage execution over time. With the latest addition of **statemachines** you have the possiblity to manage the complexity of state and interaction. What interactions should be allowed in what states. And with state values as **class instances** you are able to co-locate state with logic.