Actually, instead of using a grid, it might be easier to just make boxes with fixed sizes and placement, and then rotate them with the contents, rather than dealing with the contents of each block separately 
Looks good enough for now!
Next I can work on the backend for a simple one-suit four-tile game 
Made some progress on turning the mahjong layout mockup into Yew components. The view is pretty much the same, but now I can specify the tiles outside of the view 
![let player_discards: Vec<Discard> = vec![
(Character(One), false),
(Character(Two), false),
(Character(Three), false),
(Character(Four), false),
(Character(Five), false),
(Character(Six), true),
(Character(One), false),
(Character(Two), false),
(Character(Three), false),
(Character(Four), false),
(Character(Five), false),
(Character(Six), false),
(Character(One), false),
(Character(Two), false),
(Character(Three), false),
(Character(Four), false),
(Character(Five), false),
(Character(Six), false),
]
.iter()
.map(|(tile, rotated)| Discard::new(*tile, *rotated))
.collect();
html! {
<>
<div class="board">
<div class="across-hand">
<div class="hand rotate-up">
<TileBacks count=13/>
</div>
</div>
<div class="across-discards">
<div class="discards rotate-up">
<Discards discards={across_discards}/>
</div>
</div>
<div class="left-hand">
<div class="hand rotate-left">
<TileBacks count=13/>
</div>
</div>](https://media.tech.lgbt/media_attachments/files/114/128/422/592/589/186/original/41a784cd1e8a9d78.png "let player_discards: Vec<Discard> = vec![
(Character(One), false),
(Character(Two), false),
(Character(Three), false),
(Character(Four), false),
(Character(Five), false),
(Character(Six), true),
(Character(One), false),
(Character(Two), false),
(Character(Three), false),
(Character(Four), false),
(Character(Five), false),
(Character(Six), false),
(Character(One), false),
(Character(Two), false),
(Character(Three), false),
(Character(Four), false),
(Character(Five), false),
(Character(Six), false),
]
.iter()
.map(|(tile, rotated)| Discard::new(*tile, *rotated))
.collect();
html! {
<>
<div class=\"board\">
<div class=\"across-hand\">
<div class=\"hand rotate-up\">
<TileBacks count=13/>
</div>
</div>
<div class=\"across-discards\">
<div class=\"discards rotate-up\">
<Discards discards={across_discards}/>
</div>
</div>
<div class=\"left-hand\">
<div class=\"hand rotate-left\">
<TileBacks count=13/>
</div>
</div>")
I guess it's a sign that I should just have separate "server" and "client" parts, and worry about a possible offline version later
I've separated some of the logic into a separate library, so that I can share it between the frontend and the backend.
Now I'm trying to figure out how to get Yew to make an async call (to communicate with a NATS server) 
One day I'll understand how Callbacks work in Yew. Today doesn't seem to be that day 
Okay, I got the tile id to bubble up when the tile is clicked 
(I've removed the tile shuffling for now)
And now I can pass the id over to the Tauri backend, which in turn can publish it to NATS
(It would be nice to publish directly from WebAssembly, but the nats crate doesn't compile to wasm yet)
![[aesdeef@fedora-book2 ~]$ nats subscribe "*"
16:49:38 Subscribing on *
[#1] Received on "messages"
78](https://media.tech.lgbt/media_attachments/files/114/139/874/675/283/567/original/c85c6f62fa79f66e.png "[aesdeef@fedora-book2 ~]$ nats subscribe \"*\"
16:49:38 Subscribing on *
[#1] Received on \"messages\"
78")