YEW Tutorial: 06 Custom Custom Custom
Tags: rust, yew, webassembly, beginners
Published: 2020-06-08 14:59:19

(Photo by Aaron Huber on Unsplash)

**EDIT**: edited for the new Yew version (**>0.16**)

In this sixth part we are going to see how to write and use custom components (and more... as usual...).

### Code to follow this tutorial

The code has been tagged with the relative tutorial and part.

```Bash
git clone https://github.com/davidedelpapa/yew-tutorial.git
cd yew-tutorial
git checkout tags/v6p1
```

## Part 1: Simple but custom

Modularity is the key concept of all current web technologies. In this section we will see how to crate custom components, that is components to embed in the `view` of our app, that will provide both modularity and customization. As usual, we will start with simple examples in order to gain understanding and proficiency in this technique. Those who are used to write JS using React (or Vue or another modern framework) will not have many problems in understanding Yew's custom components; in JS frameworks custom components are the bread and butter of web development.

We will start with a simple wrapper for the `<button>` element.

### Cargo.toml

We will bump up to Yew 0.14 for this part, because there are many more helps to write custom components:

```toml
[dependencies]
wasm-bindgen = "^0.2"
yew = { version = "0.14", features = ["web_sys"] }
```

With yew 0.14 you really need to specify with the `feature` which backend you are using; in this case we are using so far `web-sys`, and we will continue with it (really there are few differences with `std-web`, the other backend, and pros and cons for both, so I made an opinionated choice and now we will stick with it. feel free to check out [std-web](https://docs.rs/stdweb/0.4.20/stdweb/) as well. For example, _std-web_ has got an interesting `js!` macro that simplifies writing small JS snippets).

### src/lib.rs

We will need to add a components _mod_ so this is our entire _src/lib.rs_:

```Rust
#![recursion_limit = "256"]
mod app;
mod components;
use wasm_bindgen::prelude::{wasm_bindgen, JsValue};

#[wasm_bindgen]
pub fn run_app() -> Result<(), JsValue> {
    yew::start_app::<app::App>();

    Ok(())
}
```

### src/components/mod.rs

As you can recall from Rust's basics, mods can be done as separate subdirectories with a _mod.rs_ file in it that exports the other file's elements.

Thus we will create a directory _components_ inside our _src_ directory and add to it the following file _mod.rs_

```Rust
pub mod button;
```

Easy enough: we will add each component in its own file inside the _src/components_, and then we will export them inside the _src/components/mod.rs_ with `pub mod <filename>;`

Many modern languages can behave this way, so for example JS and Python (in Python the file inside the folder is called `__init__.py` for example)

### src/components/button.rs

Our first component. For this part we'll use the one present in Yew's good examples.

First a quick overview of the functions we need to implement. In our _src/app.rs_ so far we have implemented really a custom component, with the `impl Component for App {}`. We did not give too much weight to it, but as is, our _src/app.rs_ **is** a custom component in reality.

So we already know what components need to do: implement 2 types: `type Message` and `type Properties`; and implement 3 functions: `fn create`, `fn update`, and `fn view`

So far this is what we saw in action, and we did not need much more than that. We did not even use the `Properties` type, while we made extensive use of the `Message`. Well, so far our custom componets was the root of our virtual DOM, that is the WASM DOM injected in the `<body>` of our _index.html_. However, for all other custom components, that is, components that will be injected inside our _app_, we will use the _Properties_ type, and a new function as well, `fn change`.

Let's go forth with order. We have all we need in Yew's prelude:

```Rust
use yew::prelude::*;
```

We start with the definition of our _Button_ struct.

```Rust
pub struct Button {
    link: ComponentLink<Self>,
    title: String,
    onsignal: Callback<()>,
}
```

We use the usual `link`, but we have also an iteresting `Callback` (explanations later); moreover, we attach to our _Button_ also a `title` _String_ that we will use as text for our button.

For a simple example, we will use only a message, to fire a _click_ event. We could map a _hover_ or other event as well, if needed.

```Rust
pub enum Msg {
    Clicked,
}
```

We will introduce now a _Props_ struct, to use as `type Properties`.
The name _Props_ is a classic React term, and in fact it represents the same thing. The parent component, in this case our _App_, will use it to communicate the state to the child component we are writing.

```Rust
#[derive(Clone, PartialEq, Properties)]
pub struct Props {
    #[prop_or_default]
    pub title: String,
    pub onsignal: Callback<()>,
}
```

We make it derive the standard `Clone` and `PartialEq`, but also the `Properties` which is defined in Yew's prelude as of the 0.13 release. It is one of the feature that is making working with custom componets really easy now.

The `#[prop_or_default]` means that it will be assigned as a prop, otherwise to use the default (empty string in this case). There is also a `#[prop_or()]` which lets us define the default value if not given as prop.
Of course, the callback will be passed as prop if we want to assign it from our parent to the child (we will see the props in action in our _src/app.rs_ very soon).

Let's tackle the impl of our Button now:

```Rust
impl Component for Button {
    type Message = Msg;
    type Properties = Props;
```

As usual we select our _Msg_ structure as `type Message`. The novelty is that we will not leave the `type Properties` empty, as we did so far, but we assign to it the _Props_ struct.

```Rust
    fn create(props: Self::Properties, link: ComponentLink<Self>) -> Self {
        Button {
            link,
            title: props.title,
            onsignal: props.onsignal,
        }
    }
```

`fn create`: for this we will not assign by defauld the values to our _Button_ but we will use the values of _Props_. In the _App_ we never passed props around, because it is the root of our virtual DOM, so up to now we left the value empy with a `_: Self::Properties`. Now we need it, so we set it as `props: Self::Properties`: in this way, we can assign its values to cosnstruct the _Button_. We pass the second argument, _link_, as usual, from the one received at creation time, as we have always done with our _App_.

```Rust
    fn update(&mut self, msg: Self::Message) -> ShouldRender {
        match msg {
            Msg::Clicked => {
                self.onsignal.emit(());
            }
        }
        false
    }
```

`fn update`: the update is really simple: we just _emit()_ the callback set as `onsignal` in the props when the message is `Clicked`. In other words when clicked the custom button will call the _Callback_ mimicking the `onclick` of the regular `<Button>`.

Notice though that we return `false` as _ShouldRender_ return type: since we emit a callback there's no need to call again the `fn view` and render again the element on the DOM. The component that will call this _Button_ will decide if the logic called by the _Callback_ needs a new rendering or not. However this will be left to the `fn update` of the parent, _App_ in our case.

We finally meet a new function that we will implement for our custom component: `fn change`:

```Rust
    fn change(&mut self, props: Self::Properties) -> ShouldRender {
        self.title = props.title;
        self.onsignal = props.onsignal;
        true
    }
```

The function _change_ is called by the parent of our component every time it asks the child to render again, and is used to implement logic to be done for the changes. Up to now we did not need this, because all logic pre-rendering was done in the `fn update`, since our _App_ represents the root of the DOM, deciding when to render itself again and how.

However, each custom component is not in charge of all the rendering, while between rendering the parent could change the properties in the Props. So we need a mechanism to handle that. That is, we need a function the parent can call when forcing a child to render again. That is the purpose of `change()`.

For example, if we set up our custom _Button_ with a certain title, and we decide that once clicked it should change its title, how does the chain of the envents unfold?
The _App_ will set the custom button and assign to it a title and a callback to emit the signal when it is clicked. When indeed the user clicks on our custom button the `Msg::Clicked` will be called: at this point, the _update_ logic will emit the callback (which the button component ignores, because it can be whatever the parent decides it to be). At this point let's suppose the callback set by the parent (the _App_) calls a message in the _App_ itself (in the `update()` function) that decides to change the title of the button. Since the parent uses the Props to communicate with the child, our app will change the props of the child, then call for a `ShouldRender`. At this point the function _change_ will be invocked, signaling to our custom component that it should handle the new rendering, and check the new info it received from the parent.

Most of the time it is sufficient to re-set the state copying the state received in the _Props_, and then call a new render (by returning `true`) but this logic depends on the internal working of the custom element. Thus the programmer has to make sure of the logic inside the `update()` function.

Here then we see the need for the `fn change`, without which we could not handle new render and changes in the props. Of course, the `fn change` is very similar to the `fn update`, but with a difference: change is **imposed** on the child, while update is a response to the child's own needs, that is, is **self-initiated**.

In this case, we reasssign both the _title_ String and the _onsignal_ Callback, because we do not know what has changed. And since we do not know what changed (if anything) but we do know that the parent forced a new rendering of the view, we return by default a `ShouldRender` as `true`. A strategy that could work, and in JS is done often, is to check if something indeed has changed before making again costly operations. In this case we can update by simply copying the values inside the props to the custom `Button` own properties, but sometimes the logic involved is more complex: think of mapping external APIs for examples, if the `update` logic has to send API requests and wait for responses in order to sync the internal state. Sometimes it's easier to compare and modify only upon change.

Enough with the theory, let's move on.

Finally we see the _view_ of our component:

```Rust
    fn view(&self) -> Html {
        html! {
            <button onclick=self.link.callback(|_| Msg::Clicked)>{ &self.title }</button>
        }
    }
}
```

Most simply we assign the calling of the `Msg::Clicked` to the `onclicked`, which will call the Button's callbck in turn, and we use the `title` as the inner HTML of the `<button></button>` couple.

### src/app.rs

Now we can see our custom component in action. In order to simplify the example, I propose again here the dust off our first example app, with a counter and the messages `AddOne`, `RemoveOne`.

```Rust
use crate::components::button::Button;
use yew::prelude::*;
```

We need to summon our custom component here, with the `use crate::components::button::Button`

```Rust
pub enum Msg {
    AddOne,
    RemoveOne,
}

pub struct App {
    link: ComponentLink<Self>,
    counter: i32,
}
```

_Msg_ and _App_ as usual, nothing to explain here, just our old friends `AddOne`, `RemoveOne`, and the `counter`.

```Rust
impl Component for App {
    type Message = Msg;
    type Properties = ();

    fn create(_: Self::Properties, link: ComponentLink<Self>) -> Self {
        App {
            link: link,
            counter: 0,
        }
    }

    fn update(&mut self, msg: Self::Message) -> ShouldRender {
        match msg {
            Msg::AddOne => {
                self.counter += 1;
            }
            Msg::RemoveOne => {
                self.counter -= if self.counter == 0 { 0 } else { 1 };
            }
        }
        true
    }
```

No _Properties_ as usual, either as type or as paramenter in `fn create`.
In `Msg::RemoveOne` we added a check so that the counter does not reach negative numbers but sits at 0 once reached. So now you can see a possible answer for the little exercise I left you in our second tutorial.

Our custom component will be useful in the `view`:

```Rust
    fn view(&self) -> Html {
        html! {
            <div>
                <h1>{ "Welcome to Components" }</h1>
                <p>{ self.counter } </p>
                <Button onsignal=self.link.callback(|_| Msg::AddOne) title="+1" />
                <Button onsignal=self.link.callback(|_| Msg::RemoveOne) title="-1" />
            </div>
        }
    }
}
```

First thing to notice is that the custom component does not have a closing tag, that is why we **have** to use the final slash form, otherwise the `html!` macro will not recognize it (this is one little restriction that Yew has, we already saw it).

We assign to the `onsignal` of the first button the calling of the `Msg::AddOne`, and the title "+1". Similarly, we assign to the `onsignal` of the second button the calling of the `Msg::RemoveOne`, and the title "-1".

The examle is failry simple and contrieved, but it shows the bare minimum.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/573sbbbxfh0okp5qwm9f.jpg)

Here we can see our custom buttons in action

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/1mhvpwbrshik5jqsyvzc.jpg)

