[kkafar]

Requested by Kacper

Description

Follow-up to #4920, raised in its review. The tab item invalidation flags TITLE, BADGE and ACCESSIBILITY only routed a change to the per-item menu update, which then re-applied title (diffed), badge and accessibility every time. They now gate what is applied, mirroring the Stack header's needsRebuild || flags.containsAny(X) in StackHeaderCoordinatorLayout.processUpdate. Nothing visible changes; unchanged parts of a menu item are no longer re-applied.

Closes https://github.com/software-mansion/react-native-screens-labs/issues/1956.

Targets main: #4946, which it was stacked on, merged on 2026-10-21.

Changes

• One consumer of a menu item's flags (review, e3c6bde): TabsContainer.applyPendingMenuItemChanges is the only caller of TabsMenuItemState.consumePendingFlags(). It hands the flags to TabsAppearanceCoordinator.updateMenuItemAppearance, which applies title (TITLE), icon (ICON / ICON_SIZE), active indicator (ICON_SIZE / ACTIVE_INDICATOR_SIZE) and badge (BADGE), and applies accessibility (ACCESSIBILITY) through TabsHostA11yCoordinator. The title is no longer diffed manually.
• Apply-only primitives: TabsAppearanceApplicator exposes applyTitle, applyIcon, applyActiveIndicatorSize and updateBadgeAppearance and knows nothing about flags. A part whose menu item view doesn't exist yet is re-invalidated through TabsBottomNavigationView.invalidateMenuItem: the active indicator as before, and accessibility too (ce494b0; setA11yPropertiesToTabItem now reports whether it found the view).
• Whole-bar update without a special mode: TabsContainer.updateTabBarAppearance applies the bar-wide appearance, then every menu item through the same per-item path, then fonts. It invalidates BADGE on every item first (badge colours come from the selected tab's appearance); appearance updates also invalidate ACCESSIBILITY, replacing setA11yPropertiesToAllTabItems (removed, with TabsHostA11yCoordinator's unused tabsScreenFragments parameter).
• A fresh menu item state is fully dirty, so new and rebuilt menu items still get everything applied.
• Menu item lookups go through TabsBottomNavigationView.findMenuItem(menuItemId) / requireMenuItem(menuItemId), and the appearance applicator / coordinator methods are explicitly internal (review, fb1e94a and 1f0d8bd; comment fixes in c339610). No behavioural change, so the device runs below on ce494b0 still apply.

Test plan

Run locally:

• yarn lint-android (layer check + spotlessCheck) passes.
• :react-native-screens:compileDebugKotlin succeeds.

