The type of an asset fetched from the server. This allows distinguishing
between errors in fetching, say, pages, vs. translations, which you may wish
to handle differently.
Errors that can occur while building an app.
Errors that can occur in the browser.
Errors that can occur in the browser from certain invariants not being
upheld. These should be extremely rare, but, since we don’t control what
HTML the browser gets, we avoid panicking in these cases.
Errors that can occur in the browser while interfacing with browser
functionality. These should never really occur unless you’re operating in an
extremely alien environment (which probably wouldn’t support Wasm, but
we try to allow maximal error page control).
Errors that can occur as a result of user-instructed preloads. Note that
this will not cover network-related errors, which are considered fetch
errors (since they are likely not the fault of your code, whereas a
ClientPreloadError
probably is).
Errors that can occur in the browser as a result of attempting to thaw
provided state.
Errors that can occur in the server-side engine system (responsible for
building the app).
All errors that can be returned from this crate.
Defines who caused an ambiguous error message so we can reliably create an
HTTP status code. Specific status codes may be provided in either case, or
the defaults (400 for client, 500 for server) will be used.
Errors that can occur while exporting an app to static files.
Errors that can occur while fetching a resource from the server.
Errors that can occur while serving an app. These are integration-agnostic.
Errors that can occur in the build process or while the server is running.
Errors that can occur while reading from or writing to a mutable or
immutable store.