GitBook: [master] 29 pages modified

Author: jstarry

src/README.md

@@ -40,10 +40,10 @@ Rust also helps developers write safer code with its rich type system and owners
 
 #### Alternatives?
 
-We love to share ideas with other projects and believe we can all help each other reach the full potential of this exciting new technology. If you're not into Yew, you may like the following projects \(listed alphabetically\)
+We love to share ideas with other projects and believe we can all help each other reach the full potential of this exciting new technology. If you're not into Yew, you may like the following projects:
 
-* [Draco](https://github.com/utkarshkukreti/draco) - _"A Rust library for building client side web applications with Web Assembly"_
 * [Percy](https://github.com/chinedufn/percy) - _"A modular toolkit for building isomorphic web apps with Rust + WebAssembly"_
 * [Seed](https://github.com/seed-rs/seed) - _"A Rust framework for creating web apps"_
-* [Smithy](https://github.com/rbalicki2/smithy) - _"A framework for building WebAssembly apps in Rust"_
+
+
 

src/advanced-topics/optimizations.md

@@ -6,13 +6,9 @@ description: Make your app faster
 
 ## neq\_assign
 
-When a component receives props from its parent component, the `change` method is called. This, in 
-addition to allowing you to update the component's state, also allows you to return a `ShouldRender` 
-boolean value that indicates if the component should re-render itself in response to the prop changes.
+When a component receives props from its parent component, the `change` method is called. This, in addition to allowing you to update the component's state, also allows you to return a `ShouldRender` boolean value that indicates if the component should re-render itself in response to the prop changes.
 
-Re-rendering is expensive, and if you can avoid it, you should. As a general rule, you only want to 
-re-render when the props actually changed. The following block of code represents this rule, 
-returning `true` if the props differed from the previous props:
+Re-rendering is expensive, and if you can avoid it, you should. As a general rule, you only want to re-render when the props actually changed. The following block of code represents this rule, returning `true` if the props differed from the previous props:
 
 ```rust
 use yew::ShouldRender;
@@ -36,68 +32,37 @@ impl Example {
 }
 ```
 
-But we can go further! This is six lines of boilerplate can be reduced down to one by using a trait 
-and a blanket implementation for anything that implements `PartialEq`. Check out the `yewtil` crate's
-`NeqAssign` trait [here](https://docs.rs/yewtil/*/yewtil/trait.NeqAssign.html).
+But we can go further! This is six lines of boilerplate can be reduced down to one by using a trait and a blanket implementation for anything that implements `PartialEq`. Check out the `yewtil` crate's `NeqAssign` trait [here](https://docs.rs/yewtil/*/yewtil/trait.NeqAssign.html).
 
 ## RC
 
-In an effort to avoid cloning large chunks of data to create props when re-rendering, we can use 
-smart pointers to only clone the pointer instead. If you use `Rc<_>`s in your props and child 
-components instead of plain unboxed values, you can delay cloning until you need to modify the data 
-in the child component, where you use `Rc::make_mut` to clone and get a mutable reference to the data
-you want to alter. By not cloning until mutation, child components can reject props identical to 
-their state-owned props in `Component::change` for almost no performance cost, versus the case where 
-the data itself needs to be copied into the props struct in the parent before it is compared and 
-rejected in the child.
+In an effort to avoid cloning large chunks of data to create props when re-rendering, we can use smart pointers to only clone the pointer instead. If you use `Rc<_>`s in your props and child components instead of plain unboxed values, you can delay cloning until you need to modify the data in the child component, where you use `Rc::make_mut` to clone and get a mutable reference to the data you want to alter. By not cloning until mutation, child components can reject props identical to their state-owned props in `Component::change` for almost no performance cost, versus the case where the data itself needs to be copied into the props struct in the parent before it is compared and rejected in the child.
 
-This optimization is most useful for data types that aren't `Copy`. If you can copy your data easily,
-then it probably isn't worth putting it behind a smart pointer. For structures that can contain lots 
-of data like `Vec`, `HashMap`, and `String`, this optimization should be worthwhile.
+This optimization is most useful for data types that aren't `Copy`. If you can copy your data easily, then it probably isn't worth putting it behind a smart pointer. For structures that can contain lots of data like `Vec`, `HashMap`, and `String`, this optimization should be worthwhile.
 
-This optimization works best if the values are never updated by the children, and even better, if 
-they are rarely updated by parents. This makes `Rc<_>s` a good choice for wrapping property values in
-for pure components.
+This optimization works best if the values are never updated by the children, and even better, if they are rarely updated by parents. This makes `Rc<_>s` a good choice for wrapping property values in for pure components.
 
 ## View Functions
 
-For code readability reasons, it often makes sense to migrate sections of `html!` to their own 
-functions so you can avoid the rightward drift present in deeply nested HTML.
+For code readability reasons, it often makes sense to migrate sections of `html!` to their own functions so you can avoid the rightward drift present in deeply nested HTML.
 
 ## Pure Components/Function Components
 
-Pure components are components that don't mutate their state, only displaying content and propagating
-messages up to normal, mutable components. They differ from view functions in that they can be used 
-from within the `html!` macro using the component syntax \(`<SomePureComponent />`\) instead of 
-expression syntax \(`{some_view_function()}`\), and that depending on their implementation, they can 
-be memoized - preventing re-renders for identical props using the aforementioned `neq_assign` logic.
+Pure components are components that don't mutate their state, only displaying content and propagating messages up to normal, mutable components. They differ from view functions in that they can be used from within the `html!` macro using the component syntax \(`<SomePureComponent />`\) instead of expression syntax \(`{some_view_function()}`\), and that depending on their implementation, they can be memoized - preventing re-renders for identical props using the aforementioned `neq_assign` logic.
 
 Yew doesn't natively support pure or function components, but they are available via external crates.
 
-Function components don't exist yet, but in theory, pure components could be generated by using proc 
-macros and annotating functions.
+Function components don't exist yet, but in theory, pure components could be generated by using proc macros and annotating functions.
 
 ## Keyed DOM nodes when they arrive
 
 ## Compile speed optimizations using Cargo Workspaces
 
-Arguably, the largest drawback to using Yew is the long time it takes to compile. Compile time seems
-to correlate with the quantity of code found within `html!` macro blocks. This tends to not be a 
-significant problem for smaller projects, but for web apps that span multiple pages, it makes sense 
-to break apart your code across multiple crates to minimize the amount of work the compiler has to do
-for each change made.
+Arguably, the largest drawback to using Yew is the long time it takes to compile. Compile time seems to correlate with the quantity of code found within `html!` macro blocks. This tends to not be a significant problem for smaller projects, but for web apps that span multiple pages, it makes sense to break apart your code across multiple crates to minimize the amount of work the compiler has to do for each change made.
 
-You should try to make your main crate handle routing/page selection, move all commonly shared code 
-to another crate, and then make a different crate for each page, where each page could be a different
-component, or just a big function that produces `Html`. In the best case scenario, you go from 
-rebuilding all of your code on each compile to rebuilding only the main crate, and one of your page 
-crates. In the worst case, where you edit something in the "common" crate, you will be right back to 
-where you started: compiling all code that depends on that commonly shared crate, which is 
-probably everything else.
+You should try to make your main crate handle routing/page selection, move all commonly shared code to another crate, and then make a different crate for each page, where each page could be a different component, or just a big function that produces `Html`. In the best case scenario, you go from rebuilding all of your code on each compile to rebuilding only the main crate, and one of your page crates. In the worst case, where you edit something in the "common" crate, you will be right back to where you started: compiling all code that depends on that commonly shared crate, which is probably everything else.
 
-If your main crate is too heavyweight, or you want to rapidly iterate on a deeply nested page \(eg. a
-page that renders on top of another page\), you can use an example crate to create a more simple 
-implementation of the main page and render your work-in-progress component on top of that.
+If your main crate is too heavyweight, or you want to rapidly iterate on a deeply nested page \(eg. a page that renders on top of another page\), you can use an example crate to create a more simple implementation of the main page and render your work-in-progress component on top of that.
 
 ## Build size optimization
 
@@ -106,19 +71,13 @@ implementation of the main page and render your work-in-progress component on to
   * `cargo.toml` \( defining release profile \)
 * optimize wasm code using `wasm-opt`
 
-More information about code size profiling: 
-[rustwasm book](https://rustwasm.github.io/book/reference/code-size.html#optimizing-builds-for-code-size)
+More information about code size profiling: [rustwasm book](https://rustwasm.github.io/book/reference/code-size.html#optimizing-builds-for-code-size)
 
 ### wee\_alloc
 
-[wee\_alloc](https://github.com/rustwasm/wee_alloc) is a tiny allocator that is much smaller than the
-allocator that is normally used in Rust binaries. Replacing the default allocator with this one will 
-result in smaller WASM file sizes, at the expense of speed and memory overhead.
+[wee\_alloc](https://github.com/rustwasm/wee_alloc) is a tiny allocator that is much smaller than the allocator that is normally used in Rust binaries. Replacing the default allocator with this one will result in smaller WASM file sizes, at the expense of speed and memory overhead.
 
-The slower speed and memory overhead are minor in comparison to the size gains made by not including
-the default allocator. This smaller file size means that your page will load faster, and so it is 
-generally recommended that you use this allocator over the default, unless your app is doing some 
-allocation-heavy work.
+The slower speed and memory overhead are minor in comparison to the size gains made by not including the default allocator. This smaller file size means that your page will load faster, and so it is generally recommended that you use this allocator over the default, unless your app is doing some allocation-heavy work.
 
 ```rust
 // Use `wee_alloc` as the global allocator.
@@ -152,8 +111,7 @@ Further more it is possible to optimize size of `wasm` code.
 
 wasm-opt info: [binaryen project](https://github.com/WebAssembly/binaryen)
 
-The Rust Wasm book features a section about reducing the size of WASM binaries: 
-[Shrinking .wasm size](https://rustwasm.github.io/book/game-of-life/code-size.html)
+The Rust Wasm book features a section about reducing the size of WASM binaries: [Shrinking .wasm size](https://rustwasm.github.io/book/game-of-life/code-size.html)
 
 * using `wasm-pack` which by default optimizes `wasm` code in release builds
 * using `wasm-opt` directly on `wasm` files.
@@ -164,8 +122,7 @@ wasm-opt wasm_bg.wasm -Os -o wasm_bg_opt.wasm
 
 #### Build size of 'minimal' example in yew/examples/
 
-Note: `wasm-pack` combines optimization for Rust and Wasm code. `wasm-bindgen` is used in this 
-example without any Rust size optimization.
+Note: `wasm-pack` combines optimization for Rust and Wasm code. `wasm-bindgen` is used in this example without any Rust size optimization.
 
 | used tool | size |
 | :--- | :--- |

src/concepts/agents.md

@@ -4,16 +4,9 @@ description: Yew's Actor System
 
 # Agents
 
-Agents are similar to Angular's [Services](https://angular.io/guide/architecture-services) \(but 
-without dependency injection\), and provide a Yew with an 
-[Actor Model](https://en.wikipedia.org/wiki/Actor_model). Agents can be used to route messages 
-between components independently of where they sit in the component hierarchy, or they can be used to 
-create a shared state, and they can also be used to offload computationally expensive tasks from the 
-main thread which renders the UI. There is also planned support for using agents to allow Yew 
-applications to communicate across tabs \(in the future\).
+Agents are similar to Angular's [Services](https://angular.io/guide/architecture-services) \(but without dependency injection\), and provide a Yew with an [Actor Model](https://en.wikipedia.org/wiki/Actor_model). Agents can be used to route messages between components independently of where they sit in the component hierarchy, or they can be used to create a shared state, and they can also be used to offload computationally expensive tasks from the main thread which renders the UI. There is also planned support for using agents to allow Yew applications to communicate across tabs \(in the future\).
 
-In order for agents to run concurrently, Yew uses 
-[web-workers](https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers).
+In order for agents to run concurrently, Yew uses [web-workers](https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers).
 
 ## Lifecycle
 
@@ -24,12 +17,19 @@ In order for agents to run concurrently, Yew uses
 #### Reaches
 
 * Context - There will exist at most one instance of a Context Agent at any given time. Bridges will 
-spawn or connect to an already spawned agent on the UI thread. This can be used to coordinate state 
-between components or other agents. When no bridges are connected to this agent, the agent will 
-disappear.
+
+  spawn or connect to an already spawned agent on the UI thread. This can be used to coordinate state 
+
+  between components or other agents. When no bridges are connected to this agent, the agent will 
+
+  disappear.
+
 * Job - Spawn a new agent on the UI thread for every new bridge. This is good for moving shared but 
-independent behavior that communicates with the browser out of components. \(TODO verify\) When the 
-task is done, the agent will disappear.
+
+  independent behavior that communicates with the browser out of components. \(TODO verify\) When the 
+
+  task is done, the agent will disappear.
+
 * Public - Same as Context, but runs on its own web worker.
 * Private - Same as Job, but runs on its own web worker.
 * Global \(WIP\)
@@ -38,24 +38,19 @@ task is done, the agent will disappear.
 
 ### Bridges
 
-A bridge allows bi-directional communication between an agent and a component. Bridges also allow 
-agents to communicate with one another.
+A bridge allows bi-directional communication between an agent and a component. Bridges also allow agents to communicate with one another.
 
 ### Dispatchers
 
-A dispatcher allows uni-directional communication between a component and an agent. A dispatcher 
-allows a component to send messages to an agent.
+A dispatcher allows uni-directional communication between a component and an agent. A dispatcher allows a component to send messages to an agent.
 
 ## Overhead
 
-Agents that live in their own separate web worker (Private and Public) incur serialization overhead 
-on the messages they send and receive. They use [bincode](https://github.com/servo/bincode) to 
-communicate with other threads, so the cost is substantially higher than just calling a function. 
-Unless the cost of computation will outweigh the cost of message passing, you should contain your 
-logic in the UI thread agents (Job or Context).
+Agents that live in their own separate web worker \(Private and Public\) incur serialization overhead on the messages they send and receive. They use [bincode](https://github.com/servo/bincode) to communicate with other threads, so the cost is substantially higher than just calling a function. Unless the cost of computation will outweigh the cost of message passing, you should contain your logic in the UI thread agents \(Job or Context\).
 
 ## Further reading
 
 * The [pub\_sub](https://github.com/yewstack/yew/tree/master/examples/pub_sub) example shows how 
-components can use agents to communicate with each other.
+
+  components can use agents to communicate with each other.