Skip to content

fix(teams): start the members load quietly when settings mounts - #165

Merged
anilcancakir merged 1 commit into
mainfrom
fix/team-settings-quiet-load
Sep 24, 2026
Merged

anilcancakir merged 1 commit into
mainfrom
fix/team-settings-quiet-load

Conversation

@anilcancakir

Copy link
Copy Markdown
Member

What

loadMembersAndInvitations({bool quietStart = false}): with quietStart the loading state is set without notifying. Team settings' onInit uses it, and every other caller keeps the notifying start.

Why

After a successful create, team create navigates to team settings, which is .stacked(), so create stays mounted underneath. Settings' onInit started the load with a synchronous setLoading() that notified create while the settings route was being built: "setState() or markNeedsBuild() called during build". The settings view reads loading in its own first build, and the result still notifies after the await, outside any build. Closes #163.

The framework-level alternative (magic's refreshUI deferring during the build phase) would change notification timing for every magic app, so it is left out here.

Testing

  • New widget test: create mounted with an active team id, settings pushed over it. Red before (MagicStarterTeamCreateView marked mid-build), green after; putting the notifying start back turns it red again.
  • flutter analyze clean, 1552 tests green, dart format --set-exit-if-changed . clean.

After a successful create the view navigates to team settings, which is
stacked over it, and settings loads members on mount. The load set
loading before its first await, which notified the create view while
the settings route was being built: "setState() or markNeedsBuild()
called during build".

loadMembersAndInvitations(quietStart: true) sets the loading state
without notifying, and settings' onInit uses it. The view reads loading
in its own first build, and the result still notifies after the await,
outside any build. Other callers keep the notifying start.

Closes #163
@codecov

codecov Bot commented Sep 24, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

@kodizm

kodizm Bot commented Sep 24, 2026

Copy link
Copy Markdown

Note

Kodizm (AI-generated). May contain mistakes; verify before acting.

The change looks correct and narrowly scoped: only team settings' onInit uses the quiet start, and every other caller keeps the notifying one.

Minor

lib/src/http/controllers/magic_starter_team_controller.dart:87: maintainability. The quiet branch calls setState(null, status: const RxStatus.loading(), notify: false). I couldn't find the Magic framework source in this environment, so I couldn't confirm that this matches what setLoading() does apart from notifying. If setLoading() keeps the existing value rather than passing null, the quiet start would clear it. The 1552 green tests suggest it doesn't, but it's worth a glance.

Tests

A new widget test mounts team create, pushes settings over it, and asserts no mid-build mark. The author reports it red before the fix and red again with the notifying start restored. I read only the diffs of the controller and settings view, not the test file.

CI

  • Lint & Test: success
  • codecov/patch: success
  • Published graph: success
  • Auto-merge low-risk Dependabot PRs: skipped

@anilcancakir

Copy link
Copy Markdown
Member Author

On the minor at magic_starter_team_controller.dart:87: it matches. magic's setLoading() is setState(null, status: const RxStatus.loading()) (magic/lib/src/http/magic_controller.dart, the state helpers below setState), so the quiet branch differs only in notify: false. Both clear the value the same way.

@anilcancakir
anilcancakir merged commit 7b59770 into main Sep 24, 2026
5 checks passed
@anilcancakir
anilcancakir deleted the fix/team-settings-quiet-load branch September 24, 2026 10:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Team settings opened over team create notifies the create view during build

1 participant