Jonathan Kelley
f2b1c6d97f
overhaul dioxus fullstack using a new implementation of server_fn This PR is a complete rewrite of dioxus fullstack designed to improve compatibility with axum and to fix a number of compilation errors based on feature flag unification plumbing through macros.
66 lines
3.1 KiB
Markdown
66 lines
3.1 KiB
Markdown
# Test harnesses
|
|
|
|
This folder contains a series of CLI harnesses that represent common structures of dioxus apps.
|
|
|
|
We test these projects as a form of smoke testing to ensure our argument resolution works properly.
|
|
|
|
These projects might not be functionally useful, but they do have interesting properties that the CLI tests.
|
|
|
|
The tests for the CLI are contained within the CLI itself.
|
|
|
|
## This Folder
|
|
|
|
The items in this folder are procedurally generated by tests in the CLI crate. We will delete EVERYTHING that ends up here.
|
|
|
|
## How platform resolution works
|
|
|
|
Determine which features, triple, profile, etc to pass to the build.
|
|
|
|
Most of the time, users should use `dx serve --<platform>` where the platform name directly
|
|
corresponds to the feature in their cargo.toml. So,
|
|
- `dx serve --web` will enable the `web` feature
|
|
- `dx serve --mobile` will enable the `mobile` feature
|
|
- `dx serve --desktop` will enable the `desktop` feature
|
|
|
|
In this case, we set default-features to false and then add back the default features that
|
|
aren't renderers, and then add the feature for the given renderer (ie web/desktop/mobile).
|
|
We call this "no-default-features-stripped."
|
|
|
|
There are a few cases where the user doesn't need to pass a platform.
|
|
- they selected one via `dioxus = { features = ["web"] }`
|
|
- they have a single platform in their default features `default = ["web"]`
|
|
- there is only a single non-server renderer as a feature `web = ["dioxus/web"], server = ["dioxus/server"]`
|
|
- they compose the super triple via triple + bundleformat + features
|
|
|
|
Note that we only use the names of the features to correspond with the platform.
|
|
Platforms are "super triples", meaning they contain information about
|
|
- bundle format
|
|
- target triple
|
|
- how to serve
|
|
- enabled features
|
|
|
|
By default, the --platform presets correspond to:
|
|
- web: bundle(web), triple(wasm32), serve(http-serve), features("web")
|
|
- desktop: alias to mac/win/linux
|
|
- mac: bundle(mac), triple(host), serve(appbundle-open), features("desktop")
|
|
- windows: bundle(exefolder), triple(host), serve(run-exe), features("desktop")
|
|
- linux: bundle(appimage), triple(host), serve(run-exe), features("desktop")
|
|
- ios: bundle(ios), triple(arm64-apple-ios), serve(ios-simulator/xcrun), features("mobile")
|
|
- android: bundle(android), triple(arm64-apple-ios), serve(android-emulator/adb), features("mobile")
|
|
- server: bundle(server), triple(host), serve(run-exe), features("server")
|
|
- liveview: bundle(liveview), triple(host), serve(run-exe), features("liveview")
|
|
- unknown: <auto or default to desktop>
|
|
|
|
Fullstack usage is inferred from the presence of the fullstack feature or --fullstack.
|
|
|
|
## List of harnesses (brainstorming)
|
|
|
|
- app that doesn't use dioxus
|
|
- simple app where the renderer is used as an explicit feature
|
|
- simple app, same as above, but with fullstack enabled
|
|
- since no `server` feature is present, we don't run the server
|
|
- simple app, same as above, but with a `server` feature
|
|
- server should launch and take precedence over the client
|
|
- simple server-only app
|
|
- IE you're doing SSR with dioxus
|