{
  "path": "/posts/calendar-tetris-pt-3",
  "site": "at://did:plc:pans3xjam4khj7y54dx7gtfg/site.standard.publication/3mdqevmg6w32c",
  "tags": [
    "rust",
    "petgraph",
    "graphs",
    "WASM"
  ],
  "$type": "site.standard.document",
  "title": "Calendar Tetris: UI is a Side-effect",
  "description": "Building the calendar stacking UI in Rust with Dioxus, my favorite UI library for cross platform development.",
  "publishedAt": "2023-04-29T23:32:15.000Z",
  "textContent": "Live | Repository\n\nUI is a tedious side-effect, albeit a desired one.\nAs I wanted to write the backend for the calendar stacking algorithm in Rust, I had a few options: Write the UI in Javascript and interact with the calendar stacking algorithm via a JS object or write the UI in Rust using some sort of framework that provides WASM bindings.\nAs I'd already built the app once in React I didn't want to rebuild the same thing twice. Another reason is that crossing JS-WASM boundary comes with its own set of problems (that's a tale for another time). I looked into Dioxus and Leptos, both sound like names of Pokemon.\n\nThe documentation for Leptos was a bit sparse, and I ran into a few problems getting their example project to run. I do want to check out fine grained reactivity at some point but I'll come back to it later when I have some more time.\nDioxus on the other hand had great documentation, and getting the example project up and running took very little time.\nDioxus is very similar to React, which is what I've been working with for the last 8 years so it was pretty quick to get a hang of.\n\nInitial State\nDioxus lets you store state between component renders similar to React's hooks.\n\nInteractivity",
  "canonicalUrl": "https://afloat.boats/posts/calendar-tetris-pt-3"
}