1
0

lib.rs 8.1 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200
  1. //! <div align="center">
  2. //! <h1>🌗🚀 📦 Dioxus</h1>
  3. //! <p>
  4. //! <strong>A concurrent, functional, virtual DOM for Rust</strong>
  5. //! </p>
  6. //! </div>
  7. //! Dioxus: a concurrent, functional, reactive virtual dom for any renderer in Rust.
  8. //!
  9. //! This crate aims to maintain a hook-based, renderer-agnostic framework for cross-platform UI development.
  10. //!
  11. //! ## Overview and Goals
  12. //! Dioxus' ultimate goal is to save you from writing new code when bringing your application to new platforms. We forsee
  13. //! a future where WebApps, Mobile Apps, Desktop Apps, and even AR apps can be written in the same language, ecosystem,
  14. //! and leverage the same platform-agnostic libraries.
  15. //!
  16. //! In this aim we chose to use a variety of techniques:
  17. //! - We use a VirtualDOM to abstract the true renderer from application logic.
  18. //! - We use functions as components to limit the API churn for greater stability.
  19. //! - We use hooks as state to allow reusable logic across the whole ecosystem.
  20. //! - We support an extensible and compile-time safe DSL for building interfaces.
  21. //!
  22. //! Our guiding stars (in order of priority):
  23. //! - Ergonomics
  24. //! - Reusability
  25. //! - Speed and memory efficiency
  26. //! - Safety
  27. //!
  28. //! ## Components
  29. //! The base unit of Dioxus is the `component`. Components can be easily created from just a function - no traits or
  30. //! proc macros required:
  31. //!
  32. //! ```
  33. //! use dioxus::prelude::*;
  34. //!
  35. //! fn Example(cx: Context<()>) -> DomTree {
  36. //! html! { <div> "Hello, world!" </div> }
  37. //! }
  38. //! ```
  39. //! Components need to take a "Context" parameter which is generic over some properties. This defines how the component can be used
  40. //! and what properties can be used to specify it in the VNode output. Components without properties may be generic over
  41. //! `()`, and components with properties must declare their properties as a struct:
  42. //!
  43. //! ```
  44. //! #[derive(Props)]
  45. //! struct Props { name: String }
  46. //!
  47. //! fn Example(cx: Context<Props>) -> DomTree {
  48. //! html! { <div> "Hello {cx.props.name}!" </div> }
  49. //! }
  50. //! ```
  51. //!
  52. //! Props that are valid for the `'pub static` lifetime automatically get memoized by Diouxs. This means the component won't
  53. //! re-render if its Props didn't change. However, Props that borrow data from their parent cannot be safely memoized, and
  54. //! will always re-render if their parent changes. To borrow data from a parent, your component needs to add explicit lifetimes,
  55. //! otherwise Rust will get confused about whether data is borrowed from either Props or Context. Since Dioxus manages
  56. //! these lifetimes internally, Context and your Props must share the same lifetime:
  57. //!
  58. //! ```
  59. //! #[derive(Props)]
  60. //! struct Props<'a> { name: &'a str }
  61. //!
  62. //! fn Example<'a>(cx: Context<'a, Props<'a>>) -> DomTree {
  63. //! html! { <div> "Hello {cx.props.name}!" </div> }
  64. //! }
  65. //! ```
  66. //!
  67. //!
  68. //!
  69. //! The lifetimes might look a little messy, but are crucially important for Dioxus's efficiency and overall ergonimics.
  70. //! Components can also be crafted as pub static closures, enabling type inference without all the type signature noise. However,
  71. //! closure-style components cannot work with borrowed data due to limitations in Rust's lifetime system.
  72. //!
  73. //! To use custom properties for components, you'll need to derive the `Props` trait for your properties. This trait
  74. //! exposes a compile-time correct builder pattern (similar to typed-builder) that can be used in the `rsx!` and `html!`
  75. //! macros to build components. Component props may have default fields notated by the `Default` attribute:
  76. //!
  77. //! ```
  78. //! #[derive(Props)]
  79. //! struct Props {
  80. //! name: String
  81. //!
  82. //! #[props(default = false)]
  83. //! checked: bool,
  84. //!
  85. //! #[props(default, setter(strip_option, into))]
  86. //! title: Option<String>
  87. //! }
  88. //! ```
  89. //!
  90. //! These flags roughly follow that of typed-builder, though tweaked to support the `Props` usecase.
  91. //!
  92. //! ## Hooks and State
  93. //! Dioxus uses hooks for state management. Hooks are a form of state persisted between calls of the function component.
  94. //!
  95. //! ```
  96. //! pub pub static Example: FC<()> = |(cx, props)|{
  97. //! let (val, set_val) = use_state(cx, || 0);
  98. //! cx.render(rsx!(
  99. //! button { onclick: move |_| set_val(val + 1) }
  100. //! ))
  101. //! }
  102. //! ````
  103. //!
  104. //! Instead of using a single struct to represent a component and its state, hooks use the "use_hook" building block
  105. //! which allows the persistence of data between function component renders. This primitive is exposed directly through
  106. //! the `Context` item:
  107. //! ```
  108. //! fn my_hook<'a>(cx: &impl Scoped<'a>) -> &'a String {
  109. //! cx.use_hook(
  110. //! // Initializer stores a value
  111. //! |hook_idx| String::new("stored_data"),
  112. //!
  113. //! // Runner returns the hook value every time the component is rendered
  114. //! |hook| &*hook,
  115. //!
  116. //! // Cleanup runs after the component is unmounted
  117. //! |hook| log::debug!("cleaning up hook with value {:#?}", hook)
  118. //! )
  119. //! }
  120. //! ```
  121. //! Under the hood, hooks store their data in a series of "memory cells". The first render defines the layout of these
  122. //! memory cells, and on each subsequent render, each `use_hook` call accesses its corresponding memory cell. If a hook
  123. //! accesses the wrong memory cell, `use_hook` will panic, and your app will crash. You can always use `try_use_hook` but
  124. //! these types of errors can be easily mitigated by following the rules of hooks:
  125. //!
  126. //! - Don’t call Hooks inside loops, conditions, or nested functions
  127. //! - Don't call hooks in changing order between renders
  128. //!
  129. //! Hooks provide a very powerful way to reuse stateful logic between components, simplify large complex components,
  130. //! and adopt more clear context subscription patterns to make components easier to read. The mechanics of hooks in Dioxus
  131. //! shares a great amount of similarity with React's hooks and there are many guides to hooks in React online.
  132. //!
  133. //! ## Supported Renderers
  134. //! Instead of being tightly coupled to a platform, browser, or toolkit, Dioxus implements a VirtualDOM object which
  135. //! can be consumed to draw the UI. The Dioxus VDOM is reactive and easily consumable by 3rd-party renderers via
  136. //! the `RealDom` trait. See [Implementing a Renderer](docs/8-custom-renderer.md), the `StringRenderer`, and `WebSys` render implementations for a template
  137. //! on how to implement your own custom renderer. We provide 1st-class support for these renderers:
  138. //!
  139. //! - dioxus-desktop (via WebView)
  140. //! - dioxus-web (via WebSys)
  141. //! - dioxus-ssr (via StringRenderer)
  142. //! - dioxus-liveview (SSR + WebSys)
  143. //!
  144. //! In the main `dioxus` crate, these are all accessible through configuration flags.
  145. //!
  146. //! ## Rendering to the Web
  147. //!
  148. //! Most dioxus apps will be initialized in roughly the same way. The `launch` method in `web` will immediately start a
  149. //! VirtualDOM and await it using `wasm_bindgen_futures`.
  150. //!
  151. //! An example app that starts a websys app and internally awaits works as follows:
  152. //!
  153. //! ```
  154. //! use dioxus::prelude::*;
  155. //! fn main() {
  156. //! dioxus::web::launch(Example);
  157. //! }
  158. //!
  159. //! pub pub static Example: FC<()> = |(cx, props)|{
  160. //! cx.render(rsx! {
  161. //! div { "Hello World!" }
  162. //! })
  163. //! };
  164. //! ```
  165. //!
  166. //! In reality, you'll want to integrate analytics, logging, crash-protection and more.
  167. // Just a heads-up, the core functionality of dioxus rests in Dioxus-Core. This crate just wraps a bunch of utilities
  168. // together and exports their namespaces to something predicatble.
  169. #[cfg(feature = "core")]
  170. pub use dioxus_core as core;
  171. #[cfg(feature = "core")]
  172. pub use dioxus_core::events;
  173. #[cfg(feature = "web")]
  174. pub use dioxus_web as web;
  175. #[cfg(feature = "mobile")]
  176. pub use dioxus_mobile as mobile;
  177. #[cfg(feature = "ssr")]
  178. pub use dioxus_ssr as ssr;
  179. #[cfg(feature = "hooks")]
  180. pub use dioxus_hooks as hooks;
  181. #[cfg(feature = "desktop")]
  182. pub use dioxus_desktop as desktop;
  183. pub mod debug {}
  184. pub mod prelude {
  185. //! A glob import that includes helper types like FC, rsx!, html!, and required traits
  186. pub use dioxus_core::prelude::*;
  187. pub use dioxus_core_macro::{format_args_f, html, rsx, Props};
  188. pub use dioxus_elements::{GlobalAttributes, SvgAttributes};
  189. pub use dioxus_hooks::*;
  190. pub use dioxus_html as dioxus_elements;
  191. }