>();
-view! {
- "+1"
- {move || state.with(|state| state.name.clone())}
-}
-```
-
-In this example, clicking the button will cause the text inside `` to be updated, cloning `state.name` again! Because signals are the atomic unit of reactivity, updating any field of the signal triggers updates to everything that depends on the signal.
-
-There’s a better way. You can take fine-grained, reactive slices by using [`create_memo`](https://docs.rs/leptos/latest/leptos/fn.create_memo.html) or [`create_slice`](https://docs.rs/leptos/latest/leptos/fn.create_slice.html) (which uses `create_memo` but also provides a setter). “Memoizing” a value means creating a new reactive value which will only update when it changes. “Memoizing a slice” means creating a new reactive value which will only update when some field of the state struct updates.
-
-Here, instead of reading from the state signal directly, we create “slices” of that state with fine-grained updates via `create_slice`. Each slice signal only updates when the particular piece of the larger struct it accesses updates. This means you can create a single root signal, and then take independent, fine-grained slices of it in different components, each of which can update without notifying the others of changes.
-
-```rust
-/// A component that updates the count in the global state.
-#[component]
-fn GlobalStateCounter() -> impl IntoView {
- let state = expect_context::>();
-
- // `create_slice` lets us create a "lens" into the data
- let (count, set_count) = create_slice(
-
- // we take a slice *from* `state`
- state,
- // our getter returns a "slice" of the data
- |state| state.count,
- // our setter describes how to mutate that slice, given a new value
- |state, n| state.count = n,
- );
-
- view! {
-
-
- "Increment Global Count"
-
- "Count is: " {count}
-
- }
-}
-```
-
-Clicking this button only updates `state.count`, so if we create another slice
-somewhere else that only takes `state.name`, clicking the button won’t cause
-that other slice to update. This allows you to combine the benefits of a top-down
-data flow and of fine-grained reactive updates.
-
-> **Note**: There are some significant drawbacks to this approach. Both signals and memos need to own their values, so a memo will need to clone the field’s value on every change. The most natural way to manage state in a framework like Leptos is always to provide signals that are as locally-scoped and fine-grained as they can be, not to hoist everything up into global state. But when you _do_ need some kind of global state, `create_slice` can be a useful tool.
-
-[Click to open CodeSandbox.](https://codesandbox.io/p/sandbox/15-global-state-0-5-8c2ff6?file=%2Fsrc%2Fmain.rs%3A1%2C2)
-
-
-
-
-CodeSandbox Source
-
-```rust
-use leptos::*;
-
-// So far, we've only been working with local state in components
-// We've only seen how to communicate between parent and child components
-// But there are also more general ways to manage global state
-//
-// The three best approaches to global state are
-// 1. Using the router to drive global state via the URL
-// 2. Passing signals through context
-// 3. Creating a global state struct and creating lenses into it with `create_slice`
-//
-// Option #1: URL as Global State
-// The next few sections of the tutorial will be about the router.
-// So for now, we'll just look at options #2 and #3.
-
-// Option #2: Pass Signals through Context
-//
-// In virtual DOM libraries like React, using the Context API to manage global
-// state is a bad idea: because the entire app exists in a tree, changing
-// some value provided high up in the tree can cause the whole app to render.
-//
-// In fine-grained reactive libraries like Leptos, this is simply not the case.
-// You can create a signal in the root of your app and pass it down to other
-// components using provide_context(). Changing it will only cause rerendering
-// in the specific places it is actually used, not the whole app.
-#[component]
-fn Option2() -> impl IntoView {
- // here we create a signal in the root that can be consumed
- // anywhere in the app.
- let (count, set_count) = create_signal(0);
- // we'll pass the setter to specific components,
- // but provide the count itself to the whole app via context
- provide_context(count);
-
- view! {
- "Option 2: Passing Signals"
- // SetterButton is allowed to modify the count
-
-
- }
-}
-
-/// A button that increments our global counter.
-#[component]
-fn SetterButton(set_count: WriteSignal) -> impl IntoView {
- view! {
-
-
- "Increment Global Count"
-
-
- }
-}
-
-/// A component that does some "fancy" math with the global count
-#[component]
-fn FancyMath() -> impl IntoView {
- // here we consume the global count signal with `use_context`
- let count = use_context::>()
- // we know we just provided this in the parent component
- .expect("there to be a `count` signal provided");
- let is_even = move || count() & 1 == 0;
-
- view! {
-
- "The number "
- {count}
- {move || if is_even() {
- " is"
- } else {
- " is not"
- }}
- " even."
-
- }
-}
-
-/// A component that shows a list of items generated from the global count.
-#[component]
-fn ListItems() -> impl IntoView {
- // again, consume the global count signal with `use_context`
- let count = use_context::>().expect("there to be a `count` signal provided");
-
- let squares = move || {
- (0..count())
- .map(|n| view! { {n}"2" " is " {n * n} })
- .collect::>()
- };
-
- view! {
-
- }
-}
-
-// Option #3: Create a Global State Struct
-//
-// You can use this approach to build a single global data structure
-// that holds the state for your whole app, and then access it by
-// taking fine-grained slices using `create_slice` or `create_memo`,
-// so that changing one part of the state doesn't cause parts of your
-// app that depend on other parts of the state to change.
-
-#[derive(Default, Clone, Debug)]
-struct GlobalState {
- count: u32,
- name: String,
-}
-
-#[component]
-fn Option3() -> impl IntoView {
- // we'll provide a single signal that holds the whole state
- // each component will be responsible for creating its own "lens" into it
- let state = create_rw_signal(GlobalState::default());
- provide_context(state);
-
- view! {
- "Option 3: Passing Signals"
-
-
"Current Global State"
-
- {move || {
- format!("{:#?}", state.get())
- }}
-
-
-
- }
-}
-
-/// A component that updates the count in the global state.
-#[component]
-fn GlobalStateCounter() -> impl IntoView {
- let state = use_context::>().expect("state to have been provided");
-
- // `create_slice` lets us create a "lens" into the data
- let (count, set_count) = create_slice(
-
- // we take a slice *from* `state`
- state,
- // our getter returns a "slice" of the data
- |state| state.count,
- // our setter describes how to mutate that slice, given a new value
- |state, n| state.count = n,
- );
-
- view! {
-
-
- "Increment Global Count"
-
- "Count is: " {count}
-
- }
-}
-
-/// A component that updates the count in the global state.
-#[component]
-fn GlobalStateInput() -> impl IntoView {
- let state = use_context::>().expect("state to have been provided");
-
- // this slice is completely independent of the `count` slice
- // that we created in the other component
- // neither of them will cause the other to rerun
- let (name, set_name) = create_slice(
- // we take a slice *from* `state`
- state,
- // our getter returns a "slice" of the data
- |state| state.name.clone(),
- // our setter describes how to mutate that slice, given a new value
- |state, n| state.name = n,
- );
-
- view! {
-
- "Name is: " {name}
-
- }
-}
-// This `main` function is the entry point into the app
-// It just mounts our component to the
-// Because we defined it as `fn App`, we can now use it in a
-// template as
-
+`, not `T`: because it’s always possible that your resource is still loading.
-
-So, you can show the current state of a resource in your view:
-
-```rust
-let once = create_resource(|| (), |_| async move { load_data().await });
-view! {
- "My Data"
- {move || match once.get() {
- None => view! { "Loading..."
}.into_view(),
- Some(data) => view! { ` indicating whether the resource is currently loading or not.
-
-[Click to open CodeSandbox.](https://codesandbox.io/p/sandbox/10-resources-0-5-x6h5j6?file=%2Fsrc%2Fmain.rs%3A2%2C3)
-
-
-
-
-CodeSandbox Source
-
-```rust
-use gloo_timers::future::TimeoutFuture;
-use leptos::*;
-
-// Here we define an async function
-// This could be anything: a network request, database read, etc.
-// Here, we just multiply a number by 10
-async fn load_data(value: i32) -> i32 {
- // fake a one-second delay
- TimeoutFuture::new(1_000).await;
- value * 10
-}
-
-#[component]
-fn App() -> impl IntoView {
- // this count is our synchronous, local state
- let (count, set_count) = create_signal(0);
-
- // create_resource takes two arguments after its scope
- let async_data = create_resource(
- // the first is the "source signal"
- count,
- // the second is the loader
- // it takes the source signal's value as its argument
- // and does some async work
- |value| async move { load_data(value).await },
- );
- // whenever the source signal changes, the loader reloads
-
- // you can also create resources that only load once
- // just return the unit type () from the source signal
- // that doesn't depend on anything: we just load it once
- let stable = create_resource(|| (), |_| async move { load_data(1).await });
-
- // we can access the resource values with .get()
- // this will reactively return None before the Future has resolved
- // and update to Some(T) when it has resolved
- let async_result = move || {
- async_data
- .get()
- .map(|value| format!("Server returned {value:?}"))
- // This loading state will only show before the first load
- .unwrap_or_else(|| "Loading...".into())
- };
-
- // the resource's loading() method gives us a
- // signal to indicate whether it's currently loading
- let loading = async_data.loading();
- let is_loading = move || if loading() { "Loading..." } else { "Idle." };
-
- view! {
-
- "Click me"
-
-
- "stable"": " {move || stable.get()}
-
-
- "count"": " {count}
-
-
- "async_value"": "
- {async_result}
-
- }
-}
-
-fn main() {
- leptos::mount_to_body(App)
-}
-```
-
-
-
+"My Data"
- {move || match once.get() {
- None => view! { "Loading..."
}.into_view(),
- Some(data) => view! { "My Data"
- {move || match (a.get(), b.get()) {
- (Some(a), Some(b)) => view! {
- "Loading..."
}.into_view()
- }}
-}
-```
-
-That’s not _so_ bad, but it’s kind of annoying. What if we could invert the flow of control?
-
-The [`"My Data"
- "Loading..."
}
- >
- "My Data"
- "A"
- {move || {
- a.get()
- .map(|a| view! { "B"
- {move || {
- b.get()
- .map(|b| view! {
- // you receive the data by reference and can use it in your view here
- {*data} " little monkeys, jumping on the bed."
-
-}
-```
-
-[Click to open CodeSandbox.](https://codesandbox.io/p/sandbox/11-suspense-0-5-qzpgqs?file=%2Fsrc%2Fmain.rs%3A1%2C1)
-
-
-
-
-CodeSandbox Source
-
-```rust
-use gloo_timers::future::TimeoutFuture;
-use leptos::*;
-
-async fn important_api_call(name: String) -> String {
- TimeoutFuture::new(1_000).await;
- name.to_ascii_uppercase()
-}
-
-#[component]
-fn App() -> impl IntoView {
- let (name, set_name) = create_signal("Bill".to_string());
-
- // this will reload every time `name` changes
- let async_data = create_resource(
-
- name,
- |name| async move { important_api_call(name).await },
- );
-
- view! {
- "name:" {name}
- "Loading..." }
- >
- // the children will be rendered once initially,
- // and then whenever any resources has been resolved
-
- "Your shouting name is "
- {move || async_data.get()}
-
-
- }
-}
-
-fn main() {
- leptos::mount_to_body(App)
-}
-```
-
-
-
+
-CodeSandbox Source
-
-```rust
-use gloo_timers::future::TimeoutFuture;
-use leptos::*;
-
-async fn important_api_call(id: usize) -> String {
- TimeoutFuture::new(1_000).await;
- match id {
- 0 => "Alice",
- 1 => "Bob",
- 2 => "Carol",
- _ => "User not found",
- }
- .to_string()
-}
-
-#[component]
-fn App() -> impl IntoView {
- let (tab, set_tab) = create_signal(0);
-
- // this will reload every time `tab` changes
- let user_data = create_resource(tab, |tab| async move { important_api_call(tab).await });
-
- view! {
-
-
- "Tab A"
-
-
- "Tab B"
-
-
- "Tab C"
-
- {move || if user_data.loading().get() {
- "Loading..."
- } else {
- ""
- }}
-
- "Loading..." }
- >
-
- {move || user_data.read()}
-
-
- }
-}
-
-fn main() {
- leptos::mount_to_body(App)
-}
-```
-
-
-
+>
-let pending = add_todo_action.pending(); // ReadSignal
-let todo_id = add_todo_action.value(); // RwSignal>
-```
-
-This makes it easy to track the current state of your request, show a loading indicator, or do “optimistic UI” based on the assumption that the submission will succeed.
-
-```rust
-let input_ref = create_node_ref::{move || pending().then("Loading...")}
-}
-```
-
-Now, there’s a chance this all seems a little over-complicated, or maybe too restricted. I wanted to include actions here, alongside resources, as the missing piece of the puzzle. In a real Leptos app, you’ll actually most often use actions alongside server functions, [`create_server_action`](https://docs.rs/leptos/latest/leptos/fn.create_server_action.html), and the [`
-CodeSandbox Source
-
-```rust
-use gloo_timers::future::TimeoutFuture;
-use leptos::{html::Input, *};
-use uuid::Uuid;
-
-// Here we define an async function
-// This could be anything: a network request, database read, etc.
-// Think of it as a mutation: some imperative async action you run,
-// whereas a resource would be some async data you load
-async fn add_todo(text: &str) -> Uuid {
- _ = text;
- // fake a one-second delay
- TimeoutFuture::new(1_000).await;
- // pretend this is a post ID or something
- Uuid::new_v4()
-}
-
-#[component]
-fn App() -> impl IntoView {
- // an action takes an async function with single argument
- // it can be a simple type, a struct, or ()
- let add_todo = create_action(|input: &String| {
- // the input is a reference, but we need the Future to own it
- // this is important: we need to clone and move into the Future
- // so it has a 'static lifetime
- let input = input.to_owned();
- async move { add_todo(&input).await }
- });
-
- // actions provide a bunch of synchronous, reactive variables
- // that tell us different things about the state of the action
- let submitted = add_todo.input();
- let pending = add_todo.pending();
- let todo_id = add_todo.value();
-
- let input_ref = create_node_ref::{move || pending().then(|| "Loading...")}
-
- "Submitted: "
- {move || format!("{:#?}", submitted())}
-
-
- "Pending: "
- {move || format!("{:#?}", pending())}
-
-
- "Todo ID: "
- {move || format!("{:#?}", todo_id())}
-
- }
-}
-
-fn main() {
- leptos::mount_to_body(App)
-}
-```
-
-
-
+
-> rustup override set nightly
-> ```
->
-> [See here for more details.](https://doc.rust-lang.org/book/appendix-07-nightly-rust.html)
->
-> If you’d rather use stable Rust with Leptos, you can do that too. In the guide and examples, you’ll just use the [`ReadSignal::get()`](https://docs.rs/leptos/latest/leptos/struct.ReadSignal.html#impl-SignalGet%3CT%3E-for-ReadSignal%3CT%3E) and [`WriteSignal::set()`](https://docs.rs/leptos/latest/leptos/struct.WriteSignal.html#impl-SignalGet%3CT%3E-for-ReadSignal%3CT%3E) methods instead of calling signal getters and setters as functions.
-
-Make sure you've added the `wasm32-unknown-unknown` target so that Rust can compile your code to WebAssembly to run in the browser.
-
-```bash
-rustup target add wasm32-unknown-unknown
-```
-
-Create a simple `index.html` in the root of the `leptos-tutorial` directory
-
-```html
-
-
-
-
-
-```
-
-And add a simple “Hello, world!” to your `main.rs`
-
-```rust
-use leptos::*;
-
-fn main() {
- mount_to_body(|| view! { "Hello, world!"
})
-}
-```
-
-Your directory structure should now look something like this
-
-```
-leptos_tutorial
-├── src
-│ └── main.rs
-├── Cargo.toml
-├── index.html
-```
-
-Now run `trunk serve --open` from the root of the `leptos-tutorial` directory.
-Trunk should automatically compile your app and open it in your default browser.
-If you make edits to `main.rs`, Trunk will recompile your source code and
-live-reload the page.
-
-
-Welcome to the world of UI development with Rust and WebAssembly (WASM), powered by Leptos and Trunk!
-
----
-
-Now before we get started building your first real UI's with Leptos, there are a couple of things you might want to know to help make your experience with Leptos just a little bit easier.
\ No newline at end of file
+(fallback: F, children: ChildrenFn) -> impl IntoView
-where
- F: Fn() -> IV + 'static,
- IV: IntoView,
-{
- view! {
-
-
- {children()}
-
-
- }
-}
-```
-
-This is pretty straightforward: when the user is logged in, we want to show `children`. If the user is not logged in, we want to show `fallback`. And while we’re waiting to find out, we just render `()`, i.e., nothing.
-
-In other words, we want to pass the children of `(fallback: F, children: ChildrenFn) -> impl IntoView
-where
- F: Fn() -> IV + 'static,
- IV: IntoView,
-{
- let fallback = store_value(fallback);
- let children = store_value(children);
- view! {
-
-
- {children.with_value(|children| children())}
-
-
- }
-}
-```
-
-At the top level, we store both `fallback` and `children` in the reactive scope owned by `LoggedIn`. Now we can simply move those references down through the other layers into the `
-
-
-
-
- }
-}
-
-#[component]
-pub fn Outer(children: ChildrenFn) -> impl IntoView {
- children()
-}
-
-#[component]
-pub fn Inner(children: ChildrenFn) -> impl IntoView {
- children()
-}
-
-#[component]
-pub fn Inmost(name: String) -> impl IntoView {
- view! {
- {name}
- }
-}
-```
-
-Even with `name=name.clone()`, this gives the error
-
-```
-cannot move out of `name`, a captured variable in an `Fn` closure
-```
-
-It’s captured through multiple levels of children that need to run more than once, and there’s no obvious way to clone it _into_ the children.
-
-In this case, the `clone:` syntax comes in handy. Calling `clone:name` will clone `name` _before_ moving it into `
-
-
-
-
-}
-```
-
-These issues can be a little tricky to understand or debug, because of the opacity of the `view` macro. But in general, they can always be solved.
+
- "Welcome to Leptos with Tailwind"
- "Tailwind will scan your Rust files for Tailwind class names and compile them into a CSS file."
-
- {move || if count() == 0 {
- "Click me!".to_string()
- } else {
- count().to_string()
- }}
-
-
- }
-}
-```
-
-It can be a little complicated to set up the Tailwind integration at first, but you can check out our two examples of how to use Tailwind with a [client-side-rendered `trunk` application](https://github.com/leptos-rs/leptos/tree/main/examples/tailwind_csr) or with a [server-rendered `cargo-leptos` application](https://github.com/leptos-rs/leptos/tree/main/examples/tailwind_actix). `cargo-leptos` also has some [built-in Tailwind support](https://github.com/leptos-rs/cargo-leptos#site-parameters) that you can use as an alternative to Tailwind’s CLI.
-
-## Stylers: Compile-time CSS Extraction
-
-[Stylers](https://github.com/abishekatp/stylers) is a compile-time scoped CSS library that lets you declare scoped CSS in the body of your component. Stylers will extract this CSS at compile time into CSS files that you can then import into your app, which means that it doesn’t add anything to the WASM binary size of your application.
-
-This allows you to write components like this:
-
-```rust
-use stylers::style;
-
-#[component]
-pub fn App() -> impl IntoView {
- let styler_class = style! { "App",
- ##two{
- color: blue;
- }
- div.one{
- color: red;
- content: raw_str(r#"\hello"#);
- font: "1.3em/1.2" Arial, Helvetica, sans-serif;
- }
- div {
- border: 1px solid black;
- margin: 25px 50px 75px 100px;
- background-color: lightblue;
- }
- h2 {
- color: purple;
- }
- @media only screen and (max-width: 1000px) {
- h3 {
- background-color: lightblue;
- color: blue
- }
- }
- };
-
- view! { class = styler_class,
-
-
"Hello"
- "World"
- "and"
- "friends!"
-
- }
-}
-```
-
-## Styled: Runtime CSS Scoping
-
-[Styled](https://github.com/eboody/styled) is a runtime scoped CSS library that integrates well with Leptos. It lets you declare scoped CSS in the body of your component function, and then applies those styles at runtime.
-
-```rust
-use styled::style;
-
-#[component]
-pub fn MyComponent() -> impl IntoView {
- let styles = style!(
- div {
- background-color: red;
- color: white;
- }
- );
-
- styled::view! { styles,
- "This text should be red with white text."
- }
-}
-```
-
-## Contributions Welcome
-
-Leptos has no opinions on how you style your website or app, but we’re very happy to provide support to any tools you’re trying to create to make it easier. If you’re working on a CSS or styling approach that you’d like to add to this list, please let us know!
+"Welcome to Leptos!"
- "Click Me: " {count}
- }
-}
-```
-
-Here’s the interactive version:
-
-```rust
-#[island]
-fn HomePage() -> impl IntoView {
- // Creates a reactive value to update the button
- let (count, set_count) = create_signal(0);
- let on_click = move |_| set_count.update(|count| *count += 1);
-
- view! {
- "Welcome to Leptos!"
- "Click Me: " {count}
- }
-}
-```
-
-Now when I click the button, it works!
-
-The `#[island]` macro works exactly like the `#[component]` macro, except that in islands mode, it designates this as an interactive island. If we check the binary size again, this is 166kb uncompressed in release mode; much larger than the 24kb totally static version, but much smaller than the 355kb fully-hydrated version.
-
-If you open up the source for the page now, you’ll see that your `HomePage` island has been rendered as a special `` HTML element which specifies which component should be used to hydrate it:
-
-```html
-
- Welcome to Leptos!
-
- Click Me:
- 11
-
-
-```
-
-The typical Leptos hydration keys and markers are only present inside the island, only the island is hydrated.
-
-## Using Islands Effectively
-
-Remember that _only_ code within an `#[island]` needs to be compiled to WASM and shipped to the browser. This means that islands should be as small and specific as possible. My `HomePage`, for example, would be better broken apart into a regular component and an island:
-
-```rust
-#[component]
-fn HomePage() -> impl IntoView {
- view! {
- "Welcome to Leptos!"
- "Click Me: " {count}
- }
-}
-```
-
-Now the `` doesn’t need to be included in the client bundle, or hydrated. This seems like a silly distinction now; but note that you can now add as much inert HTML content as you want to the `HomePage` itself, and the WASM binary size will remain exactly the same.
-
-In regular hydration mode, your WASM binary size grows as a function of the size/complexity of your app. In islands mode, your WASM binary grows as a function of the amount of interactivity in your app. You can add as much non-interactive content as you want, outside islands, and it will not increase that binary size.
-
-## Unlocking Superpowers
-
-So, this 50% reduction in WASM binary size is nice. But really, what’s the point?
-
-The point comes when you combine two key facts:
-
-1. Code inside `#[component]` functions now _only_ runs on the server.
-2. Children and props can be passed from the server to islands, without being included in the WASM binary.
-
-This means you can run server-only code directly in the body of a component, and pass it directly into the children. Certain tasks that take a complex blend of server functions and Suspense in fully-hydrated apps can be done inline in islands.
-
-We’re going to rely on a third fact in the rest of this demo:
-
-3. Context can be passed between otherwise-independent islands.
-
-So, instead of our counter demo, let’s make something a little more fun: a tabbed interface that reads data from files on the server.
-
-## Passing Server Children to Islands
-
-One of the most powerful things about islands is that you can pass server-rendered children into an island, without the island needing to know anything about them. Islands hydrate their own content, but not children that are passed to them.
-
-As Dan Abramov of React put it (in the very similar context of RSCs), islands aren’t really islands: they’re donuts. You can pass server-only content directly into the “donut hole,” as it were, allowing you to create tiny atolls of interactivity, surrounded on _both_ sides by the sea of inert server HTML.
-
-> In the demo code included below, I added some styles to show all server content as a light-blue “sea,” and all islands as light-green “land.” Hopefully that will help picture what I’m talking about!
-
-To continue with the demo: I’m going to create a `Tabs` component. Switching between tabs will require some interactivity, so of course this will be an island. Let’s start simple for now:
-
-```rust
-#[island]
-fn Tabs(labels: Vec) -> impl IntoView {
- let buttons = labels
- .into_iter()
- .map(|label| view! { {label} })
- .collect_view();
- view! {
-
- {buttons}
-
- }
-}
-```
-
-Oops. This gives me an error
-
-```
-error[E0463]: can't find crate for `serde`
- --> src/app.rs:43:1
- |
-43 | #[island]
- | ^^^^^^^^^ can't find crate
-```
-
-Easy fix: let’s `cargo add serde --features=derive`. The `#[island]` macro wants to pull in `serde` here because it needs to serialize and deserialize the `labels` prop.
-
-Now let’s update the `HomePage` to use `Tabs`.
-
-```rust
-#[component]
-fn HomePage() -> impl IntoView {
- // these are the files we’re going to read
- let files = ["a.txt", "b.txt", "c.txt"];
- // the tab labels will just be the file names
- let labels = files.iter().copied().map(Into::into).collect();
- view! {
- "Welcome to Leptos!"
- "Click any of the tabs below to read a recipe."
- {children()}
- }
-}
-```
-
-Each tab, for now will just be a `` wrapping its children.
-
-Our `Tabs` component will also get some children: for now, let’s just show them all.
-
-```rust
-#[island]
-fn Tabs(labels: Vec
, children: Children) -> impl IntoView {
- let buttons = labels
- .into_iter()
- .map(|label| view! { {label} })
- .collect_view();
- view! {
-
- {buttons}
-
- {children()}
- }
-}
-```
-
-Okay, now let’s go back into the `HomePage`. We’re going to create the list of tabs to put into our tab box.
-
-```rust
-#[component]
-fn HomePage() -> impl IntoView {
- let files = ["a.txt", "b.txt", "c.txt"];
- let labels = files.iter().copied().map(Into::into).collect();
- let tabs = move || {
- files
- .into_iter()
- .enumerate()
- .map(|(index, filename)| {
- let content = std::fs::read_to_string(filename).unwrap();
- view! {
-
- {filename.to_string()}
- {content}
-
- }
- })
- .collect_view()
- };
-
- view! {
- "Welcome to Leptos!"
- "Click any of the tabs below to read a recipe."
-
- {tabs()}
-
- }
-}
-```
-
-Uh... What?
-
-If you’re used to using Leptos, you know that you just can’t do this. All code in the body of components has to run on the server (to be rendered to HTML) and in the browser (to hydrate), so you can’t just call `std::fs`; it will panic, because there’s no access to the local filesystem (and certainly not to the server filesystem!) in the browser. This would be a security nightmare!
-
-Except... wait. We’re in islands mode. This `HomePage` component _really does_ only run on the server. So we can, in fact, just use ordinary server code like this.
-
-> **Is this a dumb example?** Yes! Synchronously reading from three different local files in a `.map()` is not a good choice in real life. The point here is just to demonstrate that this is, definitely, server-only content.
-
-Go ahead and create three files in the root of the project called `a.txt`, `b.txt`, and `c.txt`, and fill them in with whatever content you’d like.
-
-Refresh the page and you should see the content in the browser. Edit the files and refresh again; it will be updated.
-
-You can pass server-only content from a `#[component]` into the children of an `#[island]`, without the island needing to know anything about how to access that data or render that content.
-
-**This is really important.** Passing server `children` to islands means that you can keep islands small. Ideally, you don’t want to slap and `#[island]` around a whole chunk of your page. You want to break that chunk out into an interactive piece, which can be an `#[island]`, and a bunch of additional server content that can be passed to that island as `children`, so that the non-interactive subsections of an interactive part of the page can be kept out of the WASM binary.
-
-## Passing Context Between Islands
-
-These aren’t really “tabs” yet: they just show every tab, all the time. So let’s add some simple logic to our `Tabs` and `Tab` components.
-
-We’ll modify `Tabs` to create a simple `selected` signal. We provide the read half via context, and set the value of the signal whenever someone clicks one of our buttons.
-
-```rust
-#[island]
-fn Tabs(labels: Vec, children: Children) -> impl IntoView {
- let (selected, set_selected) = create_signal(0);
- provide_context(selected);
-
- let buttons = labels
- .into_iter()
- .enumerate()
- .map(|(index, label)| view! {
-
- {label}
-
- })
- .collect_view();
-// ...
-```
-
-And let’s modify the `Tab` island to use that context to show or hide itself:
-
-```rust
-#[island]
-fn Tab(children: Children) -> impl IntoView {
- let selected = expect_context::>();
- view! {
-
-// ...
-```
-
-Now the tabs behave exactly as I’d expect. `Tabs` passes the signal via context to each `Tab`, which uses it to determine whether it should be open or not.
-
-> That’s why in `HomePage`, I made `let tabs = move ||` a function, and called it like `{tabs()}`: creating the tabs lazily this way meant that the `Tabs` island would already have provided the `selected` context by the time each `Tab` went looking for it.
-
-Our complete tabs demo is about 220kb uncompressed: not the smallest demo in the world, but still about a third smaller than the counter button! Just for kicks, I built the same demo without islands mode, using `#[server]` functions and `Suspense`. and it was 429kb. So again, this was about a 50% savings in binary size. And this app includes quite minimal server-only content: remember that as we add additional server-only components and pages, this 220 will not grow.
-
-## Overview
-
-This demo may seem pretty basic. It is. But there are a number of immediate takeaways:
-
-- **50% WASM binary size reduction**, which means measurable improvements in time to interactivity and initial load times for clients.
-- **Reduced HTML page size.** This one is less obvious, but it’s true and important: HTML generated from `#[component]`s doesn’t need all the hydration IDs and other boilerplate added.
-- **Reduced data serialization costs.** Creating a resource and reading it on the client means you need to serialize the data, so it can be used for hydration. If you’ve also read that data to create HTML in a `Suspense`, you end up with “double data,” i.e., the same exact data is both rendered to HTML and serialized as JSON, increasing the size of responses, and therefore slowing them down.
-- **Easily use server-only APIs** inside a `#[component]` as if it were a normal, native Rust function running on the server—which, in islands mode, it is!
-- **Reduced `#[server]`/`create_resource`/`Suspense` boilerplate** for loading server data.
-
-## Future Exploration
-
-The `experimental-islands` feature included in 0.5 reflects work at the cutting edge of what frontend web frameworks are exploring right now. As it stands, our islands approach is very similar to Astro (before its recent View Transitions support): it allows you to build a traditional server-rendered, multi-page app and pretty seamlessly integrate islands of interactivity.
-
-There are some small improvements that will be easy to add. For example, we can do something very much like Astro's View Transitions approach:
-
-- add client-side routing for islands apps by fetching subsequent navigations from the server and replacing the HTML document with the new one
-- add animated transitions between the old and new document using the View Transitions API
-- support explicit persistent islands, i.e., islands that you can mark with unique IDs (something like `persist:searchbar` on the component in the view), which can be copied over from the old to the new document without losing their current state
-
-There are other, larger architectural changes that I’m [not sold on yet](https://github.com/leptos-rs/leptos/issues/1830).
-
-## Additional Information
-
-Check out the [islands PR](https://github.com/leptos-rs/leptos/pull/1660), [roadmap](https://github.com/leptos-rs/leptos/issues/1830), and [Hackernews demo](https://github.com/leptos-rs/leptos/tree/main/examples/hackernews_islands_axum) for additional discussion.
-
-## Demo Code
-
-```rust
-use leptos::*;
-use leptos_router::*;
-
-#[component]
-pub fn App() -> impl IntoView {
- view! {
-
-
-
-
-
-
-
- }
-}
-
-/// Renders the home page of your application.
-#[component]
-fn HomePage() -> impl IntoView {
- let files = ["a.txt", "b.txt", "c.txt"];
- let labels = files.iter().copied().map(Into::into).collect();
- let tabs = move || {
- files
- .into_iter()
- .enumerate()
- .map(|(index, filename)| {
- let content = std::fs::read_to_string(filename).unwrap();
- view! {
-
-
-
{filename.to_string()}
-
{content}
-
- }
- })
- .collect_view()
- };
-
- view! {
-
"Welcome to Leptos!"
-
"Click any of the tabs below to read a recipe."
-
- {tabs()}
-
- }
-}
-
-#[island]
-fn Tabs(labels: Vec
, children: Children) -> impl IntoView {
- let (selected, set_selected) = create_signal(0);
- provide_context(selected);
-
- let buttons = labels
- .into_iter()
- .enumerate()
- .map(|(index, label)| {
- view! {
-
- {label}
-
- }
- })
- .collect_view();
- view! {
-
- {buttons}
-
- {children()}
- }
-}
-
-#[island]
-fn Tab(index: usize, children: Children) -> impl IntoView {
- let selected = expect_context::>();
- view! {
-
- {children()}
-
- }
-}
-```
+