Jonathan Kelley 8fcd001677 Feat: update component so build passes 4 gadi atpakaļ
..
.vscode ea2aa4b0c9 Feat: event loop 4 gadi atpakaļ
examples 8fcd001677 Feat: update component so build passes 4 gadi atpakaļ
old fcd68e61d2 Feat: listeners now have scope information 4 gadi atpakaļ
src 37f5a7ad33 Feat: wire up props macro 4 gadi atpakaļ
tests 83451372aa Feat: clean up code 4 gadi atpakaļ
Cargo.toml cb74d70f83 wip: broken, but solved 4 gadi atpakaļ
README.md c8bb392cad Feat: view -> render 4 gadi atpakaļ
architecture.md c9d95dd1dc Feat: move out scope into its own file 4 gadi atpakaļ

README.md

Dioxus-core

This is the core crate for the Dioxus Virtual DOM. This README will focus on the technical design and layout of this Virtual DOM implementation. If you want to read more about using Dioxus, then check out the Dioxus crate, documentation, and website.

Internals

Dioxus-core builds off the many frameworks that came before it. Notably, Dioxus borrows these concepts:

  • React: hooks, concurrency, suspense
  • Dodrio: bump allocation, double buffering, and source code for nodes + NodeBuilder
  • Percy: html! macro architecture, platform-agnostic edits
  • Yew: passion and inspiration ❤️

Goals

We have big goals for Dioxus. The final implementation must:

  • Be fast. Allocators are typically slow in WASM/Rust, so we should have a smart way of allocating.
  • Be extremely memory efficient. Servers should handle tens of thousands of simultaneous VDoms with no problem.
  • Be concurrent. Components should be able to pause rendering using a threading mechanism.
  • Be "remote". Edit lists should be separate from the Renderer implementation.
  • Support SSR. VNodes should render to a string that can be served via a web server.
  • Be "live". Components should be able to be both server rendered and client rendered without needing frontend APIs.
  • Be modular. Components and hooks should be work anywhere without worrying about target platform.

Optimizations

  • Support a pluggable allocation strategy that makes VNode creation very fast
  • Support lazy DomTrees (ie DomTrees that are not actually created when the html! macro is used)
  • Support advanced diffing strategies (patience, Myers, etc)

Design Quirks

  • Use of "Context" as a way of mitigating threading issues and the borrow checker. (JS relies on globals)
  • html! is lazy - needs to be used with a partner function to actually allocate the html. (Good be a good thing or a bad thing)

    let text = TextRenderer::render(html! {<div>"hello world"</div>});
    // <div>hello world</div>
    
    
    fn main() {
    tide::new()
        .get("blah", serve_app("../"))
        .get("blah", ws_handler(serve_app))
    }
    
    
    fn serve_app(ctx: &Context<()>) -> VNode {
    let livecontext = LiveContext::new()
        .with_handler("graph", graph_component)
        .with_handler("graph", graph_component)
        .with_handler("graph", graph_component)
        .with_handler("graph", graph_component)
        .with_handler("graph", graph_component)
        .with_handler("graph", graph_component)
        .build();
    
    ctx.render(html! {
        <LiveContext ctx={livecontext}>
            <App />
        </ LiveContext>
    })
    }