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 (i.e., 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