feat: re-exported spawn_local for convenience

Author: arctic-hen7

docs/0.3.x/en-US/server-communication.md

@@ -31,7 +31,7 @@ It's fairly trivial to communicate with a server at build-time in Perseus, which
 
 ### In the Browser
 
-In some cases, it's just not possible to fetch the data you need on the server, and the client needs to fetch it themselves. This is often the case in [exported](:exporting) apps. This is typically done with the browser's inbuilt Fetch API, which is conveniently wrapped by [`reqwasm`](https://docs.rs/reqwasm).
+In some cases, it's just not possible to fetch the data you need on the server, and the client needs to fetch it themselves. This is often the case in [exported](:exporting) apps. This is typically done with the browser's inbuilt Fetch API, which is conveniently wrapped by [`reqwasm`](https://docs.rs/reqwasm). Note that you'll need to do this in a `Future`, which you can spawn using [`wasm_bindgen_futures::spawn_local`](https://docs.rs/wasm-bindgen-futures/latest/wasm_bindgen_futures/fn.spawn_local.html), conveniently re-exported from Perseus as `perseus::spawn_local`. You can then modify a `Signal` in there that holds the data you want. It's common practice in web development today to show a page skeleton (those pulsating bars instead of text) while data are still being loaded.
 
 However, if you try to request from a public API in this way, you may run into problems with [CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS), which can be very confusing, especially if you're not used to web development! The simple explanation of this is that CORS is a *thing* that browsers use to make sure your code can't send requests to servers that haven't allowed it (as in your code specifically). If you're querying your own server and getting this problem, make sure to set the `Access-Control-Allow-Origin` header to allow your site to make requests (see [here](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) for more details). However, if a public API hasn't set this, you're up the creek! In these cases, it's best to query through your own server or through one of Perseus' rendering strategies (if possible).
 

docs/next/en-US/server-communication.md

@@ -31,7 +31,7 @@ It's fairly trivial to communicate with a server at build-time in Perseus, which
 
 ### In the Browser
 
-In some cases, it's just not possible to fetch the data you need on the server, and the client needs to fetch it themselves. This is often the case in [exported](:exporting) apps. This is typically done with the browser's inbuilt Fetch API, which is conveniently wrapped by [`reqwasm`](https://docs.rs/reqwasm).
+In some cases, it's just not possible to fetch the data you need on the server, and the client needs to fetch it themselves. This is often the case in [exported](:exporting) apps. This is typically done with the browser's inbuilt Fetch API, which is conveniently wrapped by [`reqwasm`](https://docs.rs/reqwasm). Note that you'll need to do this in a `Future`, which you can spawn using [`wasm_bindgen_futures::spawn_local`](https://docs.rs/wasm-bindgen-futures/latest/wasm_bindgen_futures/fn.spawn_local.html), conveniently re-exported from Perseus as `perseus::spawn_local`. You can then modify a `Signal` in there that holds the data you want. It's common practice in web development today to show a page skeleton (those pulsating bars instead of text) while data are still being loaded.
 
 However, if you try to request from a public API in this way, you may run into problems with [CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS), which can be very confusing, especially if you're not used to web development! The simple explanation of this is that CORS is a *thing* that browsers use to make sure your code can't send requests to servers that haven't allowed it (as in your code specifically). If you're querying your own server and getting this problem, make sure to set the `Access-Control-Allow-Origin` header to allow your site to make requests (see [here](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) for more details). However, if a public API hasn't set this, you're up the creek! In these cases, it's best to query through your own server or through one of Perseus' rendering strategies (if possible).
 

examples/fetching/Cargo.toml

@@ -12,4 +12,3 @@ serde = { version = "1", features = ["derive"] }
 serde_json = "1"
 ureq = "2"
 reqwasm = "0.4"
-wasm-bindgen-futures = "0.4"

examples/fetching/src/index.rs

@@ -17,11 +17,11 @@ pub fn index_page(IndexProps { ip }: IndexProps) -> View<G> {
     // This will only run in the browser
     // `reqwasm` wraps browser-specific APIs, so we don't want it running on the server
     if G::IS_BROWSER {
-        // Spawn a `Future` on this thread to fetch the data
+        // Spawn a `Future` on this thread to fetch the data (`spawn_local` is re-exported from `wasm-bindgen-futures`)
         // Don't worry, this doesn't need to be sent to JavaScript for execution
         //
         // We want to access the `message` `Signal`, so we'll clone it in (and then we need `move` because this has to be `'static`)
-        wasm_bindgen_futures::spawn_local(cloned!(message => async move {
+        perseus::spawn_local(cloned!(message => async move {
             // This interface may seem weird, that's because it wraps the browser's Fetch API
             // We request from a local path here because of CORS restrictions (see the book)
             let body = reqwasm::http::Request::get("/message")

packages/perseus/src/lib.rs

@@ -66,6 +66,7 @@ mod translator;
 // Re-exports
 pub use http;
 pub use http::Request as HttpRequest;
+pub use wasm_bindgen_futures::spawn_local;
 /// All HTTP requests use empty bodies for simplicity of passing them around. They'll never need payloads (value in path requested).
 pub type Request = HttpRequest<()>;
 pub use perseus_macro::{autoserde, head, template, test};