Skip to content

Commit

Permalink
docs: added all missing links to the docs
Browse files Browse the repository at this point in the history
They should be pretty much ready now!
  • Loading branch information
arctic-hen7 committed Feb 4, 2023
1 parent 07ab6c6 commit c3c575b
Show file tree
Hide file tree
Showing 30 changed files with 78 additions and 78 deletions.
2 changes: 1 addition & 1 deletion docs/next/en-US/capsules/capsules-vs-components.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# Capsules vs. components

With all this capsules stuff, you might be wondering whether you should be using capsules for everything: here's the short answer, **don't**. This page will go through the differences between normal [Sycamore components], which don't integrate with the Perseus state platform, and full-blown capsules.
With all this capsules stuff, you might be wondering whether you should be using capsules for everything: here's the short answer, **don't**. This page will go through the differences between normal [Sycamore components](https://sycamore-rs.netlify.app/docs/basics/components), which don't integrate with the Perseus state platform, and full-blown capsules.

## View generation

Expand Down
6 changes: 3 additions & 3 deletions docs/next/en-US/capsules/using.md
Original file line number Diff line number Diff line change
Expand Up @@ -44,9 +44,9 @@ That second argument to the capsule's `.widget()` function is by far the most im

In the above example, we used the empty string to denote the index page, because the capsules we're using only render one widget each.

if you want to see a more advanced example of a capsule that uses incremental generation to build widgets, check out [this code].
if you want to see a more advanced example of a capsule that uses incremental generation to build widgets, check out [this code](https://github.com/framesurge/perseus/blob/main/examples/core/capsules/src/capsules/number.rs).

*Note: while it might seem extremely weird, there is nothing to stop you from reactively changing the widgets you render on the client-side, as in [this example].*
*Note: while it might seem extremely weird, there is nothing to stop you from reactively changing the widgets you render on the client-side, as in [this example](https://github.com/framesurge/perseus/blob/main/examples/core/capsules/src/templates/calc.rs).*

## Delayed widgets

Expand All @@ -62,4 +62,4 @@ One notable instance where this isn't necessary is in incremental generation. Fo

## Support

The Perseus capsules system is not only very new, it is a completely novel architecture, so there are bound to be bugs and idiosyncracies that can be improved. If you're having problems, even if you don't think they're a bug, please let us know through [a GitHub discussion], or [on Discord] --- every little bit of feedback helps us improve Perseus and make it easier for you to develop lightning-fast apps! If you do reckon you've found a bug, or if you'd like to request a new feature, please open an issue [on GitHub] and let us know!
The Perseus capsules system is not only very new, it is a completely novel architecture, so there are bound to be bugs and idiosyncracies that can be improved. If you're having problems, even if you don't think they're a bug, please let us know through [a GitHub discussion](https://github.com/framesurge/perseus/discussions/new/choose), or [on Discord](https://discord.com/invite/GNqWYWNTdp) --- every little bit of feedback helps us improve Perseus and make it easier for you to develop lightning-fast apps! If you do reckon you've found a bug, or if you'd like to request a new feature, please open an issue [on GitHub](https://github.com/framesurge/perseus/issues/new/choose) and let us know!
2 changes: 1 addition & 1 deletion docs/next/en-US/core-principles.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# Core Principles

Before you dive into Perseus, you might want to get a better idea of the fundamentals on which the framework is built. If you'd prefer to dive straight in though, check out [the tutorial], and then maybe come back here later.
Before you dive into Perseus, you might want to get a better idea of the fundamentals on which the framework is built. If you'd prefer to dive straight in though, check out [the tutorial](:first-app/intro), and then maybe come back here later.

The main key idea that underpins Perseus is about *templates*, and the primary architectural matter to understand is how Perseus apps actually work in terms of their components.

Expand Down
2 changes: 1 addition & 1 deletion docs/next/en-US/faq.md
Original file line number Diff line number Diff line change
Expand Up @@ -31,7 +31,7 @@ That will archive the `git/` and `registry/` folders in `~/.cargo/`, which shoul

## Hydration doesn't work with X

Perseus v0.4.x uses Sycamore v0.8.x, which may still have a few very minor hydration bugs (though literally dozens have been fixed since v0.7.x), so there are a few things that won't work with it yet. In fact, as a general rule, if you're getting weird layout bugs that make absolutely no logical sense, try disabling hydration, it will often fix things at the moment. This shouldn't have any major impact on user experience or performance that's appreciable, though it *may* lower your app's Lighthouse scores. Please be sure to report your problem to [Sycamore] (or Perseus if you're not usre whose fault it is, and we'll probably figure it out eventually!).
Perseus v0.4.x uses Sycamore v0.8.x, which may still have a few very minor hydration bugs (though literally dozens have been fixed since v0.7.x), so there are a few things that won't work with it yet. In fact, as a general rule, if you're getting weird layout bugs that make absolutely no logical sense, try disabling hydration, it will often fix things at the moment. This shouldn't have any major impact on user experience or performance that's appreciable, though it *may* lower your app's Lighthouse scores. Please be sure to report your problem to [Sycamore](https://github.com/sycamore-rs/sycamore) (or Perseus if you're not sure whose fault it is, and we'll probably figure it out eventually!).

## I'm getting really weird errors with a page's `<head>`...

Expand Down
4 changes: 2 additions & 2 deletions docs/next/en-US/first-app/defining.md
Original file line number Diff line number Diff line change
Expand Up @@ -32,9 +32,9 @@ So, our actual `src/main.rs` file would look something like this (theory over, *

First off, we declare a module called `templates`, which will correspond to the `src/templates/` folder, which we'll use to store the code for all our templates. Go ahead and create that folder now, with an empty `mod.rs` file inside. The next thing is to import the Perseus `prelude` module, which just collates everything you'll need to run a Perseus app, which helps to avoid having to manually import a million different things. Most of your Perseus files will begin with `use perseus::prelude::*;`, and then `use sycamore::prelude::*;`

Then we get to that special `main()` function. As you can see, it returns a `PerseusApp`, which takes a generic `G`: this is a special part of Sycamore that lets is say "let this function work with any rendering backend that implements `Html`", because Sycamore can actually go way beyond the web! This generic restricts us to using `SsrNode` (for prerendering), `DomNode` (for rendering to the Document Object Model in the browser), or `HydrateNode` (the same as `DomNode`, but for when we're [hydrating]).
Then we get to that special `main()` function. As you can see, it returns a `PerseusApp`, which takes a generic `G`: this is a special part of Sycamore that lets is say "let this function work with any rendering backend that implements `Html`", because Sycamore can actually go way beyond the web! This generic restricts us to using `SsrNode` (for prerendering), `DomNode` (for rendering to the Document Object Model in the browser), or `HydrateNode` (the same as `DomNode`, but for when we're [hydrating](:fundamentals/hydration)).

You'll also notice that we've provided an argument to the `#[perseus::main(..)]` attribute macro: that's the function that will start up our server! If you want to add things like custom API routes, etc., then you can set this function manually, and then use one of the Perseus server integrations to work with the code you've written (see [this example] for more), but here we're just using the default server from the `perseus-warp` package. If you fancy [Axum], you can use `perseus-axum`, and [Actix Web] fans can use the `perseus-actix-web` package!
You'll also notice that we've provided an argument to the `#[perseus::main(..)]` attribute macro: that's the function that will start up our server! If you want to add things like custom API routes, etc., then you can set this function manually, and then use one of the Perseus server integrations to work with the code you've written (see [this example](https://github.com/framesurge/perseus/tree/main/examples/core/custom_server) for more), but here we're just using the default server from the `perseus-axum` package. If you fancy [Warp](https://github.com/seanmonstar/warp), you can use `perseus-axum`, and [Actix Web](https://github.com/actix/actix-web) fans can use the `perseus-actix-web` package!

## Your `PerseusApp`

Expand Down
8 changes: 4 additions & 4 deletions docs/next/en-US/first-app/deploying.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# Deploying!

Congratulations on making it through the tutorial, it's time to deploy your app! First, though, we haven't actually run it yet, so we may as well make sure it all compiles. Remember, you an always do this quickly with `perseus check`, which should give all ticks if everything's working. If not, you've probably just mistyped a variable name or something, which happens to us all. If you're having trouble, let us know [in a GitHub discussion], or [on Discord], and we'll be happy to help! (And remember, there are no stupid questions or dumb bugs.)
Congratulations on making it through the tutorial, it's time to deploy your app! First, though, we haven't actually run it yet, so we may as well make sure it all compiles. Remember, you an always do this quickly with `perseus check`, which should give all ticks if everything's working. If not, you've probably just mistyped a variable name or something, which happens to us all. If you're having trouble, let us know [in a GitHub discussion](https://github.com/framesurge/perseus/discussions/new/choose), or [on Discord](https://discord.com/invite/GNqWYWNTdp), and we'll be happy to help! (And remember, there are no stupid questions or dumb bugs.)

When you're ready to actually run your app, you can run `perseus serve`, which will prepare everything to be run for development. When it's ready, you'll be able to see your brand-new app at <http://localhost:8080>, in all its *Hello World!* glory! If you try clicking on the link to the *About* page, you should find that the page doesn't seem to change from the browser's perspective, it just instantly updates: this is Perseus' router in action. Press the back button in your browser to pop back to the landing page, and, again, it should be near-instant (Perseus has *cached* the index page, and can return to it with no network requests needed).

Expand Down Expand Up @@ -38,16 +38,16 @@ When you deploy your Perseus app, there are two separate main binaries that are

Most of these optimizations are all applied automatically in `perseus deploy`, but they can be tweaked if you like by setting some of the flags on the CLI (which you can see with `perseus deploy --help`). These will allow you to apply different optimization settings to suit your needs.

One thing you may want to do is replace Rust's default allocator (thing in charge of your app's memory) with something slower but smaller. There are two options here: [`wee_alloc`] (which has memory leaks, and is now unmaintained), and the newer (but largely untested) [`lol_alloc`]. Whatever you do, make sure you only use these with `#[cfg(client)]` to make sure they don't get used for your server as well! (Since that would *massively* slow down your site.)
One thing you may want to do is replace Rust's default allocator (thing in charge of your app's memory) with something slower but smaller. There are two options here: [`wee_alloc`](https://github.com/rustwasm/wee_alloc) (which has memory leaks, and is now unmaintained), and the newer (but largely untested) [`lol_alloc`](https://github.com/Craig-Macomber/lol_alloc). Whatever you do, make sure you only use these with `#[cfg(client)]` to make sure they don't get used for your server as well! (Since that would *massively* slow down your site.)

For more information on optimizing Wasm bundle sizes, see [here](https://rustwasm.github.io/book/reference/code-size.html#optimizing-builds-for-code-size).

## Export deployment

However, there's actually a simpler way of deploying this app in particular. Because we aren't using any features that need a server (e.g. we're generating state at build-time, not request-time, so all the server is doing is just passing over files that it generated when we built the app), we can *export* our app. You can try this for development with `perseus export -s` (the `-s` tells Perseus to spin up a file server automatically to serve your app for you). In production, use `perseus deploy -e` to make `pkg/` contain a series of static files. If you have `python` installed on your computer, you can serve this with `python -m http.server -d pkg/`. The nice thing about exported apps is that they can be sent to places like [GitHub Pages], which will host your app for free. In fact, this whole website is exported (because it's all static documentation), and hosted on exactly that service!
However, there's actually a simpler way of deploying this app in particular. Because we aren't using any features that need a server (e.g. we're generating state at build-time, not request-time, so all the server is doing is just passing over files that it generated when we built the app), we can *export* our app. You can try this for development with `perseus export -s` (the `-s` tells Perseus to spin up a file server automatically to serve your app for you). In production, use `perseus deploy -e` to make `pkg/` contain a series of static files. If you have `python` installed on your computer, you can serve this with `python -m http.server -d pkg/`. The nice thing about exported apps is that they can be sent to places like [GitHub Pages](https://pages.github.com), which will host your app for free. In fact, this whole website is exported (because it's all static documentation), and hosted on exactly that service!

## Closing words

With all that, you've successfully built and deployed your first ever Perseus app: well done! If you're liking Perseus so far, you can check out the rest of the documentation to learn about its features in greater detail, and [the examples] will be your friends in writing real-world Perseus code: they have examples of every single Perseus feature. If you think you've found a bug, please let us know by [opening an issue], or, if you'd like to contribute a feature, you can [open a pull request]. If you're having trouble, you can [open a GitHub discussion] or [as on our Discord], and our friendly community will be happy to help yout out! Also, make sure to take a look at [the Sycamore docs] to learn more about the library that underlies all of Perseus.
With all that, you've successfully built and deployed your first ever Perseus app: well done! If you're liking Perseus so far, you can check out the rest of the documentation to learn about its features in greater detail, and [the examples](https://github.com/framesurge/perseus/tree/main/examples) will be your friends in writing real-world Perseus code: they have examples of every single Perseus feature. If you think you've found a bug, please let us know by [opening an issue](https://github.com/framesurge/perseus/issues/new/choose), or, if you'd like to contribute a feature, you can [open a pull request](https://github.com/framesurge/perseus/compare). If you're having trouble, you can [open a GitHub discussion](https://github.com/framesurge/perseus/discussions/new/choose) or [as on our Discord](https://discord.com/invite/GNqWYWNTdp), and our friendly community will be happy to help yout out! Also, make sure to take a look at [the Sycamore docs](https://https://sycamore-rs.netlify.app/) to learn more about the library that underlies all of Perseus.

Best of luck in your journey, and, if you [defeat Medusa](https://en.wikipedia.org/wiki/Perseus), let us know!
4 changes: 2 additions & 2 deletions docs/next/en-US/first-app/error-handling.md
Original file line number Diff line number Diff line change
Expand Up @@ -20,10 +20,10 @@ The other thing to keep in mind with error views in Perseus is that they won't a

<summary>What does uninteractive actually mean?</summary>

Great question! You can learn more about this in [the section on hydration], but it basically means that the user can see the content, because it was *prerendered* on the server-side, but they can't interact with it: e.g. if they press a button, it won't do anything. Clicking links will still work, but they'll be handled by the browser, not by Perseus.
Great question! You can learn more about this in [the section on hydration](:fundamentals/hydration), but it basically means that the user can see the content, because it was *prerendered* on the server-side, but they can't interact with it: e.g. if they press a button, it won't do anything. Clicking links will still work, but they'll be handled by the browser, not by Perseus.

</details>

Finally, we handle different types of `ClientError::ServerError`s differently by their [HTTP status code], which is the language HTTP (the protocol used for communicating between clients and servers) uses to describe errors. Anything starting with a 4 is a client error, and anything starting with a 5 is a server error (1 is informational, 2 is ok, and 3 indicates a redirect; you won't need to handle those). We also separately handle 404, just because it's so common.
Finally, we handle different types of `ClientError::ServerError`s differently by their [HTTP status code](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status), which is the language HTTP (the protocol used for communicating between clients and servers) uses to describe errors. Anything starting with a 4 is a client error, and anything starting with a 5 is a server error (1 is informational, 2 is ok, and 3 indicates a redirect; you won't need to handle those). We also separately handle 404, just because it's so common.

With error handling done, it's about time to run this app!
Loading

0 comments on commit c3c575b

Please sign in to comment.