You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
// This is not part of our data model, we do NOT want the frozen app synchronized as part of our page's state, it should be separate
11
+
let frozen_app = Signal::new(String::new());
12
+
let render_ctx = perseus::get_render_ctx!();
13
+
14
+
view!{
15
+
p {(test.get())}
16
+
17
+
// When the user visits this and then comes back, they'll still be able to see their username (the previous state will be retrieved from the global state automatically)
18
+
a(href = ""){"Index"}
19
+
br()
20
+
21
+
// We'll let the user freeze from here to demonstrate that the frozen state also navigates back to the last route
Copy file name to clipboardExpand all lines: examples/core/freezing_and_thawing/src/templates/index.rs
+11-9
Original file line number
Diff line number
Diff line change
@@ -4,28 +4,30 @@ use sycamore::prelude::*;
4
4
5
5
usecrate::global_state::AppStateRx;
6
6
7
-
// We define a normal `struct` and then use `make_rx` (which derives `Serialize`, `Deserialize`, and `Clone` automatically)
8
-
// This will generate a new `struct` called `IndexPropsRx` (as we asked it to), in which every field is made reactive with a `Signal`
9
7
#[perseus::make_rx(IndexPropsRx)]
10
8
pubstructIndexProps{
11
-
pubusername:String,
9
+
username:String,
12
10
}
13
11
14
-
// This special macro (normally we'd use `template(IndexProps)`) converts the state we generate elsewhere to a reactive version
15
-
// We need to tell it the name of the unreactive properties we created to start with (unfortunately the compiler isn't smart enough to figure that out yet)
16
-
// This will also add our reactive properties to the global state store, and, if they're already there, it'll use the existing one
let username_2 = username.clone();// This is necessary until Sycamore's new reactive primitives are released
20
-
let frozen_app = Signal::new(String::new());// This is not part of our data model, so it's not part of the state properties (everything else should be though)
16
+
let test = global_state.test;
17
+
let test_2 = test.clone();
18
+
19
+
// This is not part of our data model, we do NOT want the frozen app synchronized as part of our page's state, it should be separate
20
+
let frozen_app = Signal::new(String::new());
21
21
let frozen_app_2 = frozen_app.clone();
22
22
let frozen_app_3 = frozen_app.clone();
23
23
let render_ctx = perseus::get_render_ctx!();
24
24
25
25
view!{
26
+
// For demonstration, we'll let the user modify the page's state and the global state arbitrarily
// When the user visits this and then comes back, they'll still be able to see their username (the previous state will be retrieved from the global state automatically)
This example shows how Perseus can supprot freezing state to IndexedDB and retrieving it from there later, which is the mechanism of state freezing that many apps will use. This is also the basis of Perseus' HSR system.
4
+
5
+
Notably, this requires the `wasm-bindgen-futures` package and the `idb-freezing` feature enabled on the `perseus` package.
// When the user visits this and then comes back, they'll still be able to see their username (the previous state will be retrieved from the global state automatically)
18
+
a(href = ""){"Index"}
19
+
br()
20
+
21
+
// We'll let the user freeze from here to demonstrate that the frozen state also navigates back to the last route
// When the user visits this and then comes back, they'll still be able to see their username (the previous state will be retrieved from the global state automatically)
This example shows some of the power of Perseus' reactive state platform by extending the usual basic Perseus app to show how reactive state can persist between pages through the page state store.
0 commit comments