Jonathan Kelley
508c560320
This change switches back to the original `ctx<props>` syntax for commponents. This lets lifetime elision to remove the need to match exactly which lifetime (props or ctx) gets carried to the output. As such, `Props` is currently required to be static. It *is* possible to loosen this restriction, and will be done in the future, though only through adding metadata about the props through the Props derive macro. Implementing the IS_STATIC trait is unsafe, so the derive macro will do it through some heuristics. For now, this unlocks sharing vnodes from parents to children, enabling pass-thru components, fragments, portals, etc.
1.3 KiB
Components
Dioxus should look and feel just like writing functional React components. In Dioxus, there are no class components with lifecycles. All state management is done via hooks. This encourages logic reusability and lessens the burden on Dioxus to maintain a non-breaking lifecycle API.
#[derive(Properties, PartialEq)]
struct MyProps {
name: String
}
fn Example(ctx: Context<MyProps>) -> VNode {
html! { <div> "Hello {ctx.ctx.name}!" </div> }
}
Here, the Context object is used to access hook state, create subscriptions, and interact with the built-in context API. Props, children, and component APIs are accessible via the Context object. The functional component macro makes life more productive by inlining props directly as function arguments, similar to how Rocket parses URIs.
// A very terse component!
#[fc]
fn Example(ctx: Context, name: String) -> VNode {
html! { <div> "Hello {name}!" </div> }
}
// or
#[functional_component]
static Example: FC = |ctx, name: String| html! { <div> "Hello {name}!" </div> };
The final output of components must be a tree of VNodes. We provide an html macro for using JSX-style syntax to write these, though, you could use any macro, DSL, templating engine, or the constructors directly.