From e57c0890ec31312f207db60da9fdbbf1b6855e77 Mon Sep 17 00:00:00 2001 From: Kris Warner Date: Fri, 25 Mar 2022 22:26:42 -0400 Subject: [PATCH 1/6] Delete redundant sentence --- docs/guide/src/interactivity/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/guide/src/interactivity/index.md b/docs/guide/src/interactivity/index.md index b6b9abc88..50f26e545 100644 --- a/docs/guide/src/interactivity/index.md +++ b/docs/guide/src/interactivity/index.md @@ -157,7 +157,7 @@ fn App(cx: Scope)-> Element { } ``` -Using asynchronous code can be difficult! This is just scratching the surface of what's possible. We have an entire chapter on using async properly in your Dioxus Apps. We have an entire section dedicated to using `async` properly later in this book. +Using asynchronous code can be difficult! This is just scratching the surface of what's possible. We have an entire chapter on using async properly in your Dioxus Apps. ### How do I tell Dioxus that my state changed? From 2ffd90c98bdffabdf195d97526eed6df25862e6c Mon Sep 17 00:00:00 2001 From: Kris Warner Date: Fri, 25 Mar 2022 22:32:33 -0400 Subject: [PATCH 2/6] Remove bullets from numbered list --- docs/guide/src/interactivity/index.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/guide/src/interactivity/index.md b/docs/guide/src/interactivity/index.md index 50f26e545..02c39b5b1 100644 --- a/docs/guide/src/interactivity/index.md +++ b/docs/guide/src/interactivity/index.md @@ -173,9 +173,9 @@ With these building blocks, we can craft new hooks similar to `use_state` that l In general, Dioxus should be plenty fast for most use cases. However, there are some rules you should consider following to ensure your apps are quick. -- 1) **Don't call set_state _while rendering_**. This will cause Dioxus to unnecessarily re-check the component for updates or enter an infinite loop. -- 2) **Break your state apart into smaller sections.** Hooks are explicitly designed to "unshackle" your state from the typical model-view-controller paradigm, making it easy to reuse useful bits of code with a single function. -- 3) **Move local state down**. Dioxus will need to re-check child components of your app if the root component is constantly being updated. You'll get best results if rapidly-changing state does not cause major re-renders. +1) **Don't call set_state _while rendering_**. This will cause Dioxus to unnecessarily re-check the component for updates or enter an infinite loop. +2) **Break your state apart into smaller sections.** Hooks are explicitly designed to "unshackle" your state from the typical model-view-controller paradigm, making it easy to reuse useful bits of code with a single function. +3) **Move local state down**. Dioxus will need to re-check child components of your app if the root component is constantly being updated. You'll get best results if rapidly-changing state does not cause major re-renders. - event handlers as string attributes - `value`, `checked`, and `selected` @@ -31,7 +30,7 @@ fn BlogPost(cx: Scope) -> Element { ``` > Note! This attribute is called "dangerous_inner_html" because it is **dangerous** to pass it data you don't trust. If you're not careful, you can easily expose cross-site-scripting (XSS) attacks to your users. -> +> > If you're handling untrusted input, make sure to sanitize your HTML before passing it into `dangerous_inner_html` – or just pass it to a Text Element to escape any HTML tags. @@ -49,9 +48,9 @@ rsx!{ } } ``` -wouldn't actually render the `hidden` attribute: +wouldn't actually render the `hidden` attribute: ```html -
hello
+
hello
``` Not all attributes work like this however. *Only the following attributes* have this behavior: @@ -87,9 +86,9 @@ For any other attributes, a value of `"false"` will be sent directly to the DOM. ## Stopping form input and navigation with `prevent_default` -Currently, calling `prevent_default` on events in EventHandlers is not possible from Desktop/Mobile. Until this is supported, it's possible to prevent default using the `prevent_default` attribute. +Currently, calling `prevent_default` on events in EventHandlers is not possible from Desktop/Mobile. Until this is supported, it's possible to prevent default using the `prevent_default` attribute. -> Note: you cannot conditionally prevent default with this approach. This is a limitation until synchronous event handling is available across the Webview boundary +> Note: you cannot conditionally prevent default with this approach. This is a limitation until synchronous event handling is available across the Webview boundary To use `prevent_default`, simply attach the `prevent_default` attribute to a given element and set it to the name of the event handler you want to prevent default on. We can attach this attribute multiple times for multiple attributes. @@ -104,7 +103,7 @@ rsx!{ } } ``` - diff --git a/docs/guide/src/elements/vnodes.md b/docs/guide/src/elements/vnodes.md index 95b979c7c..5312306f0 100644 --- a/docs/guide/src/elements/vnodes.md +++ b/docs/guide/src/elements/vnodes.md @@ -8,6 +8,7 @@ In this chapter, we'll cover: - Element properties ## Declaring our first Element + Because Dioxus is mostly used with HTML/CSS renderers, the default Element "collection" is HTML. Provided the `html` feature is not disabled, we can declare Elements using the `rsx!` macro: ```rust @@ -29,6 +30,7 @@ Produces: ``` We can construct any valid HTML tag with the `tag {}` pattern and expect the resulting HTML structure to resemble our declaration. + ## Composing Elements Of course, we need more complex structures to make our apps actually useful! Just like HTML, the `rsx!` macro lets us nest Elements inside of each other. @@ -150,7 +152,7 @@ All element attributes must occur *before* child elements. The `rsx!` macro will Listeners are a special type of Attribute that only accept functions. Listeners let us attach functionality to our Elements by running a provided closure whenever the specified Listener is triggered. -We'll cover listeners in more depth in the Adding Interactivity chapter, but for now, just know that every listener must start with the `on` keyword and accepts closures. +We'll cover listeners in more depth in the Adding Interactivity chapter, but for now, just know that every listener starts with "on" and accepts closures. ```rust rsx!( diff --git a/docs/guide/src/hello_world.md b/docs/guide/src/hello_world.md index 6bcc77e30..d01122959 100644 --- a/docs/guide/src/hello_world.md +++ b/docs/guide/src/hello_world.md @@ -115,13 +115,13 @@ At this point, you could call `cargo run` and be greeted with a simple `Hello, W ### Dissecting our example -The `use` statement at the top of our app imports everything from the the `prelude` module. `use`-ing the prelude imports the right traits, types, and macros needed for working with Dioxus. +The `use` statement at the top of our app imports everything from the `prelude` module. `use`-ing the prelude imports the right traits, types, and macros needed for working with Dioxus. ```rust use dioxus::prelude::*; ``` -This initialization code launches a Tokio runtime on a helper thread where your code will run. Then, the WebView renderer will be launched on the main-thread. Due to platform requirements, the main thread is blocked by your app's event loop. +This initialization code launches a Tokio runtime on a helper thread where your code will run. Then, the WebView renderer will be launched on the main thread. Due to platform requirements, the main thread is blocked by your app's event loop. ```rust fn main() { diff --git a/docs/guide/src/interactivity/event_handlers.md b/docs/guide/src/interactivity/event_handlers.md index ee6a7675f..89139adb4 100644 --- a/docs/guide/src/interactivity/event_handlers.md +++ b/docs/guide/src/interactivity/event_handlers.md @@ -1,6 +1,6 @@ # Event handlers -To make our boring UIs less static and more interesting, we want to add the ability to interact to user input. To do this, we need to add some event handlers. +To make our boring UIs less static and more interesting, we want to add the ability to interact with user input. To do this, we need to add some event handlers. ## The most basic events: clicks @@ -82,7 +82,7 @@ div { } ``` -In this particular layout, a click on the inner div is transitively also a click on the outer div. If we didn't want the outer div to be triggered every time we trigger the inner div, then we'd want to call "cancel_bubble". +In this particular layout, a click on the inner div is transitively also a click on the outer div. If we didn't want the outer div to be triggered every time we trigger the inner div, then we'd want to call `cancel_bubble()`. This will prevent any listeners above the current listener from being triggered. @@ -102,7 +102,7 @@ div { ## Prevent Default -With HTML based renderers, the browser will automatically perform some action. For text inputs, this would be entering the provided key. For forms, this might involve navigating the page. +With HTML-based renderers, the browser will automatically perform some action. For text inputs, this would be entering the provided key. For forms, this might involve navigating the page. In some instances, you don't want this default behavior. In these cases, instead of handling the event directly, you'd want to prevent any default handlers. diff --git a/docs/guide/src/interactivity/user_input.md b/docs/guide/src/interactivity/user_input.md index 958e58553..e878afbbe 100644 --- a/docs/guide/src/interactivity/user_input.md +++ b/docs/guide/src/interactivity/user_input.md @@ -60,14 +60,13 @@ cx.render(rsx!{ ## Uncontrolled Inputs -When working with large sets of inputs, you might be quickly tired of creating `use_state` for each value. Additionally, the pattern of one use_state per interaction might deteriorate when you need to have a flexible number of inputs. In these cases, we use "uncontrolled" inputs. Here, we don't drive the value of the input from the use_state, choosing to leave it in an "uncontrolled" state. +When working with large sets of inputs, you might be quickly tired of creating `use_state` for each value. Additionally, the pattern of one `use_state` per interaction might deteriorate when you need to have a flexible number of inputs. In these cases, we use "uncontrolled" inputs. Here, we don't drive the value of the input from the `use_state`, choosing to leave it in an "uncontrolled" state. -This approach can be more performant, more flexible, but more prone to UI inconsistencies than its controlled counterpart. +This approach can be more performant and more flexible, but more prone to UI inconsistencies than its controlled counterpart. To use the "uncontrolled" pattern, we simply omit setting the value of the input. Instead, we can react to the change directly on the input itself, or from a form element higher up in the tree. - -For this example, we don't attach any `use_state` handles into the labels. Instead, we simply attach an "oninput" handler to the form element. This will run each time any of the child inputs change, allowing us to perform tasks like form validation. +For this example, we don't attach any `use_state` handles into the labels. Instead, we simply attach an `oninput` handler to the form element. This will run each time any of the child inputs change, allowing us to perform tasks like form validation. ```rust form { @@ -81,4 +80,3 @@ form { input { name: "date", } } ``` - diff --git a/docs/guide/src/interactivity/usestate.md b/docs/guide/src/interactivity/usestate.md index 256ac94a3..64aa81d59 100644 --- a/docs/guide/src/interactivity/usestate.md +++ b/docs/guide/src/interactivity/usestate.md @@ -3,7 +3,7 @@ The first fundamental hook for state management is `use_state`. This particular hook is designed to work well with the entire Dioxus ecosystem including futures, children, and memoization. -## Basic usage. +## Basic usage The simplest use case of `use_state` is a simple counter. The handle returned by `use_state` implements `Add` and `AddAssign`. Writing through `AddAssign` will automatically mark the component as dirty, forcing an update. diff --git a/docs/guide/src/state/index.md b/docs/guide/src/state/index.md index 5dc86539f..ac025aff1 100644 --- a/docs/guide/src/state/index.md +++ b/docs/guide/src/state/index.md @@ -1,6 +1,6 @@ # Managing State -Every app you'll build with Dioxus will have some sort of state that needs to be maintained and updated as your users interact with it. However, managing state can be particular challenging at times, and is frequently the source of bugs in many GUI frameworks. +Every app you'll build with Dioxus will have some sort of state that needs to be maintained and updated as your users interact with it. However, managing state can be particularly challenging at times, and is frequently the source of bugs in many GUI frameworks. In this chapter, we'll cover the various ways to manage state, the appropriate terminology, various patterns, and some problems you might run into. @@ -11,7 +11,7 @@ Why do people say state management is so difficult? What does it mean? Generally, state management is the code you need to write to ensure that your app renders the *correct* content. If the user inputs a name, then you need to display the appropriate response - like alerts, validation, and disable/enable various elements on the page. Things can quickly become tricky if you need loading screens and cancellable tasks. -For the simplest of apps, all your state can enter the app from the root props. This is common in server-side rendering - we can collect all of the required state *before* rendering the content. +For the simplest of apps, all of your state can enter the app from the root props. This is common in server-side rendering - we can collect all of the required state *before* rendering the content. ```rust let all_content = get_all_content().await; @@ -36,4 +36,3 @@ To deal with complexity, you have a couple of options: - Lift state upwards to be spread across multiple components (fan out). - Use the Context API to share state globally. - Use a dedicated state management solution like Fermi. -