## Part 1b: Explaining the process

The method we have seen, to implement the two types `type Message` and `type Properties`, as well as the four functions `fn create`, `fn update`, `fn change`, and `fn view` is valid for all the components. Here in the second part we will see how to simplify greatly the custom component generation. However, before doing so, let's briefly take a more in-depth look at custom components. This could be helpful in some situations, and hopefully this little detour will be a little more clear than the simple info I gave while explaining the code. Feel free to skip ahead to part 2 if you are not interested.

We have seen 2 types and 4 functions (or methods since they are part of each component impl). Actualy, there are other two methods besides these four functions in the component lifecycle, which can help handling more complex situations with more nuanced components.

Let's go in temporal order.

### 1. fn create()

**Signature**:

`fn create(props: Self::Properties, link: ComponentLink<Self>) -> Self`

First things first. `create()` is the "constructor" of our component. As part of the function signature it accepts the props and a link to the component, as already explained. It returns `Self` (or equivalent), thus it needs to construct the struct that implements the Component.

Init logic goes here.

### 2. fn view()

**Signature**:

`fn view(&self) -> Html`

Even if we save it always for last in writing our code, really after the creation of the elments the page will have to be rendered, otherwise the user cannot push our buttons and try to fire our Messages, etc... The `view()` method renders the layout of the component in the virtual DOM. It accepts a reference to `self` (through which all fields of the component's structure are available), and returns the virtual `Html`, that is usually rendered from the `html!` macro.

Layout goes here.

### 3. fn mounted() // fn rendered()

**EDIT**: edited for the new Yew version (**>0.16**).
**Now it is called redered() and has got different signature**

**Signature**:

`fn mounted(&mut self) -> ShouldRender`

(Yew>0.16) `fn rendered(&mut self, , first_render: bool)`

This new method is called after mounting the component on the DOM, that is, after the view has been rendered, but before the browser refreshes the page. This method is useful for implementing actions to be done after rendering the components, for example if you want to get the focus on a button or form field... 

**(Yew < 0.16)** The method accepts a mutable reference to `self` and returns a `ShouldRender`, that is, `true` if you need to refresh the component after the logic is executed, and render it again on the DOM, or `false` if not.

**(Yew >= 0.16)** The method gets a parameter, `true` the first time it is rendered, `false` all other times, so we can do post-initiation logic pnly once (with `if first_render {...}`) , such for example, `fetch` a service when the page is first loaded instead of asking the user to push a button to do so.

It is an optional method, and will do nothing if not implemented.

Post-render logic goes here.

### 4. fn update()

**Signature**:

`fn update(&mut self, msg: Self::Message) -> ShouldRender`

Whenever a Message is fired the `update` method is called. A message can be triggered by user actions on the UI (callback on buttons or form inputs, for example), but also child components, Services, Agents (we did not see them yet), or Futures (we saw a form in the Fetch handling). The function accepts a reference to `self`, and the message that triggered the call for update. It returns a `ShouldRender` estabishing if a new rendering is due as consequence of the message's handling, or not. Notice that with `update` is the component that updates itself as a reponse of a message event.

Messages handling goes here.

### 5. fn change()

**Signature**:

`fn change(&mut self, props: Self::Properties) -> ShouldRender`

Whenever a parent component needs to re-render its children, or just to change the props of a child, and so to re-render that component, the `change` method of the child is called. This method is akin to the `update`, but instead of accepting a message, it accepts the props. It will have to return a `ShouldRender` too, in case the change in props warrants for the component's' refresh (say the change of a text value or other). `Change` is an optional method, and will do nothing if not implemented. In fact, for the root element it is usually not needed.

Props change handling goes here.

### 6. fn destroy()

**Signature**:

`fn destroy(&mut self)`

This method is called to finalize the lifecycle of the component, when it has to be deleted. It accepts a mutable reference to self, and it is useful for gracefully finalize, clenup or sanitize the removal of the component from the DOM. It does not have a return. This method is totally optional, in fact usually a component does not need to do anything before being removed; in fact, many times in webapps no component is ever removed at all.

Component cleanup logic goes here.

## Part 2 Simplify (I)

#### Caveat

When I started to write the code for this tutorial, and then the text, Yew had just bumped up a version (0.15), but I waited to update to it, I updated only to the 0.14; as I show next, the crate we had to use, _yewtil_, was not compatible with several recent versions (stuck to 0.10!!!). So, as I explain next, I forked it and bumped it up myself. Then Yew bumped up version again, and this time _yewtil_ has beeen moved into Yew's own workspace. However, the versions in _crates.io_ have not been synced so far, while to use the new version of Yew there is quite a change to be done to the codebase, so at this point it is useless for me to try and correct all the following, expecially since I have tagged all versions for reference. So, be patient please: I will show in the following tutorial how to use the latest version of Yew, and how to properly use the official _yewtil_ and not my own fork. But for now, for the sake of understanding the concepts, I will leave the following unchanged.
The next tutorial is scheduled to come up next week, so you will not need to wait too much, and you will be able to use the new Yew, and Yewtil then. Be patient: Yew is still a maturing ecosystem; as I am trying to show, it is already quite usable, but with some caveats, as it is evolving still up to version 1.0

#### Intro to part 2

There are some ways to simplify our code for components: here we will show one of them. We will make use of a crate named [yewtil](https://crates.io/crates/yewtil). Beware, this crate is experimental, and so far there is not the support for Yew 0.14. While waiting for it I made a temporary fork on my github to bump this crate to Yew 0.14. This is all not too orthodox, but while we wait for the new releases, let me show you how simplifying can be done. If you want to stick to the known path keep working with vanilla Yew, as shown in part 1.

For this part I will show you the power of yewtil's **pure components**

#### Code to follow this part

```Bash
git checkout tags/v6p2
```

### Cargo.toml

We would usually add a reference to Yewtil here, and when the version will be updated I will correct this part of the tutorial. For the time being we will refer to my updated fork.

```toml
[dependencies]
wasm-bindgen = "^0.2"
yew = { version = "0.14", features = ["web_sys"] }
yewtil = { git = "https://github.com/davidedelpapa/yewtil", branch="master" }
```

### src/components/button.rs

We will make a change only in the component, while mantaining full compatibility with the previous interface: how cool is that? It is important to have the possibility of simplifying things while still mantaining the old interfaces. Well, it's not so evident in contrived exampes, of course, but while working with real projects it is important not too break things too much while improving, if it is possible.

```Rust
use yew::prelude::*;
use yew::{html, Callback, MouseEvent, Properties};
use yewtil::{Pure, PureComponent};
```

Two things to notice: the use of the `MouseEvent` and the use of _yewtil_. The _MouseEvent_ will handle the click for us.

```Rust
pub type Button = Pure<PureButton>;
```

`Button` has been declared as a type that represents an implementation of yewtil's `Pure` by a struct `PureButton` that we will define next.

```Rust

#[derive(Clone, PartialEq, Properties)]
pub struct PureButton {
    pub onsignal: Callback<MouseEvent>,
    pub title: String,
}
```

The struct `PureButton` is very similar to the old `Props`, not the old `Button`. In fact, the pure component is a mixture of props + component, however, with these differences:

- the Callback is specified for the MouseEvent, while before it was empty
- since pure components do not hold a state, there is no reference to any `ComponentLink`
- the imp will focus only on the render

```html
impl PureComponent for PureButton {
    fn render(&self) -> Html {
        html! {
            <button onclick="&self.onsignal">{ &self.title }</button>
        } 
    }
}
```

That's it: we just use it in a `render` method. _Yewtil_ will take charge of init logic internally with the helper funcion `neq_assign()`. This function is a "blanket trait to provide a convenience method for assigning props in `changed` or updating values in `update`" what it does is that "if `self` and `new` aren't equal, assigns `new` to `self` and returns true, otherwise returns false." This method is very useful to keep the boilerplate code to a minimum.

If you run this code, apart from downloading the new crate and building it, you will see no change in the UI. However, we simplified much more the code!

Two considerations:

1. Pure components are useful only for components that do not need to handle internal state, say, custom implementation of standard components that only present a different render grafphics. For example, if we wanted to implement with Yew all the components available in _Picnic CSS_ that we used earlier in a "Yew Picnic" framework.
2. All this shows that most of the times the `Change` method has only to update the internal state according to props if the two have changed, by copying one to the other. This is what is done for the most art in JS frameworks under the hood. If it is so widely used, then it must be of grat use. One thing then: the `neq_assign()` function is available in Yewtil also for custom components that are not pure components: we should use more of it.

Now, off with these rumblings, back to work again!

## Part 3: Simplify (II) the devops

Up till now we are using the two scripts we did at the beginning, `run.sh` and `stop.sh` for our (limited) "devops".

They are fine for our purposes, but if we want to scale our project to a realworld situation we need to do something serious about the devops. This part is optional, but some quick experimenting will be of much use later on.

#### Code to follow this part

```Bash
git checkout tags/v6p3
```

Let's start with a simple addition: a [live reload plugin](https://www.npmjs.com/package/rollup-plugin-livereload) for _rollup_.
This plugin is needed to reload the content of `main.js` inside the document if it changes, that is, if we change the wasm build.

However, to use it, we need a _package.json_ that is, we need to initialize our project as a regular _npm_ project.

Easy enough,

```bash
npm init
```

...and answer the questions (or press enter many times, and go with the defaults).

At this point we need to save the dependency of `rollup-plugin-livereload` as development dependency (not to be brought to the production project):

```bash
npm install --save-dev rollup-plugin-livereload
```

### rollup.config.js

Now we need to add a JS file that configures rollup, _rollup.config.js_

```javascript
import livereload from "rollup-plugin-livereload";

export default {
  input: "main.js",
  output: {
    file: "pkg/bundle.js",
    format: "iife",
  },
  plugins: [livereload("pkg")],
};
```

We set in this files the options that we were first passing with the command line (or in the _run.sh_):

```bash
rollup ./main.js --format iife --file ./pkg/bundle.js
```

We added to it the plugin `liverelod`, and told it to watch only the directory _pkg_ since for now we need to reload the browser only should changes happen there.

We could as easily watch more than one folder, a JS folder for example:

```javascript
livereload({
  watch: ["pkg", "js"],
});
```

At this point it would be sufficient a:

```bash
rollup -c
```

in order to watch for the changes inside the _pkg/_ folder, and reload the page content. But we need to rebuild the wasm too in order to make the _pkg/_ folder change. We shall see next how to do it

### Cargo Watch

So, we need a way to monitor the changes in the source files and issue a command to compile again the wasm from Rust. We will use [cargo watch](https://github.com/passcod/cargo-watch) to handle this job.

```bash
cargo install cargo-watch
```

Now we need to put together a better flow inside our _run.sh_

### run.sh

We need to change the `pack()` function to use the `rollup -c` and also create a file similar to _.serverpid_ that we will name _.serverpid.rollup_

```bash
pack(){
    cmd="rollup -c"
    $cmd &
    PID=$!
    echo $PID > .serverpid.rollup
}
```

That was easy. Next step, **which is optional**, inside the _run_ function we swap the python server with a Rust server, [thttp](https://crates.io/crates/thttp); it can be installed with `cargo install thttp`

```bash
run(){
    thttp -p 8080 &
    PID=$!
    echo $PID > .serverpid
}
```

The advantage is that it could be easily containerized later on if needs be, since it supports [systemfd](https://crates.io/crates/systemfd)

Next step is **very important**: we create a new _watch()_ and _stop()_ functions.

`watch()` invokes the `cargo watch` command with some options: namely when it detects a change it does call again the same _run.sh_ script with an option, `--reload`, which we will set up in a little while.

```bash
watch() {
    cargo watch -w ./src --postpone -s "run.sh --reload"
}
```

As you can see, `cargo watch` watches for changes only inside the _src/_ folder (option `-w <path>`).

The _stop()_ function is a copy of the content of _stop.sh_ so that we can stop the server, before rebuilding everything.

```bash
stop() {
    kill $(cat .serverpid)
    rm .serverpid
}
```

Finally after all the functions, we need a way to handle the `--reload` option for the script, that is invoked by `cargo watch -s <shell-command>` (see above the full command)

```bash
while [ "$1" != "" ]; do
    case $1 in
        -r | --reload )         stop
                                build
                                run
                                exit
                                ;;
    esac
    shift
done
```

Quite easily: it checks for the option `-r` or `--reload`, and if present, it execues the following functions in a row:

- `stop` to stop the `thttp` server (or python if you still got that)
- `build` to re-build the Rust again
- `run` to restart the server
- then it `exit` without continuing the script.

You may think that we are missing the `pack` function, but think about it: we call the `--reload` option from within `cargo watch` when some source file changes in the Rust part. After this, the `build` will create again a wasm file inside the _pkg/_ folder.

At this point though, _rollup_ will take care of it, because it is still watching the _pkg/_ folder through the _rollup-plugin-livereload_: it will re-run the packaging and swap it with the original one inside the _index.html_

Talking about options in a bash script, we could add easily other options, for example a `--help`:

```bash
while [ "$1" != "" ]; do
    case $1 in
        -r | --reload )         stop
                                build
                                run
                                exit
                                ;;
        -h | --help )           help
                                exit
                                ;;
    esac
    shift
done
```

Of course, we need now a `help()` function, but I leave that up to you.

The final row is very important, it's the default set of commands called up by the script when there are no options:

```bash
build && pack && run && watch
```

We just `build`, then `pack`, then `run`, and `watch` over the run.

Easy peasy.

For your reference I leave here the whole _run.sh_, since we change a lot of things. Besides, you could go and check it in the repo (there are additional changes there):

```bash
#!/bin/bash

build(){
    wasm-pack build --target web
}

pack(){
    cmd="rollup -c"
    $cmd &
    PID=$!
    echo $PID > .serverpid.rollup
}

run(){
    thttp -p 8080 &
    PID=$!
    echo $PID > .serverpid
}

watch() {
    cargo watch -w ./src --postpone -s "run.sh --reload"
}

stop() {
    kill $(cat .serverpid)
    rm .serverpid
}

while [ "$1" != "" ]; do
    case $1 in
        -r | --reload )         stop
                                build
                                run
                                exit
                                ;;
    esac
    shift
done


if [ -f .serverpid ]; then
    echo "Server already running, or in an inconsistent state"
    exit 1
fi

build && pack && run && watch
```

### stop.sh

Just to be sure, we modify also the _stop.sh_ to be a cleanup, if things go wrong, and also to remove the _.serverpid_ 's

```bash
#!/bin/sh

stop(){
    if [ -f .serverpid ]; then
        kill $(cat .serverpid)
        rm .serverpid
        echo Server stopped.
    else
        echo Could not find the server PID. Is it running?
    fi
    if [ -f .serverpid.rollup ]; then
        kill $(cat .serverpid.rollup)
        rm .serverpid.rollup
        echo Hot-Reload server stopped.
    else
        echo Could not find the rot-reload server PID. Is it running?
    fi
}

stop
```

I think it's quite self-explanatory at this point.

### Test the live reload environment

To test it, let's run the script:

```bash
./run.sh
```

Then we modify something in the _src/_ folder, for example _src/app.rs_, so that the `-1` is on the left, and `+1` on the right:

```Rust
fn view(&self) -> Html {
        html! {
            <div>
                <h1>{ "Welcome to Components" }</h1>
                <p>{ self.counter } </p>
                <Button onsignal=self.link.callback(|_| Msg::RemoveOne) title="-1" />
                <Button onsignal=self.link.callback(|_| Msg::AddOne) title="+1" />
            </div>
        }
    }
```

Now it will recompile and restar the server:

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/o0wvwb920ffq80hn6bxh.jpg)

Then, rollup will hot reaload it all! (you do not have to move a finger!)

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/0nk3pvvhfffx2lrjatq3.jpg)

### [Optional] Set the version of the build

**Very Optional**

With all this compiling, many times we do not know if and when the WASM module has been reloaded.

We could make an addition to the _main.js_, to know which version we are running by outputting the compilation date and time:

```javascript
import init, { run_app } from "./pkg/yew_tutorial.js";
import { __compiled } from "./src/js/version.js";

// Add compilation time
console.log("WASM program compiled: " + __compiled());

async function main() {
  await init("/pkg/yew_tutorial_bg.wasm");
  run_app();
}
main();
```

And, of course we have to create a _version.js_ in _src/js/_ ... programmatically! (Inside the _runs.sh_, that is)

First we need to create the folder

```bash
mkdir ./src/js/
```

Then we modify accordingly the _build()_ function in _run.sh_

```bash
create_version() {
    datetime=`date +"%D %T"`
    cat > ./src/js/version.js << EOL
// Do not modify; created programmatically
export function __compiled() {
    return "${datetime}"
}
EOL
}

build(){
    create_version
    wasm-pack build --target web
}
```

To avoid incurring in a costant loop, we need to ignore JavaScript files from the `cargo watch` command

```bash
watch() {
    cargo watch -w ./src --ignore "*.js" --postpone -s "run.sh --reload"
}
```

Finally we can see in the web console the build date and time of the WASM:

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/rrcbmat2lzgwkxnn73z3.jpg)

We could easily change the JS to add a real version, followed by the timestamp, and so on (you got the knack of it).

## Conclusions

It's all for today. 

I'm tired, but I hope these little modifications will help you to build real world apps.
Stay tuned!