Fix: Remove play button from guide example (#1118)

* fix: Remove play button from guide example

* Update index.md

* update other examples

docs/guide/src/en/interactivity/custom_hooks.md

@@ -10,13 +10,13 @@ To avoid repetition, you can encapsulate business logic based on existing hooks
 
 For example, if many components need to access an `AppSettings` struct, you can create a "shortcut" hook:
 
-```rust
+```rust, no_run
 {{#include ../../../examples/hooks_composed.rs:wrap_context}}
 ```
 
 Or if you want to wrap a hook that persists reloads with the storage API, you can build on top of the use_ref hook to work with mutable state:
 
-```rust
+```rust, no_run
 {{#include ../../../examples/hooks_composed.rs:use_storage}}
 ```
 
@@ -34,7 +34,7 @@ Inside the initialization closure, you will typically make calls to other `cx` m
 
 Here is a simplified implementation of the `use_state` hook:
 
-```rust
+```rust, no_run
 {{#include ../../../examples/hooks_custom_logic.rs:use_state}}
 ```
 
@@ -42,7 +42,7 @@ Here is a simplified implementation of the `use_state` hook:
 
 Here is an implementation of the `use_context` and `use_context_provider` hooks:
 
-```rust
+```rust, no_run
 {{#include ../../../examples/hooks_custom_logic.rs:use_context}}
 ```
 
@@ -54,13 +54,13 @@ When writing a custom hook, you should avoid the following anti-patterns:
 
 This version of use_state may seem more efficient, but it is not cloneable:
 
-```rust
+```rust, no_run
 {{#include ../../../examples/hooks_anti_patterns.rs:non_clone_state}}
 ```
 
 If we try to use this hook in an async block, we will get a compile error:
 
-```rust
+```rust, no_run
 fn FutureComponent(cx: &ScopeState) -> Element {
     let my_state = my_use_state(cx, || 0);
     cx.spawn({
@@ -76,7 +76,7 @@ fn FutureComponent(cx: &ScopeState) -> Element {
 
 But with the original version, we can use it in an async block:
 
-```rust
+```rust, no_run
 fn FutureComponent(cx: &ScopeState) -> Element {
     let my_state = use_state(cx, || 0);
     cx.spawn({

docs/guide/src/en/interactivity/dynamic_rendering.md

@@ -6,7 +6,7 @@ Sometimes you want to render different things depending on the state/props. With
 
 To render different elements based on a condition, you could use an `if-else` statement:
 
-```rust
+```rust, no_run
 {{#include ../../../examples/conditional_rendering.rs:if_else}}
 ```
 
@@ -18,7 +18,7 @@ You may have noticed some repeated code in the `if-else` example above. Repeatin
 
 We can improve this example by splitting up the dynamic parts and inserting them where they are needed.
 
-```rust
+```rust, no_run
 {{#include ../../../examples/conditional_rendering.rs:if_else_improved}}
 ```
 
@@ -26,18 +26,17 @@ We can improve this example by splitting up the dynamic parts and inserting them
 
 Since `Element` is a `Option<VNode>`, components accepting `Element` as a prop can inspect its contents, and render different things based on that. Example:
 
-```rust
+```rust, no_run
 {{#include ../../../examples/component_children_inspect.rs:Clickable}}
 ```
 
 You can't mutate the `Element`, but if you need a modified version of it, you can construct a new one based on its attributes/children/etc.
 
-
 ## Rendering Nothing
 
 To render nothing, you can return `None` from a component. This is useful if you want to conditionally hide something:
 
-```rust
+```rust, no_run
 {{#include ../../../examples/conditional_rendering.rs:conditional_none}}
 ```
 
@@ -58,7 +57,7 @@ For this, Dioxus accepts iterators that produce `Element`s. So we need to:
 
 Example: suppose you have a list of comments you want to render. Then, you can render them like this:
 
-```rust
+```rust, no_run
 {{#include ../../../examples/rendering_lists.rs:render_list}}
 ```
 
@@ -66,7 +65,7 @@ Example: suppose you have a list of comments you want to render. Then, you can r
 
 Because of how common it is to render a list of items, Dioxus provides a shorthand for this. Instead of using `.iter`, `.map`, and `rsx`, you can use a `for` loop with a body of rsx code:
 
-```rust
+```rust, no_run
 {{#include ../../../examples/rendering_lists.rs:render_list_for_loop}}
 ```
 

docs/guide/src/en/interactivity/event_handlers.md

@@ -8,7 +8,7 @@ Event handlers are similar to regular attributes, but their name usually starts
 
 For example, to handle clicks on an element, we can specify an `onclick` handler:
 
-```rust
+```rust, no_run
 {{#include ../../../examples/event_click.rs:rsx}}
 ```
 
@@ -33,7 +33,7 @@ Some events will trigger first on the element the event originated at upward. Fo
 
 If you want to prevent this behavior, you can call `stop_propagation()` on the event:
 
-```rust
+```rust, no_run
 {{#include ../../../examples/event_nested.rs:rsx}}
 ```
 
@@ -43,25 +43,25 @@ Some events have a default behavior. For keyboard events, this might be entering
 
 In some instances, might want to avoid this default behavior. For this, you can add the `prevent_default` attribute with the name of the handler whose default behavior you want to stop. This attribute can be used for multiple handlers using their name separated by spaces:
 
-```rust
+```rust, no_run
 {{#include ../../../examples/event_prevent_default.rs:prevent_default}}
 ```
 
 Any event handlers will still be called.
 
-> Normally, in React or JavaScript, you'd call "preventDefault" on the event in the callback. Dioxus does *not* currently support this behavior. Note: this means you cannot conditionally prevent default behavior based on the data in the event.
+> Normally, in React or JavaScript, you'd call "preventDefault" on the event in the callback. Dioxus does _not_ currently support this behavior. Note: this means you cannot conditionally prevent default behavior based on the data in the event.
 
 ## Handler Props
 
 Sometimes, you might want to make a component that accepts an event handler. A simple example would be a `FancyButton` component, which accepts an `on_click` handler:
 
-```rust
+```rust, no_run
 {{#include ../../../examples/event_handler_prop.rs:component_with_handler}}
 ```
 
 Then, you can use it like any other handler:
 
-```rust
+```rust, no_run
 {{#include ../../../examples/event_handler_prop.rs:usage}}
 ```
 

docs/guide/src/en/interactivity/hooks.md

@@ -14,9 +14,10 @@ Hooks allow us to create state in our components. Hooks are Rust functions that
 
 For example, you might have seen the counter example, in which state (a number) is tracked using the `use_state` hook:
 
-```rust
+```rust, no_run
 {{#include ../../../examples/hooks_counter.rs:component}}
 ```
+
 ![Screenshot: counter app](./images/counter.png)
 
 Every time the component's state changes, it re-renders, and the component function is called, so you can describe what you want the new UI to look like. You don't have to worry about "changing" anything – just describe what you want in terms of the state, and Dioxus will take care of the rest!
@@ -25,9 +26,10 @@ Every time the component's state changes, it re-renders, and the component funct
 
 You can use multiple hooks in the same component if you want:
 
-```rust
+```rust, no_run
 {{#include ../../../examples/hooks_counter_two_state.rs:component}}
 ```
+
 ![Screenshot: app with two counters](./images/counter_two_state.png)
 
 ## Rules of Hooks
@@ -36,7 +38,7 @@ The above example might seem a bit magic, since Rust functions are typically not
 
 But how can Dioxus differentiate between multiple hooks in the same component? As you saw in the second example, both `use_state` functions were called with the same parameters, so how come they can return different things when the counters are different?
 
-```rust
+```rust, no_run
 {{#include ../../../examples/hooks_counter_two_state.rs:use_state_calls}}
 ```
 
@@ -51,17 +53,20 @@ This is only possible because the two hooks are always called in the same order,
 These rules mean that there are certain things you can't do with hooks:
 
 ### No Hooks in Conditionals
-```rust
+
+```rust, no_run
 {{#include ../../../examples/hooks_bad.rs:conditional}}
 ```
 
 ### No Hooks in Closures
-```rust
+
+```rust, no_run
 {{#include ../../../examples/hooks_bad.rs:closure}}
 ```
 
 ### No Hooks in Loops
-```rust
+
+```rust, no_run
 {{#include ../../../examples/hooks_bad.rs:loop}}
 ```
 
@@ -75,9 +80,8 @@ Thankfully, there is another hook for that, `use_ref`! It is similar to `use_sta
 
 Here's a simple example that keeps a list of events in a `use_ref`. We can acquire write access to the state with `.with_mut()`, and then just `.push` a new value to the state:
 
-```rust
+```rust, no_run
 {{#include ../../../examples/hooks_use_ref.rs:component}}
 ```
 
 > The return values of `use_state` and `use_ref` (`UseState` and `UseRef`, respectively) are in some ways similar to [`Cell`](https://doc.rust-lang.org/std/cell/) and [`RefCell`](https://doc.rust-lang.org/std/cell/struct.RefCell.html) – they provide interior mutability. However, these Dioxus wrappers also ensure that the component gets re-rendered whenever you change the state.
-

docs/guide/src/en/interactivity/router.md

@@ -4,7 +4,6 @@ In many of your apps, you'll want to have different "scenes". For a webpage, the
 
 To unify these platforms, Dioxus provides a first-party solution for scene management called Dioxus Router.
 
-
 ## What is it?
 
 For an app like the Dioxus landing page (https://dioxuslabs.com), we want to have several different scenes:
@@ -20,12 +19,11 @@ The Dioxus router makes it easy to create these scenes. To make sure we're using
 cargo add dioxus-router
 ```
 
-
 ## Using the router
 
 Unlike other routers in the Rust ecosystem, our router is built declaratively. This makes it possible to compose our app layout simply by arranging components.
 
-```rust
+```rust, no_run
 rsx!{
     // All of our routes will be rendered inside this Router component
     Router {
@@ -43,7 +41,7 @@ We can fix this one of two ways:
 
 - A fallback 404 page
 
-```rust
+```rust, no_run
 rsx!{
     Router {
         Route { to: "/home", Home {} }
@@ -54,10 +52,9 @@ rsx!{
 }
 ```
 
-
 - Redirect 404 to home
 
-```rust
+```rust, no_run
 rsx!{
     Router {
         Route { to: "/home", Home {} }
@@ -72,8 +69,7 @@ rsx!{
 
 For our app to navigate these routes, we can provide clickable elements called Links. These simply wrap `<a>` elements that, when clicked, navigate the app to the given location.
 
-
-```rust
+```rust, no_run
 rsx!{
     Link {
         to: "/home",

docs/guide/src/en/interactivity/sharing_state.md

@@ -11,7 +11,8 @@ Suppose we want to build a meme editor. We want to have an input to edit the mem
 > Of course, in this simple example, we could write everything in one component – but it is better to split everything out in smaller components to make the code more reusable, maintainable, and performant (this is even more important for larger, complex apps).
 
 We start with a `Meme` component, responsible for rendering a meme with a given caption:
-```rust
+
+```rust, no_run
 {{#include ../../../examples/meme_editor.rs:meme_component}}
 ```
 
@@ -19,14 +20,16 @@ We start with a `Meme` component, responsible for rendering a meme with a given
 
 We also create a caption editor, completely decoupled from the meme. The caption editor must not store the caption itself – otherwise, how will we provide it to the `Meme` component? Instead, it should accept the current caption as a prop, as well as an event handler to delegate input events to:
 
-```rust
+```rust, no_run
 {{#include ../../../examples/meme_editor.rs:caption_editor}}
 ```
 
 Finally, a third component will render the other two as children. It will be responsible for keeping the state and passing down the relevant props.
-```rust
+
+```rust, no_run
 {{#include ../../../examples/meme_editor.rs:meme_editor}}
 ```
+
 ![Meme Editor Screenshot: An old plastic skeleton sitting on a park bench. Caption: "me waiting for a language feature"](./images/meme_editor_screenshot.png)
 
 ## Using Context
@@ -43,24 +46,26 @@ Dioxus offers a better solution than this "prop drilling" – providing context.
 
 First, we have to create a struct for our dark mode configuration:
 
-```rust
+```rust, no_run
 {{#include ../../../examples/meme_editor_dark_mode.rs:DarkMode_struct}}
 ```
 
 Now, in a top-level component (like `App`), we can provide the `DarkMode` context to all children components:
-```rust
+
+```rust, no_run
 {{#include ../../../examples/meme_editor_dark_mode.rs:context_provider}}
 ```
 
 As a result, any child component of `App` (direct or not), can access the `DarkMode` context.
-```rust
+
+```rust, no_run
 {{#include ../../../examples/meme_editor_dark_mode.rs:use_context}}
 ```
 
 > `use_context` returns `Option<UseSharedState<DarkMode>>` here. If the context has been provided, the value is `Some(UseSharedState<DarkMode>)`, which you can call `.read` or `.write` on, similarly to `UseRef`. Otherwise, the value is `None`.
 
 For example, here's how we would implement the dark mode toggle, which both reads the context (to determine what color it should render) and writes to it (to toggle dark mode):
-```rust
+
+```rust, no_run
 {{#include ../../../examples/meme_editor_dark_mode.rs:toggle}}
 ```
-

docs/guide/src/en/interactivity/user_input.md

@@ -6,11 +6,12 @@ Interfaces often need to provide a way to input data: e.g. text, numbers, checkb
 
 With controlled inputs, you are directly in charge of the state of the input. This gives you a lot of flexibility, and makes it easy to keep things in sync. For example, this is how you would create a controlled text input:
 
-```rust
+```rust, no_run
 {{#include ../../../examples/input_controlled.rs:component}}
 ```
 
 Notice the flexibility – you can:
+
 - Also display the same contents in another element, and they will be in sync
 - Transform the input every time it is modified (e.g. to make sure it is upper case)
 - Validate the input every time it changes
@@ -23,9 +24,10 @@ As an alternative to controlled inputs, you can simply let the platform keep tra
 
 Since you don't necessarily have the current value of the uncontrolled input in state, you can access it either by listening to `oninput` events (similarly to controlled components), or, if the input is part of a form, you can access the form data in the form events (e.g. `oninput` or `onsubmit`):
 
-```rust
+```rust, no_run
 {{#include ../../../examples/input_uncontrolled.rs:component}}
 ```
+
 ```
 Submitted! UiEvent { data: FormData { value: "", values: {"age": "very old", "date": "1966", "name": "Fred"} } }
-```
+```