+ 
+
+ }
+ })
+ .collect();
+
+ html! { {products} }
- html! { {"Home!"} }
}
}
The create lifecycle method is invoked when the component is created
and this is where we set the initial state. For the time being, we've
created a mock list of products and assigned it to the products
inside the state as initial value. Later, we'll fetch this list using
network request.
The view lifecycle method is invoked when the component is rendered.
Here we've iterated over products inside state to generate product
cards. If you're familiar with React, this is same as the render
method and the html! macro is similar to JSX.
Save some random images as static/products/apple.png and static/
products/banana.png and you'll get this UI:
[image-2]
Let's implement the "add to cart" functionality:
* We keep track of all products added to cart in a new state field
called cart_products
* We render a "add to cart" button for each product
* Add logic to update the cart_products state when "add to cart"
button is clicked
use yew::prelude::*;
+ #[derive(Clone)]
struct Product {
id: i32,
name: String,
description: String,
image: String,
price: f64,
}
+ struct CartProduct {
+ product: Product,
+ quantity: i32,
+ }
struct State {
products: Vec{&product.name}
+ {"$"}{&product.price}
+ {&product.name}
{"$"}{&product.price}
+
+ {format!("Cart Value: {:.2}", cart_value)}
+ {products}
+
+ }
}
}
* clone - We've derived the Clone trait in Product struct so we can
save the cloned Product into CartProduct whenever the user adds
them to cart.
* update - This method is the place where the logic to update the
component State or perform side-effects (like network requests)
exist. It is invoked using a Message enum that contains all the
actions the component supports. When we return true from this
method, the component is re-rendered. In the above code, when the
user clicks the "Add To Cart" button, we send a Msg::AddToCart
message to update. Inside update, this either adds the product to
cart_product if it doesn't exist or it increments the quantity.
* link - This allows us to register callbacks that can trigger our
update lifecycle method.
If you've used Redux before, update is similar to Reducer (for state
updates) and Action Creator (for side-effects), Message is similar to
Action and link is similar to Dispatch.
[rust-wasm-]
Here's how the UI looks like, try clicking the "Add To Cart" button
and see the changes in "Cart Value":
[image-3]
Fetching Data
We'll move the product data from the create function to static/
products/products.json and query it using the fetch api.
[
{
"id": 1,
"name": "Apple",
"description": "An apple a day keeps the doctor away",
"image": "/products/apple.png",
"price": 3.65
},
{
"id": 2,
"name": "Banana",
"description": "An old banana leaf was once young and green",
"image": "/products/banana.png",
"price": 7.99
}
]
Yew exposes common browser apis like fetch, localstorage etc through
something called "services". We can use the FetchService to make
network requests. It requires anyhow and serde crates, let's install
them:
[package]
name = "rustmart"
version = "0.1.0"
authors = ["sheshbabu {&product.name}
{"$"}{&product.price}
{"Loading ..."}
+ }
+ } else if let Some(_) = self.state.get_products_error {
+ html! {
+
+ {"Error loading products! :("}
+
+ }
+ } else {
html! {
{format!("Cart Value: {:.2}", cart_value)}
{products}
}
+ }
}
}
Quite a number of changes, but you should be able to understand most
of them.
* We've replaced the hardcoded products list in create with an
empty array. We're also sending a message Msg::GetProducts to
update which calls the get_products method in the api module. The
returned FetchTask is stored in task.
* When the network request succeeds, the Msg::GetProductsSuccess
message is called with products list or Msg::GetProductsError
with error.
* These two messages set the products and get_products_error fields
in state respectively. They also set the get_products_loaded
state to true after the request is fulfilled.
* In the view method, we've used conditional rendering to render
either the loading view, error view or products view based on the
component's state.
[rust-wasm-]
Splitting into reusable components
Let's extract the "product card" component into its own module so we
can reuse it in other pages.
// src/components/product_card.rs
use crate::types::Product;
use yew::prelude::*;
pub struct ProductCard {
props: Props,
}
#[derive(Properties, Clone)]
pub struct Props {
pub product: Product,
pub on_add_to_cart: Callback<()>,
}
impl Component for ProductCard {
type Message = ();
type Properties = Props;
fn create(props: Self::Properties, _link: ComponentLink{&self.props.product.name}
{"$"}{&self.props.product.price}
-
-
+ {&product.name}
- {"$"}{&product.price}
-
-
- {format!("Cart Value: {:.2}", cart_value)}
- {products}
+
+
}
// src/components/product_card.rs
html! {
- {products}
- 
-
+ {&self.props.product.name}
- {"$"}{&self.props.product.price}
-
-
+
+
}
After adding the styles and a few more products, here's how the UI
looks like:
[image-4]
CSS changes are outside the scope of this post, please refer to the
GitHub repo.
Routing
In server rendered pages (Jinja, ERB, JSP etc), each page the user
sees is mapped to a different template file. For example, when the
user navigates to "/login", it's rendered in server using
"login.html" and when the user goes to "/settings", it's rendered
using "settings.html". Using unique urls for different UI pages is
also useful for bookmarking and sharing.
Since SPAs only have one html page (the "Single Page" in SPA), we
should be able to replicate the above behavior. This is done using a
Router. A Router maps different url paths (with query params,
fragments etc) to different page components and helps in navigating
between multiple pages without reloading.
For our application, we'll be using this mapping:
/ => HomePage
/product/:id => ProductDetailPage
Let's install yew-router:
[package]
name = "rustmart"
version = "0.1.0"
authors = ["sheshbabu {&self.props.product.name}
+ {"$"}{&self.props.product.price}
+
+
+
}
}
}
Notice how we used classes instead of class for Anchor.
We'll create files named static/products/1.json, static/products/
2.json etc with mock data:
{
"id": 1,
"name": "Apple",
"description": "An apple a day keeps the doctor away",
"image": "/products/apple.png",
"price": 3.65
}
Let's update the api.rs module with the new route:
use crate::types::Product;
use anyhow::Error;
use yew::callback::Callback;
use yew::format::{Json, Nothing};
use yew::services::fetch::{FetchService, FetchTask, Request, Response};
pub type FetchResponse{&self.props.product.name}
{"$"}{&self.props.product.price}
+ {&product.name}
{&product.description}
{"$"}{&product.price}
{"Loading ..."}
{"Error loading product! :("}
}
}
}
}
Very similar to the HomePage component. Let's also add this file to
the module tree:
// src/pages/mod.rs
mod home;
+ mod product_detail;
pub use home::Home;
+ pub use product_detail::ProductDetail;
This is how it looks like:
[image-5]
We can now move between multiple pages without refreshing the page!
State Management
One thing you might have noticed in the ProductDetail page is that
clicking on the "Add To Cart" button doesn't update the cart. This is
because the state that holds the list of products in cart
cart_products currently resides inside Home page component:
[rust-wasm-]
To share state between two components, we can either:
* Hoist the state to a common ancestor
* Move state to global app state
The App component is a common ancestor to both ProductDetail and
Home. We can move the cart_products state there and pass it as props
to ProductDetail and Home.
[rust-wasm-]
This works fine for shallow component hierarchies but when you have
deep component hierarchy (which is common in larger SPAs), you'll
need to pass this state through multiple layers of components (which
might not have use for this prop) to reach the desired node. This is
called "Prop Drilling".
You can see that cart_products is now passed from App to AddToCart
component via ProductDetail and Home even though they have no use for
this state. Imagine the same scenario with components many layers
deep.
This is the problem the global state solves. Here's how it would look
like:
[rust-wasm-]
Notice how there's a direct link between the components that need
this state and the global state.
Unfortunately, Yew doesn't seem to have a good solution for this. The
recommended solution is to use Agents for broadcasting state changes
via pubsub. This is something I stay away from as it gets messy fast.
I hope in future we see something similar to React's Context, Redux
or Mobx etc.
Let's solve our problem by hoisting the state.
Hoisting State
We'll be refactoring our code by moving cart_products state to App
and extracting Navbar and AtcButton as separate components:
[rust-wasm-]
// src/components/navbar.rs
use crate::types::CartProduct;
use yew::prelude::*;
pub struct Navbar {
props: Props,
}
#[derive(Properties, Clone)]
pub struct Props {
pub cart_products: Vec{&self.props.product.name}
{"$"}{&self.props.product.price}
{&product.name}
{&product.description}
{"$"}{&product.price}
-
+
-
}
}
}
}
Now we can finally add to cart from ProductDetail page and we can
also see the navbar in all pages
[image-6]
[image-4]
We've successfully built a SPA fully in Rust!
I've hosted the demo here and the code is in this GitHub repo. If you
have questions or suggestions, please contact me at sheshbabu [at]
gmail.com.
Conclusion
The Yew community has done a good job designing abstractions like
html!, Component etc so someone like me who's familiar with React can
immediately start being productive. It definitely has some rough
edges like FetchTask, lack of predictable state management and the
documentation is sparse, but has potential to become a good
alternative to React, Vue etc once these issues are fixed.
Thanks for reading! Feel free to follow me in Twitter for more posts
like this :)
Tagged under: Rust
Published on: 11 Aug 2020
(c) 2021 Sheshbabu Chinnakonda
{products}
-