Reboot DDD Dashboard - #125
Conversation
Current Aviator status
This PR is not ready to merge (currently in state pending): this PR has a review with changes requested (the review must be approved or dismissed before merging). Pending Status Checks
See the real-time status of this PR on the
Aviator webapp.
Use the Aviator Chrome Extension
to see the status of your PR within GitHub.
|
b088604 to
2d349ce
Compare
benh
left a comment
benh
left a comment
There was a problem hiding this comment.
Let me know if you'd like to find some time to discuss these!
| message APIGetRequest {} | ||
|
|
||
| message APIGetResponse { | ||
| repeated StateTypeInfo state_types = 1; |
There was a problem hiding this comment.
Bigger picture, I don't think we should put all of the state types on the main page, I think we should just have a home page that says something like "review state and data types by selecting them on the left, or review behaviors, or ..."
Or maybe the home page will be the "call graph" view.
Either way I think it's overwhelming to see all of the text that we currently have, especially as your app scales up.
That probably means that we should have finer grained readers for getting only what we need for the current page that we're on (and take advantage of the local cache). I think we'd want to do this anyway as apps grow and we add lots more information (like the call graph), so that we're transmitting less and have a faster first paint.
I also think that once we have the call graph users will likely click into other state type or state methods or data types or behaviors to learn more and they'll want to hit the back button to go to the previous state/data/method/behavior, etc, and I think it'll seem less overwhelming if each state/data type has its own page. What do you think?
There was a problem hiding this comment.
Part of the way that it works is to show, on one page, the app getting assembled as it comes into being from the robot. So I think an overview page of some kind is still useful.
Now what to do as the app grows? I'd be surprised if you thought it wasn't possible to display this much information usefully on one page. There are useful one page apps that have more information than an app is every likely to. I think we could do this and still make it useful by adding filters or search.
I guess put another way, what would be the purpose of looking at just one state type on it's own page that couldn't be gotten by clicking the navigation fragment? If there is no difference, than I think it's more powerful on one page.
I like the idea of a back button, we can use react router to achieve that with navigation fragments.
I think most people will think it's more cool than overwhelming. My preference is to leave it on one page but I'd be fine going to a higher level overview. I'd want to give some thought to the first few minutes experience so it still feels like something substantial is being built that you don't have to click around a bunch to see.
|
Some more food for thought for this as I work through method call analysis: can we just use the |
I actually did this in my follow up PR so nothing for you to do here. |
mypy 1.18 rejects `if x is Any:` as `comparison-overlap` when `x` is declared as a union of concrete types. The comparison is correct at runtime: `get_args` on an annotation such as `dict[str, Any]` hands back the `typing.Any` object itself, so the converters meet it as a value. Only the declared parameter types disagree, since they do not mention `Any`. Route the comparison through `is_annotation_any`, whose parameter is typed `object` — the honest domain of what typing introspection returns. The converters' declared unions stay as they are, and the runtime behavior is identical: the same `is` comparison, one call deeper. Until now this error failed the build of every target whose closure reaches `reboot/api.py` under a fresh mypy run, which is how it was found: Bazel's remote cache had been serving stale mypy results, so CI never re-ran mypy over these files. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
A `description=` was only set on `McpMethodOptions.description`, so a Reader, Writer, Transaction or Workflow that was not also an MCP tool didn't have it. It is now set on `MethodOptions.description` for every method, and MCP tool and resource descriptions read from there. `McpMethodOptions.description` is deprecated but still read as a fallback, so protos that already set it keep their descriptions. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The first of several changes, split so that each can be reviewed on its own and so the dashboard can be tried out while the rest is written. It is not a documented feature yet: nothing opens a page by itself, so seeing one means passing `--open-dashboard` or visiting the URL. `rbt dev run` now starts a second Reboot application alongside the developer's, with its own state store, holding what the dashboard needs. The companion watches the developer's `api/` directory and records what those files declare, so the dashboard can describe an application. It also serves the page itself. The page reads that schema reactively and renders one section per state type: its fields, and each method's kind, whether it constructs, whether it is reachable over MCP, its signature and the errors it raises. Dashboard state, such as which detail views are open and which are closed, is saved in Reboot state, so it survives a hot reload and an `rbt dev run` restart. Auto-open is complete but off. `_AUTO_OPEN_DASHBOARD` is False, so only `--open-dashboard` opens a page. We don't reopen the dashboard if the developer already has it open, and we use the `Presence` library to determine whether they do. Note that presence does not drain through a DevPod workstation's port forward, which is filed separately. This will eventually supersede the inspect dashboard at `/__/inspect`, which lists state instances and their values. It does not replace it yet and both exist meanwhile: this describes an application's API, its state types, their fields and their methods, and cannot yet show the data behind them. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
A method can say what it does, but a state type is the sum of its state and its methods, and its name alone does not say what it is for. `Type` now takes a description, which the dashboard shows beside the state type's name and file. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The manylinux images build every CPython with `--disable-shared` and delete even the static `libpython` archives. The `reboot-dev-reboot` genrule links `reboot_native.node` with `-lpython3.10`, a flag emitted by `python3.10-config --ldflags --embed`. That link has never been able to succeed inside these images. CI stayed green only while Bazel's remote cache served the genrule's outputs. The first cache miss made every platform fail deterministically. On x86_64 that miss came from a runner hardware swap: it changed the `lscpu` portion of `the_environment.txt`, and with it the whole cache scope. Point `python`/`python3` at a python-build-standalone CPython 3.10, which ships `libpython3.10.so`. It is the same build `reboot/nodejs/prepare_environment.sh` downloads. `pip`/`pip3` stay on the manylinux interpreter, whose layout `auditwheel` and the wheel builds expect. `python3` and `pip` therefore deliberately name different installations. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
f778d84 to
aa5039f
Compare
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| import { RebootClientProvider } from "@reboot-dev/reboot-react"; | ||
| import { Presence } from "@reboot-dev/reboot-std-react/presence"; | ||
| import { | ||
| FC, |
There was a problem hiding this comment.
FC is imported as a value, but the new tsconfig.json for this frontend sets "verbatimModuleSyntax": true. Since FC is a type-only export of @types/react (there is no runtime FC binding in react), tsc will report TS1484: 'FC' is a type and must be imported using a type-only import when 'verbatimModuleSyntax' is enabled, failing //reboot/dashboard/frontend:dashboard_ts and therefore dashboard_bundle.
.bazelrc sets --@aspect_rules_ts//ts:default_to_tsc_transpiler, so type-checking happens in the same action as transpilation — this isn't deferred to a separate, skippable target. Every other file in the repo that value-imports FC sits under a tsconfig without verbatimModuleSyntax; files that are under one already use the type-only form (e.g. reboot/rootpage/install_step.tsx).
| FC, | |
| type FC, |
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
5f669a8 to
0a7c6b1
Compare
Code reviewNo issues found. Checked for bugs and CLAUDE.md compliance. |
2 participants
No description provided.