On device, after the review changes, this PR alone (ce494b0, without #4976; Android, FabricExample, release build, Pixel 3a API 34 emulator):

• Detox: every Android-applicable file in FabricExample/e2e/single-feature-tests/tabs/ plus example-tests/bottomTabs: 11 suites, 66 tests pass. Crash buffer empty.
• Manual runtime change of one tab's title, badgeValue, tabBarItemTestID and tabBarItemAccessibilityLabel (temporary buttons on test-tabs-general-appearance-android, not committed), read with uiautomator dump: the item's title, badge, resource-id and content description update immediately; the other tabs stay unchanged; the values survive switching tabs and whole-bar updates (label visibility labeled / unlabeled); a reset restores the original values. Crash buffer empty.

On device, before the review restructuring (Android, FabricExample, release build with this PR and #4976 on top, Pixel 3a API 34 emulator):

• Detox: every Android-applicable file in FabricExample/e2e/single-feature-tests/tabs/ plus example-tests/bottomTabs: 11 suites, 66 tests pass (test-tabs-item-badge and test-tabs-navigation-state-search-tab are iOS-gated). Crash buffer empty.
• Manual single-feature-tests/tabs/test-tabs-item-icon-tint-and-size: runtime icon size (32 / 56 / default), active indicator (96x64 / auto), tinting modes and the badge toggle apply immediately and revert; other tabs stay unchanged.
• Manual test-tabs-item-icon: asynchronously loaded image icons appear (they arrive outside a React transaction); the selected icon swaps.
• Manual test-tabs-item-badge: badge colours follow the selected tab on every switch (whole-bar update re-applies all badges).
• Manual test-tabs-general-appearance-android and issue-tests/TestBottomTabs: tab items expose their testIDs (viewIdResourceName) and content descriptions, unchanged across tab switches and label modes.
• Manual test-tabs-item-title: titles, colours and per-tab fonts follow selection.

Checklist

• Included code example that can be used to test this change.
• For visual changes, included screenshots / GIFs / recordings documenting the change.
• For API changes, updated relevant public types.
• Ensured that CI passes

---

Generated by Claude Code

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Source mode: Auto
• Repository: Unavailable
• Branch: Unavailable
• File: No configuration file from this repository applied
• Commit: Unavailable
• Layers: Repository UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: 0df3e0a0-126d-4fc3-b920-f21d13a86fe9

📥 Commits

Reviewing files that changed from the base of the PR and between dde9759 and a5d4810.

📒 Files selected for processing: 6

• android/src/main/java/com/swmansion/rnscreens/core/containers/tabs/appearance/TabsAppearanceApplicator.kt
• android/src/main/java/com/swmansion/rnscreens/core/containers/tabs/appearance/TabsAppearanceCoordinator.kt
• android/src/main/java/com/swmansion/rnscreens/core/containers/tabs/container/TabsBottomNavigationView.kt
• android/src/main/java/com/swmansion/rnscreens/core/containers/tabs/container/TabsContainer.kt
• android/src/main/java/com/swmansion/rnscreens/core/containers/tabs/container/TabsHostA11yCoordinator.kt
• android/src/main/java/com/swmansion/rnscreens/core/containers/tabs/container/TabsMenuItemState.kt

Included review availability: This review used your included allowance. Your plan provides up to 8 included reviews per hour; 7 remain after this review.

📝 Walkthrough

The Android tab container now coordinates bar-wide and per-item appearance updates through pending invalidation flags. Accessibility updates follow the same per-item flow and remain pending when the item view is unavailable.

Changes: Tab appearance updates

Layer / File(s)	Summary
Pending menu-item invalidation android/src/main/java/com/swmansion/rnscreens/core/containers/tabs/container/TabsMenuItemState.kt, android/src/main/java/com/swmansion/rnscreens/core/containers/tabs/container/TabsBottomNavigationView.kt	Menu-item state can return and clear pending flags. The bottom navigation view can find menu items and apply supplied invalidation flags to all stored items.
Selective appearance application android/src/main/java/com/swmansion/rnscreens/core/containers/tabs/appearance/TabsAppearanceApplicator.kt, android/src/main/java/com/swmansion/rnscreens/core/containers/tabs/appearance/TabsAppearanceCoordinator.kt	The coordinator separates bar, font, and menu-item updates. The applicator provides separate title and icon operations. Active-indicator updates are re-invalidated when the menu item view is unavailable.
Container and accessibility updates android/src/main/java/com/swmansion/rnscreens/core/containers/tabs/container/TabsContainer.kt, android/src/main/java/com/swmansion/rnscreens/core/containers/tabs/container/TabsHostA11yCoordinator.kt	The container consumes pending flags for item and bar updates. Accessibility properties are applied per item, and the container re-invalidates accessibility when the item view is unavailable.

Priority: ⬇️ Low

Estimated code review effort: 3 (Moderate) | ~20 minutes

Change: Refactor

Sequence Diagram(s)

sequenceDiagram
  participant TabsContainer
  participant TabsMenuItemState
  participant TabsAppearanceCoordinator
  participant TabsAppearanceApplicator
  participant TabsHostA11yCoordinator
  TabsContainer->>TabsMenuItemState: consume pending flags
  TabsContainer->>TabsAppearanceCoordinator: apply flagged menu-item updates
  TabsAppearanceCoordinator->>TabsAppearanceApplicator: apply title, icon, or active-indicator size
  TabsContainer->>TabsHostA11yCoordinator: apply accessibility properties
  TabsHostA11yCoordinator-->>TabsContainer: report whether the item view was found
  TabsContainer->>TabsMenuItemState: re-invalidate accessibility if the view is unavailable

Loading

Suggested reviewers: stachbial, t0maboro, kmichalikk

Merge Risk: ⚪ Minimal · up to a5d48

No actionable regression was identified in the selective tab-item updates; this change is mergeable after normal checks.

Pre-merge checks: 4 · 1

Failed checks: 1 warning

Check name	Status	Explanation	Resolution
Docstring Coverage		Docstring coverage is 35.48% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 31 functions across 6 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

Passed checks: 4 passed

Check name	Status	Explanation
Description check		The description clearly explains the Android Tabs invalidation refactor, its behavior, implementation changes, and validation results.
Title check		The title clearly and concisely identifies the main change: applying Android tab title, badge, and accessibility updates only when invalidated.
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches: 💡 2

📝 Generate docstrings: 💡

• Commit to this branch
• Create a new PR

🛠️ Fix failing CI checks: 💡

• Commit to this branch
• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[kkafar]

This method now does something peculiar. It zeros out the state.pendingFlags - so it takes responsibility for all the updates, but then it returns flags - so a set of still invalidated flags, that need to be applied somewhere else.

Suggest architecture here that actually does make sense.

[kkafar]

Agreed, the ownership was wrong: one function cleared every flag, applied three parts, and relied on two other classes to finish the job from its return value. e3c6bde restructures it as one consumer, apply-only primitives:

• TabsMenuItemState.consumePendingFlags() reads and clears the flags. Its only caller is TabsContainer.applyPendingMenuItemChanges, which hands the flags to TabsAppearanceCoordinator.updateMenuItemAppearance (title, icon, active indicator, badge) and applies accessibility through TabsHostA11yCoordinator. Whoever consumes the flags applies everything they name.
• The applicator only applies (applyTitle, applyIcon, applyActiveIndicatorSize, updateBadgeAppearance) and knows nothing about flags. A part that can't be applied yet (no item view) is re-invalidated through TabsBottomNavigationView.invalidateMenuItem, like any other change: the active indicator as before, and accessibility too since ce494b0 (it used to be dropped until the next a11y change or bar pass).
• No isWholeBarUpdate: the bar pass (TabsContainer.updateTabBarAppearance: bar-wide appearance, then the menu items, then fonts) invalidates what it re-applies to every item and runs the same per-item path: BADGE, because badge colours come from the selected tab, and ACCESSIBILITY on appearance updates, which replaces setA11yPropertiesToAllTabItems and its index-based pairing. A fresh menu item state is still fully dirty, so rebuilt items get everything.

Side effect worth knowing: the colour-scheme path (applyDayNightUiMode) used to clear pending ACCESSIBILITY without applying it (safe only by call order). It now applies whatever it consumes. TabsHostA11yCoordinator loses its unused tabsScreenFragments constructor parameter.

#4976 and #4982 are rebased; everything compiles and passes yarn lint-android. Re-running the Android tabs Detox suites and a manual title / badge / a11y check on this PR alone (without #4976) now; I'll update the test plan with the results.

---

Generated by Claude Code

[kkafar]

Should these methods be public? It seems that internal is enough here. They are used only from inside the core, right?

[kkafar]

fb1e94a: yes, only core's tabs code calls them. They are now explicitly internal: applyIconBox, applyActiveIndicatorSize, updateSharedAppearance, updateFontStyles, applyTitle and applyIcon in TabsAppearanceApplicator, plus the same for updateBarAppearance and updateFontStyles in TabsAppearanceCoordinator. Both classes were already internal, so the effective visibility doesn't change, but the declarations now say it.

---

Generated by Claude Code

[kkafar]

Nest an if block here with the second part of the condition. It'll be easier to read IMO.

[kkafar]

fb1e94a: nested. The same "apply, and re-invalidate if the item view is missing" check for accessibility in TabsContainer.applyPendingMenuItemChanges got the same shape.

---

Generated by Claude Code

[kkafar]

Check whether there isn't a helper method already for this. If yes - use it. If not - create one. Look for other places that might use the helper method.

[kkafar]

fb1e94a: there was none for a fragment → menu item lookup; MenuHelpers.kt only had getOrCreateMenuItemForFragment. Added next to it:

• Menu.findMenuItemForFragment(fragment): MenuItem?
• Menu.requireMenuItemForFragment(fragment): MenuItem (the checkNotNull with the "Missing MenuItem" message)

Used here, in TabsContainer.getMenuItemForItem and in getOrCreateMenuItemForFragment. Those were all the findItem(fragment.menuItemId) call sites in tabs; the only other menu.findItem calls in core are the Stack header toolbar's, which look items up by their own id map.

---

Generated by Claude Code

[kkafar]

1f0d8bd: done your way. TabsBottomNavigationView now has

internal fun findMenuItem(menuItemId: Int): MenuItem? = menu.findItem(menuItemId)

internal fun requireMenuItem(menuItemId: Int): MenuItem =
    checkNotNull(findMenuItem(menuItemId)) { "[RNScreens] Missing MenuItem for id: $menuItemId" }

and the call sites are bottomNavigationView.requireMenuItem(fragment.menuItemId) (here) and bottomNavigationView.findMenuItem(fragment.menuItemId) (getMenuItemForItem). The Menu extensions from fb1e94a are gone, so MenuHelpers.kt is back to its state on main.

---

Generated by Claude Code