Convention question: parallel _app Dioxus crates and island-*-native features — finish, repurpose, or deprecate? #190
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What's the question
Across the hero_* services, there's an inconsistent pattern for how a service's UI integrates with
hero_os: some have a_server+_ui(JS) +_app(Dioxus WASM) split with anisland-*-nativeCargo feature inhero_os_app; some have only one or the other; some have neither. What's the convention going forward, and what's the right fate of the in-flight parallel mirrors that nobody is finishing?How we got here
mik-tfrolled out a "100% SPA migration" in hero_collab8579db4(sessions 17-18 — native dioxus islands, new URL routing) and equivalent commits across ~18 services in early April 2026. Goal stated in the commit: replace every JS UI with a native Dioxus island. The migration created_appcrates in many services andisland-*-nativefeatures inhero_os_app/Cargo.toml(lines 79-95). It hasn't been completed.State today (verified across 9 services)
_appcrate_appcommitchat_view.rsis 403 lines that re-declare the chat HTML scaffold inrsx!{}and dynamically load the samechat-app.js(4,597 LOC). Plus 3,383 LOC of Dioxus admin tabs duplicatingdashboard.js(1,905 LOC).dashboard.jsadmin tabsembed/iframe wrappersIn
hero_os_app/Cargo.toml: 16island-*-nativefeatures, all OFF in the defaultwebfeature (line 11), only enabled underweb-native(lines 142-154). Whetherweb-nativeis built/deployed anywhere is unclear — the audit didn't surface a release flow that uses it.What works (concrete references)
01fa4b6feat(office): native Dioxus file browser + iframe-only OnlyOffice editor— native Dioxus chrome + iframe for the heavy embed. Wired into hero_os via PR #88, replacing the prior inline iframe.hero_voice_app(linked above) —_appand_uiat different scopes (one is the focused embedded surface, one is the full standalone management UI). Not mirrors.The cost of the status quo
For services with parallel mirrors that nobody is finishing, every JS feature added is invisible to the Dioxus snapshot. In hero_collab specifically: ~5,700 LOC of parallel surface area, last Dioxus-side commit on 2026-04-12, every chat/admin feature shipped since lives in JS only. Whoever's currently on an
_appcrate's iframe path is paying for the duplicate that they didn't sign up for.Questions
Is
web-nativeused in any deployed build? If yes, the stale_appcrates are load-bearing and need active owners. If no, they're carrying cost for nothing.For the three services with stale parallel mirrors (hero_collab, hero_whiteboard, hero_agent), what's the right fate per service? Three options:
_appa different scope from the JS (focused widget, embedded compose, activity feed). hero_voice's pattern._appcrate, remove theisland-*-nativefeature, keep iframe as the sole integration path. (hero_slides already operates this way.)For new services: convention should be
_server+ (_uiJS / Askama / Dioxus — pick ONE), or always-three? If the answer depends on the service shape, what's the rubric?No emergency, but every service that ships locks in another answer.
Good points.
So Kristof is aware of the web-native/100% SPA version. And in the end we want to have 100% SPA, but he said many times that it is not the time now to do it. I did the web-native in a way that does not stop the development of the non web-native versions (called just web). So it should not interfere. In the best scenario we can have 100% SPA quickly so we can have a stronger Hero OS for all platforms.
@despiegk If you change your mind and think we should do 100% let us know. Otherwise as I see it the latest direction was to not focus on this (yet).
I hope it helps @sameh-farouk . Curious to hear the feedback on this.
Note: Any time we want to go web-native, it does not take me too long to update it so it is in line with latest features from web version, but with 100% SPA. (I tested the whole thing in Hero OS live).