feat(tui): Broadcast actions to all components - #1922
Merged
Conversation
Broadcast dispatch sends every action to all ~26 resource components, not just the active one. Refresh and DescribeApiResponse were never mode-gated because single-target dispatch used to make that implicit -- now they fan out, firing simultaneous API calls / racing the describe pane on every navigation and login. Add explicit current_mode == B::mode() gates; add one for the selection-derived hooks block too since it reads get_selected() and has the same shape of bug. Investigated ConnectedToCloud reaching project/region-select popups unconditionally: confirmed harmless, each fires exactly one fetch per login event either way -- left as-is (pre-warm). Add an end-to-end regression test through the real App::handle_actions path for the actual reported bug (application-credentials filter seeding on an inactive view), plus a #[cfg(test)] accessor to read a GenericResourceView's filter back out for assertions. seed_filter_from_current_user's "don't clobber an existing value" guard protects a drilled-down user selection across CloudChangeScope/SwitchToRegion reconnects (same authenticated user) -- but ConnectToCloud (a genuine cloud switch, different user) hits the same guard and gets skipped too, since user_id is never empty again after the first login. Filter stays stuck on the previous cloud's user forever. Add reset_filter_on_cloud_switch, run only for ConnectToCloud (split out from the CloudChangeScope/SwitchToRegion branch, which must keep the old behavior), overridden to clear user_id so the following ConnectedToCloud's seed sees an empty filter and re-scopes to the new cloud's user. Signed-off-by: Artem Goncharov <artem.goncharov@gmail.com>
CI failed: Tui::new() -> Terminal::new() always builds Viewport::Fullscreen, which queries the real terminal size (backend.size(), an ioctl on stdout / fallback open of /dev/tty) -- absent in a headless CI container, unlike this sandbox's shell where a real /dev/tty is still reachable through the redirected fd, which is why it passed locally. Add Tui::new_for_test(), building Viewport::Fixed instead -- confirmed via ratatui-core's Terminal::with_options source that the Fixed branch never calls backend.size(), so construction needs no terminal I/O at all. Switch all 5 app.rs tests that construct a Tui to use it. Signed-off-by: Artem Goncharov <artem.goncharov@gmail.com>
Open
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Broadcast dispatch sends every action to all ~26 resource components,
not just the active one. Refresh and DescribeApiResponse were never
mode-gated because single-target dispatch used to make that implicit --
now they fan out, firing simultaneous API calls / racing the describe
pane on every navigation and login. Add explicit current_mode ==
B::mode() gates; add one for the selection-derived hooks block too since
it reads get_selected() and has the same shape of bug.
Investigated ConnectedToCloud reaching project/region-select popups
unconditionally: confirmed harmless, each fires exactly one fetch per
login event either way -- left as-is (pre-warm).
Add an end-to-end regression test through the real App::handle_actions
path for the actual reported bug (application-credentials filter seeding
on an inactive view), plus a #[cfg(test)] accessor to read a
GenericResourceView's filter back out for assertions.
seed_filter_from_current_user's "don't clobber an existing value" guard
protects a drilled-down user selection across
CloudChangeScope/SwitchToRegion reconnects (same authenticated user) --
but ConnectToCloud (a genuine cloud switch, different user) hits the
same guard and gets skipped too, since user_id is never empty again
after the first login. Filter stays stuck on the previous cloud's user
forever.
Add reset_filter_on_cloud_switch, run only for ConnectToCloud (split out
from the CloudChangeScope/SwitchToRegion branch, which must keep the old
behavior), overridden to clear user_id so the following
ConnectedToCloud's seed sees an empty filter and re-scopes to the new
cloud's user.
Signed-off-by: Artem Goncharov artem.goncharov@gmail.com