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/__unused/advanced-guides/custom-renderer.md

@@ -22,7 +22,7 @@ For reference, check out the WebSys renderer as a starting point for your custom
 
 The current `RealDom` trait lives in `dioxus-core/diff`. A version of it is provided here (but might not be up-to-date):
 
-```rust
+```rust, no_run
 pub trait RealDom<'a> {
     fn handle_edit(&mut self, edit: DomEdit);
     fn request_available_node(&mut self) -> ElementId;
@@ -32,7 +32,7 @@ pub trait RealDom<'a> {
 
 For reference, the "DomEdit" type is a serialized enum that represents an atomic operation occurring on the RealDom. The variants roughly follow this set:
 
-```rust
+```rust, no_run
 enum DomEdit {
     PushRoot,
     AppendChildren,
@@ -51,12 +51,11 @@ enum DomEdit {
 
 The Dioxus diffing mechanism operates as a [stack machine](https://en.wikipedia.org/wiki/Stack_machine) where the "push_root" method pushes a new "real" DOM node onto the stack and "append_child" and "replace_with" both remove nodes from the stack.
 
-
 ### An example
 
 For the sake of understanding, lets consider this example – a very simple UI declaration:
 
-```rust
+```rust, no_run
 rsx!( h1 {"hello world"} )
 ```
 
@@ -64,7 +63,7 @@ To get things started, Dioxus must first navigate to the container of this h1 ta
 
 When the renderer receives this instruction, it pushes the actual Node onto its own stack. The real renderer's stack will look like this:
 
-```rust
+```rust, no_run
 instructions: [
     PushRoot(Container)
 ]
@@ -75,7 +74,7 @@ stack: [
 
 Next, Dioxus will encounter the h1 node. The diff algorithm decides that this node needs to be created, so Dioxus will generate the DomEdit `CreateElement`. When the renderer receives this instruction, it will create an unmounted node and push into its own stack:
 
-```rust
+```rust, no_run
 instructions: [
     PushRoot(Container),
     CreateElement(h1),
@@ -85,8 +84,10 @@ stack: [
     h1,
 ]
 ```
+
 Next, Dioxus sees the text node, and generates the `CreateTextNode` DomEdit:
-```rust
+
+```rust, no_run
 instructions: [
     PushRoot(Container),
     CreateElement(h1),
@@ -98,9 +99,10 @@ stack: [
     "hello world"
 ]
 ```
+
 Remember, the text node is not attached to anything (it is unmounted) so Dioxus needs to generate an Edit that connects the text node to the h1 element. It depends on the situation, but in this case we use `AppendChildren`. This pops the text node off the stack, leaving the h1 element as the next element in line.
 
-```rust
+```rust, no_run
 instructions: [
     PushRoot(Container),
     CreateElement(h1),
@@ -112,8 +114,10 @@ stack: [
     h1
 ]
 ```
+
 We call `AppendChildren` again, popping off the h1 node and attaching it to the parent:
-```rust
+
+```rust, no_run
 instructions: [
     PushRoot(Container),
     CreateElement(h1),
@@ -125,8 +129,10 @@ stack: [
     ContainerNode,
 ]
 ```
+
 Finally, the container is popped since we don't need it anymore.
-```rust
+
+```rust, no_run
 instructions: [
     PushRoot(Container),
     CreateElement(h1),
@@ -137,8 +143,10 @@ instructions: [
 ]
 stack: []
 ```
+
 Over time, our stack looked like this:
-```rust
+
+```rust, no_run
 []
 [Container]
 [Container, h1]
@@ -164,7 +172,7 @@ Like most GUIs, Dioxus relies on an event loop to progress the VirtualDOM. The V
 
 The code for the WebSys implementation is straightforward, so we'll add it here to demonstrate how simple an event loop is:
 
-```rust
+```rust, no_run
 pub async fn run(&mut self) -> dioxus_core::error::Result<()> {
     // Push the body element onto the WebsysDom's stack machine
     let mut websys_dom = crate::new::WebsysDom::new(prepare_websys_dom());
@@ -194,7 +202,7 @@ pub async fn run(&mut self) -> dioxus_core::error::Result<()> {
 
 It's important that you decode the real events from your event system into Dioxus' synthetic event system (synthetic meaning abstracted). This simply means matching your event type and creating a Dioxus `VirtualEvent` type. Your custom event must implement the corresponding event trait. Right now, the VirtualEvent system is modeled almost entirely around the HTML spec, but we are interested in slimming it down.
 
-```rust
+```rust, no_run
 fn virtual_event_from_websys_event(event: &web_sys::Event) -> VirtualEvent {
     match event.type_().as_str() {
         "keydown" | "keypress" | "keyup" => {
@@ -224,7 +232,7 @@ These custom elements are defined as unit structs with trait implementations.
 
 For example, the `div` element is (approximately!) defined as such:
 
-```rust
+```rust, no_run
 struct div;
 impl div {
     /// Some glorious documentation about the class property.
@@ -235,8 +243,8 @@ impl div {
     // more attributes
 }
 ```
-You've probably noticed that many elements in the `rsx!` and `html!` macros support on-hover documentation. The approach we take to custom elements means that the unit struct is created immediately where the element is used in the macro. When the macro is expanded, the doc comments still apply to the unit struct, giving tons of in-editor feedback, even inside a proc macro.
 
+You've probably noticed that many elements in the `rsx!` and `html!` macros support on-hover documentation. The approach we take to custom elements means that the unit struct is created immediately where the element is used in the macro. When the macro is expanded, the doc comments still apply to the unit struct, giving tons of in-editor feedback, even inside a proc macro.
 
 ## Compatibility
 
@@ -252,7 +260,7 @@ The best hooks will properly detect the target platform and still provide functi
 
 This particular code _will panic_ due to the unwrap on downcast_ref. Try to avoid these types of patterns.
 
-```rust
+```rust, no_run
 let div_ref = use_node_ref(cx);
 
 cx.render(rsx!{