fix(header): read prop-synced resources, not the lagging event store#32
Draft
anton-patrushev wants to merge 5 commits into
Draft
fix(header): read prop-synced resources, not the lagging event store#32anton-patrushev wants to merge 5 commits into
anton-patrushev wants to merge 5 commits into
Conversation
…the lagging event store CalendarHeader read `resources` from the EventsProvider store via useResources(). That store field is written inside notifyDataChanged (an effect), so it lags the `resources` prop by one commit. On a single -> multi-provider transition the resource header renders empty for that frame while the band already has its height — a visible empty header band. Thread the `resources` prop through CalendarProvider context and read it in CalendarHeader, so header content stays in step with the prop (and the layout derived from it). No EventsProvider-store dependency for header rendering. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The ResourceListView branch passed `height={dayBarHeight}` but the
CalendarListView branch (byDay mode, enableResourceScroll=false) did not.
Without it the inner ScrollView collapses to 0 and the header cells
(height: '100%') resolve to 0px — provider cells render but are invisible.
Original fix by Vlad Covaliov (GlossGenius/core-mobile#14944); pulled into this
branch so the resource-header fixes ship as one change.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
anton-patrushev
force-pushed
the
fix/header-resource-prop-sync
branch
from
96ce92f to
ec9dde5
Compare
notifyDataChanged's skip-gate compared events, timezone, pagesPerSide and the date window but ignored resources — even though resources is written into the event store and fed to populateEvents (it decides which column an event packs into). On a single -> multi provider switch where the events reference is unchanged, the gate skipped the recompute, so the store kept its stale resource set and consumers reading it rendered the wrong layout. Add an identity compare on resources to the gate; the prop is memoized upstream so steady-state swipes still hit the fast skip path.
…event store CalendarBody chose its layout (enableResourceScroll, dateResourceItems) from the resources PROP via useCalendar(), but fed the resources ARRAY into ResourceListView from the EventsProvider store via useResources(). The store is written in notifyDataChanged's effect, so it lags the prop by a commit and can strand on a stale value. When the layout said 'resource mode' but the store still held no/old resources, ResourceListView computed count: 0 and rendered an empty (white) grid with no provider columns. Read resources from the same prop-synced context source as the layout decision so the two can never disagree. Mirrors the earlier CalendarHeader fix.
The header wraps its content in an Animated.ScrollView + Animated.View whose heights are useDerivedValues reading the dayBarHeight prop. On Fabric, when dayBarHeight flips 0 -> N (e.g. single -> multi resource) during a busy re-render, the animated height can fail to re-commit and the header stays clipped at the stale 0: the day-bar/resource cells lay out correctly but are clipped to invisible (a blank header band). When useAllDayEvent is false there is no expand/collapse to animate, so drive the two header heights with plain static values that update synchronously on the React commit, leaving nothing to strand. The animated path is kept for the all-day-event case.
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.
Problem
CalendarHeaderreadsresourcesfrom the EventsProvider store (useResources()). That store field is written insidenotifyDataChanged— an effect — so it lags theresourcesprop by one commit. On a single → multi-provider transition, the resource header renders empty for that frame while the header band already has its height, producing a visible empty/white header band (surfaced downstream when the consuming app removed a height animation that previously masked the gap).Fix
Thread the
resourcesprop throughCalendarProvidercontext and read it inCalendarHeaderinstead ofuseResources(). Header content now stays in step with theresourcesprop (and the layout derived from it); no EventsProvider-store dependency for header rendering.CalendarProvider: addresources?: ResourceItem[]toCalendarContextProps.CalendarContainer: pass theresourcesprop into the contextvalue(+ deps).CalendarHeader: readresourcesfromuseCalendar(); dropuseResources().Additive context field; no behavior change in steady state — only removes the one-commit lag on resource changes.
Test plan
type:checkpasses.