Minor fixes

.github/workflows/main.yml

@@ -1,6 +1,6 @@
 name: Main
 
-on: [push]
+on: [push, pull_request]
 
 env:
   RUST_BACKTRACE: 1

crate/guides/about.md

@@ -32,7 +32,7 @@ are worth it.
 
 ## Where to start if you're familiar with existing frontend frameworks
 
-Check out the (Code comparison)[https://seed-rs.org/guide/code-comarison]) section of this guide. Additionally,
+Check out the [Code comparison](https://seed-rs.org/guide/code-comarison) section of this guide. Additionally,
 the [todomvc example](https://github.com/seed-rs/seed/tree/master/examples/todomvc) is an implementation of 
 the [TodoMVC project](https://todomvc.com/),
 which has example code in other frameworks that produce identitcal apps. Compare the example in this

crate/guides/events.md

@@ -70,7 +70,7 @@ keyboard_ev("input", Msg::PutTheHammerDown)
 
 Note that in the examples for input_ev and keyboard_ev, the syntax is simplified since
 we're only passing the field text, and keyboard event respectively to the Msg. The input_ev
-example is Rust shorthand for ```input_ev("input, |text| Msg::NewWords(text)```. If you were
+example is Rust shorthand for ```input_ev("input", |text| Msg::NewWords(text))```. If you were
 to pass something other than, or more than just the input text (Or KeyboardEvent for keyboard_ev, 
 or Event for raw_ev described below),
 you can't use this shorthand, and would have to do something like this intead,
@@ -177,7 +177,7 @@ where it handles text input triggered by a key press, and uses prevent_default()
 ## Window events
 We handle events triggered by the overall window specially, since it doesn't fit directly
 into our virtual DOM. We pass to `App::builder::window_events()` a function that accepts a
- ref to `Model`, and returns a `Vec<devents::Listener>`. We use it to control
+ ref to `Model`, and returns a `Vec<events::Listener>`. We use it to control
 which listeners are attached to the window based on the model. Excerpt from the
 [window_events](https://github.com/seed-rs/seed/blob/master/examples/window_events/src/lib.rs)
 example:

crate/guides/structure.md

@@ -25,7 +25,7 @@ impl Default for Model {
 ```
 
 In this example, we initialize using Rust’s `Default` trait, in order to keep the initialization code by the
- model struct. When we call `Model.default()`, it initializes with these values. We could 
+ model struct. When we call `Model::default()`, it initializes with these values. We could 
  also initialize it using a constructor method, or a struct literal. Note the use of `into()` 
  on our `&str` literal, to convert it into an owned `String`.
 
@@ -68,13 +68,13 @@ enum Msg {
 ```
 
 The update [function]( https://doc.rust-lang.org/book/ch03-03-how-functions-work.html) 
-you pass to `App::builder(` describes how the state should change, upon
-receiving each type of message. It's the only place where the model is changed. It accepts a message, 
-and model as parameters, and returns an `Update` struct. `Update` contains `ShouldRender` and `Effect`
+you pass to `App::builder()` describes how the state should change, upon
+receiving each type of message. It's the only place where the model is changed. It accepts a message 
+and a model as parameters, and returns an `Update` struct. `Update` contains `ShouldRender` and `Effect`
 enums. `ShouldRender` and its variants are imported in the prelude, 
 and has variants of 
-`Render` and `Skip`. Render triggers a rendering update, and will be used in 
-most cases. `Skip` updates the model without triggering a render, and is useful in animations.
+`Render` and `Skip`. Render triggers a rendering update and will be used in 
+most cases. `Skip` updates the model without triggering a render and is useful in animations.
 `Effect` isn't exposed in the API: it's used internally to handle async events like
 fetch requests. See the `Http requests` section for more info.
 
@@ -117,6 +117,8 @@ fn update(msg: Msg, model: &mut Model, _orders: &mut impl Orders<Msg>) {
 }
 ```
 
+[TODO]: # (This section below is unclear, please improve me)
+
 The third parameter of the update function is an 
 [Orders](https://docs.rs/seed/0.3.4/seed/prelude/struct.Orders.html)
  struct, imported in the prelude.

crate/guides/view.md

@@ -1,37 +1,37 @@
 # View
 
- Visual layout (ie HTML/DOM elements) is described declaratively in Rust, and uses 
-[macros]( https://doc.rust-lang.org/book/appendix-04-macros.html) to simplify syntax. Each element
+ Visual layout (ie HTML/DOM elements) is described declaratively with [macros]( https://doc.rust-lang.org/book/appendix-04-macros.html) to simplify syntax. Each element
 is represented by a macro, eg `div![]`. These act as functions that accept an arbitrary
-number of parameters, in any order: They handle the parameters based exclusively on type.
+number of parameters in any order. They handle parameters based exclusively on type.
 
-The view's defined by a function that's passed to 
-[App::builder](https://docs.rs/seed/0.4.2/seed/struct.App.html#method.build). This takes a `&Model`
-as its parameter, and outputs something that implements the ` View` trait, which is imported in the prelude.
+The view is defined by a function passed to 
+[App::build()](https://docs.rs/seed/0.4.2/seed/struct.App.html#method.build). It takes a `&Model`
+as a parameter and outputs something that implements the ` View` trait, which is imported in the prelude.
 Usually, this is a `Node`, or `Vec<Node>`, representing all nodes that will be inserted as children
-on the top-level one. (The top-level `Node` is in the html file, and specified with
-[App::builder.mount()](https://docs.rs/seed/0.4.2/seed/struct.AppBuilder.html#method.mount), 
-or as a default, the element with id `app`).
+on the top-level one. The top-level `Node` exists in the DOM as specified by
+[AppBuilder::mount()](https://docs.rs/seed/0.4.2/seed/struct.AppBuilder.html#method.mount) and defaults to an element with id `app`.
  It may composed into sub-functions, which can be thought of like components in other frameworks. 
 
 Examples:
 ```rust
 fn view(model: &Model) -> Node<Msg> {
-    h1![ "Let there be light" ],
+    h1![ "Let there be light" ]
 }
 ```
 
 ```rust
 fn view(model: &Model) -> Vec<Node<Msg>> {
     vec![
         h1![ "Let there be light" ],
-        h2![ "Let it be both a particle and a wave" ]
+        h2![ "Let it be both a particle and a wave" ],
     ]
 }
 `````
 In either of those examples, you could use the signature: `fn view(model: &Model) -> impl View<Msg>` instead.
 This allows you to change between them without changing the function signature.
 
+[TODO]: # (Explain what `Msg` type parameter means and how it's connected to `update` function)
+
 ## The Node Enum
 The Virtual DOM is represnted by nested [Nodes](https://docs.rs/seed/0.1.6/seed/dom_types/enum.Node.html).
 `Node` has 3 variants: 
@@ -433,6 +433,6 @@ branches must return an `Node` (Or `Vec` of `Node`s) to satisfy Rust's type syst
 rendered, and its `empty![]` macro alias, which is more concise and consistent:
 ```rust
 div![
-    if model.count >= 10 { h2![ style!{St::Padding => 50}, "Nice!" ] } else { empty![]) }
+    if model.count >= 10 { h2![ style!{St::Padding => 50}, "Nice!" ] } else { empty![] }
 ]
 ```