@rific/scroll-view 0.9.0 → 0.9.2

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Jay Deaton
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -14,7 +14,7 @@ npm install @rific/scroll-view
 npm install @rific/auto-paper react-native-reanimated react-native-gesture-handler react-native-safe-area-context react-native-paper react-native-keyboard-controller
 ```
 
-The exported Redux slice has no dependency on `@reduxjs/toolkit` — it works with RTK stores, vanilla Redux, or no Redux at all.
+The exported Redux slice has no dependency on `@reduxjs/toolkit` - it works with RTK stores, vanilla Redux, or no Redux at all.
 
 ## Quick start
 
@@ -57,7 +57,7 @@ App-wide defaults for scroll settings. Wrap your root layout to set global defau
 
 | Prop | Type | Description |
 |------|------|-------------|
-| `children` | `ReactNode` | — |
+| `children` | `ReactNode` | - |
 | `initialValue` | `Partial<ScrollViewSettings>` | Initial settings applied once on mount |
 | `onChange` | `(settings: ScrollViewSettings) => void` | Called whenever settings change |
 
@@ -70,15 +70,15 @@ Screen-level provider that owns header/footer state and scroll position. Must wr
 | Prop | Type | Default | Description |
 |------|------|---------|-------------|
 | `blur` | `boolean` | system | Enable frosted-glass backdrop on header/footer |
-| `chrome` | `boolean` | `true` | Join an enclosing [`ScrollViewChromeProvider`](#scrollviewchromeprovider) when there is one. Pass `false` to opt out — for a nested provider that isn't a screen, such as a picker or form modal. No effect when nothing hosts |
+| `chrome` | `boolean` | `true` | Join an enclosing [`ScrollViewChromeProvider`](#scrollviewchromeprovider) when there is one. Pass `false` to opt out - for a nested provider that isn't a screen, such as a picker or form modal. No effect when nothing hosts |
 | `fixed` | `boolean` | `false` | Pin both header and footer (overrides `headerFixed`/`footerFixed`) |
-| `footerAboveKeyboard` | `boolean` | `false` | With a fixed footer, float it above the keyboard instead of letting the keyboard cover it — see [Keyboard awareness](#keyboard-awareness) |
+| `footerAboveKeyboard` | `boolean` | `false` | With a fixed footer, float it above the keyboard instead of letting the keyboard cover it - see [Keyboard awareness](#keyboard-awareness) |
 | `headerFixed` | `boolean` | `false` | Pin header; overrides settings default |
 | `footerFixed` | `boolean` | `false` | Pin footer; overrides settings default |
 | `snapBack` | `boolean` | `false` | Snap header and footer back when scrolling up |
-| `snapBackHeader` | `boolean` | — | Override `snapBack` for header only |
-| `snapBackFooter` | `boolean` | — | Override `snapBack` for footer only |
-| `tabBarHeight` | `number` | `0` | Extra bottom inset reserved for a host app's own persistent tab bar (added on top of the safe-area inset, independent of any `ScrollViewFooter`). Ignored inside a `ScrollViewChromeProvider` — the host's `footprint` replaces it (see [Persistent bottom chrome](#persistent-bottom-chrome-hiding-a-tab-bar-with-scroll)) |
+| `snapBackHeader` | `boolean` | - | Override `snapBack` for header only |
+| `snapBackFooter` | `boolean` | - | Override `snapBack` for footer only |
+| `tabBarHeight` | `number` | `0` | Extra bottom inset reserved for a host app's own persistent tab bar (added on top of the safe-area inset, independent of any `ScrollViewFooter`). Ignored inside a `ScrollViewChromeProvider` - the host's `footprint` replaces it (see [Persistent bottom chrome](#persistent-bottom-chrome-hiding-a-tab-bar-with-scroll)) |
 
 ---
 
@@ -88,13 +88,13 @@ Hosts a persistent bottom bar (a tab bar) so it hides on scroll together with ea
 
 | Prop | Type | Default | Description |
 |------|------|---------|-------------|
-| `children` | `ReactNode` | — | Usually the navigator (`<Tabs>`) |
-| `footprint` | `number` | required | Height of the bar's resting box, including its bottom safe-area inset — how far above the screen bottom a hosted `ScrollViewFooter` has to sit to clear it. A plain number rather than something the bar reports back, so every screen has the right geometry on its very first render |
+| `children` | `ReactNode` | - | Usually the navigator (`<Tabs>`) |
+| `footprint` | `number` | required | Height of the bar's resting box, including its bottom safe-area inset - how far above the screen bottom a hosted `ScrollViewFooter` has to sit to clear it. A plain number rather than something the bar reports back, so every screen has the right geometry on its very first render |
 | `overhang` | `number` | `0` | How far the bar pokes *above* its resting box (a raised centre button, say). Hosted footers pad their bottom by this instead of the safe-area inset, and the hide distance covers it |
 | `snapBack` | `boolean` | `true` | Hosted footers reveal on a short scroll-up instead of only near the top. A bar that hides on scroll has to be reachable from anywhere in a list, so leave this on unless you have a reason not to |
-| `useIsActive` | `() => boolean` | `() => true` | A hook returning whether the calling screen is the focused one — pass react-navigation's `useIsFocused` (re-exported by `expo-router`). Only the focused screen drives the bar. Injected so this package carries no navigation dependency. **Must be a stable hook reference** (a module-level hook such as `useIsFocused`, never an inline arrow created per render): it is called as a hook on every render of every hosted provider |
+| `useIsActive` | `() => boolean` | `() => true` | A hook returning whether the calling screen is the focused one - pass react-navigation's `useIsFocused` (re-exported by `expo-router`). Only the focused screen drives the bar. Injected so this package carries no navigation dependency. **Must be a stable hook reference** (a module-level hook such as `useIsFocused`, never an inline arrow created per render): it is called as a hook on every render of every hosted provider |
 
-The default `() => true` makes every mounted hosted screen claim the host, and the last one to mount owns it — only right for a navigator that keeps a single screen mounted. Use `useIsFocused` with `Tabs` or anything else that keeps visited screens alive.
+The default `() => true` makes every mounted hosted screen claim the host, and the last one to mount owns it - only right for a navigator that keeps a single screen mounted. Use `useIsFocused` with `Tabs` or anything else that keeps visited screens alive.
 
 ---
 
@@ -104,18 +104,18 @@ Floating header with blur backdrop, title, back action, trailing action, and bui
 
 | Prop | Type | Default | Description |
 |------|------|---------|-------------|
-| `title` | `string` | — | Center title text |
-| `caption` | `string` | — | Subtitle below title |
-| `centerContent` | `ReactNode` | — | Replaces title/caption with custom content |
-| `children` | `ReactNode` | — | Left-side content (icon buttons, etc.) |
-| `backAction` | `() => void` | — | Renders a back button and calls this on press |
+| `title` | `string` | - | Center title text |
+| `caption` | `string` | - | Subtitle below title |
+| `centerContent` | `ReactNode` | - | Replaces title/caption with custom content |
+| `children` | `ReactNode` | - | Left-side content (icon buttons, etc.) |
+| `backAction` | `() => void` | - | Renders a back button and calls this on press |
 | `backActionFixed` | `boolean` | settings | Keep back button visible as header scrolls away |
-| `trailingAction` | `ReactNode` | — | Right-side floating action |
+| `trailingAction` | `ReactNode` | - | Right-side floating action |
 | `trailingActionFixed` | `boolean` | `true` | Keep trailing action visible as header scrolls away |
 | `actionSize` | `number` | `48` | Size of floating action buttons |
 | `iconSize` | `number` | `actionSize/2` | Icon size inside action buttons |
-| `actionStyle` | `ViewStyle` | — | Style applied to action button backgrounds |
-| `style` | `ViewStyle` | — | Style applied to the header content area |
+| `actionStyle` | `ViewStyle` | - | Style applied to action button backgrounds |
+| `style` | `ViewStyle` | - | Style applied to the header content area |
 | `topInset` | `boolean` | `true` | Pad for safe area top inset |
 
 ---
@@ -189,7 +189,7 @@ When `horizontal` and `pagingEnabled` are both true and `data` has more than one
 
 ### `SectionList`
 
-Drop-in for React Native's `SectionList`. Accepts all `SectionListProps<ItemT, SectionT>` (except `horizontal`) plus the same set of library props as `FlatList`. Custom sticky section headers are supported — pass `renderSectionHeader` and `stickySectionHeadersEnabled` and the library renders them via an animated overlay so they properly account for the floating header offset.
+Drop-in for React Native's `SectionList`. Accepts all `SectionListProps<ItemT, SectionT>` (except `horizontal`) plus the same set of library props as `FlatList`. Custom sticky section headers are supported - pass `renderSectionHeader` and `stickySectionHeadersEnabled` and the library renders them via an animated overlay so they properly account for the floating header offset.
 
 ---
 
@@ -218,7 +218,7 @@ import { CustomList } from '@rific/scroll-view'
 | `renderFilters` | `ReactNode` | Rendered below `ListHeaderComponent`, above list items |
 | `scrollRef` | `RefObject<{ scrollToOffset }>` | Forward ref to the underlying list |
 
-The underlying component receives `contentInset`, `contentOffset`, `onScroll`, `refreshControl`, and `scrollEventThrottle` — props it must support for the library to function.
+The underlying component receives `contentInset`, `contentOffset`, `onScroll`, `refreshControl`, and `scrollEventThrottle` - props it must support for the library to function.
 
 ---
 
@@ -282,7 +282,7 @@ export default function SearchScreen() {
 | Prop | Type | Description |
 |------|------|-------------|
 | `onChangeText` | `(text: string) => void` | Called with trimmed search text |
-| `onHeightChange` | `(height: number) => void` | Required — pass the height back as `pullSearchHeight` |
+| `onHeightChange` | `(height: number) => void` | Required - pass the height back as `pullSearchHeight` |
 | `value` | `string` | Controlled value |
 | `placeholder` | `string` | Placeholder text |
 | `debounce` | `boolean` | Debounce `onChangeText` by 500ms |
@@ -305,7 +305,7 @@ Pass `keyboardAware` to any scroll component (`ScrollView`, `FlatList`, `Section
 </ScrollViewProvider>
 ```
 
-By default, a fixed `ScrollViewFooter` doesn't follow the keyboard — it stays pinned to the screen bottom and the keyboard simply covers it. If the footer holds something the user needs while typing (a submit button, say), set `footerAboveKeyboard` on `ScrollViewProvider` so the footer floats above the keyboard instead, reachable without dismissing it first:
+By default, a fixed `ScrollViewFooter` doesn't follow the keyboard - it stays pinned to the screen bottom and the keyboard simply covers it. If the footer holds something the user needs while typing (a submit button, say), set `footerAboveKeyboard` on `ScrollViewProvider` so the footer floats above the keyboard instead, reachable without dismissing it first:
 
 ```tsx
 <ScrollViewProvider footerFixed footerAboveKeyboard>
@@ -320,25 +320,25 @@ By default, a fixed `ScrollViewFooter` doesn't follow the keyboard — it stays
 </ScrollViewProvider>
 ```
 
-`footerAboveKeyboard` only has an effect when the footer is fixed (`footerFixed`) — a footer that scrolls away with content has nothing to reserve keyboard space for. Always pair it with `keyboardAware: true` on any scroll component that could have a focused input while it's visible. Content always reserves space for the current footer height regardless of `keyboardAware` (so a fixed footer never overlaps it) — and while floating, that height already includes the keyboard, so a list with `keyboardAware: false` ends up reserving keyboard space anyway, just indirectly through the footer rather than directly. There's no useful configuration where you'd want the footer reachable above the keyboard but *not* want that same list's own content clear of it too, so don't rely on `keyboardAware: false` to opt a list out of this while `footerAboveKeyboard` is on — it won't.
+`footerAboveKeyboard` only has an effect when the footer is fixed (`footerFixed`) - a footer that scrolls away with content has nothing to reserve keyboard space for. Always pair it with `keyboardAware: true` on any scroll component that could have a focused input while it's visible. Content always reserves space for the current footer height regardless of `keyboardAware` (so a fixed footer never overlaps it) - and while floating, that height already includes the keyboard, so a list with `keyboardAware: false` ends up reserving keyboard space anyway, just indirectly through the footer rather than directly. There's no useful configuration where you'd want the footer reachable above the keyboard but *not* want that same list's own content clear of it too, so don't rely on `keyboardAware: false` to opt a list out of this while `footerAboveKeyboard` is on - it won't.
 
-Floating is done by growing the footer's own container rather than translating it, so its `BlurView` backdrop always stays sealed against the true physical screen bottom — nothing shows through beneath it, including at the keyboard's rounded top corners.
+Floating is done by growing the footer's own container rather than translating it, so its `BlurView` backdrop always stays sealed against the true physical screen bottom - nothing shows through beneath it, including at the keyboard's rounded top corners.
 
-While floating above an open keyboard, the footer also drops its safe-area bottom inset — it's no longer sitting at the physical screen edge, so that padding would just be dead space under its content. As the keyboard closes, the inset ramps back in continuously over the last bit of its travel rather than snapping back once it's fully closed, so the content settles at the safe-area line smoothly instead of dropping to the physical bottom edge and correcting back up.
+While floating above an open keyboard, the footer also drops its safe-area bottom inset - it's no longer sitting at the physical screen edge, so that padding would just be dead space under its content. As the keyboard closes, the inset ramps back in continuously over the last bit of its travel rather than snapping back once it's fully closed, so the content settles at the safe-area line smoothly instead of dropping to the physical bottom edge and correcting back up.
 
-Keyboard awareness is native-only — `useKeyboardInset` (and therefore `keyboardAware`/`footerAboveKeyboard`) always resolves to `0` height on web.
+Keyboard awareness is native-only - `useKeyboardInset` (and therefore `keyboardAware`/`footerAboveKeyboard`) always resolves to `0` height on web.
 
 ---
 
 ## Persistent bottom chrome (hiding a tab bar with scroll)
 
-A `ScrollViewFooter` hides on scroll, but an app's tab bar lives outside this package — it stays put, and the footer has to be lifted above it with `tabBarHeight`. `ScrollViewChromeProvider` turns the two into one rigid stack: the screen's footer and the tab bar share a single animated offset, so they hide and reveal together as one piece, frame for frame.
+A `ScrollViewFooter` hides on scroll, but an app's tab bar lives outside this package - it stays put, and the footer has to be lifted above it with `tabBarHeight`. `ScrollViewChromeProvider` turns the two into one rigid stack: the screen's footer and the tab bar share a single animated offset, so they hide and reveal together as one piece, frame for frame.
 
 Three pieces make it work:
 
-1. **Host** — mount `ScrollViewChromeProvider` above the navigator, giving it the bar's `footprint`.
-2. **Screens** — nothing to change. Each `ScrollViewProvider` (and its `ScrollViewHeader`, `ScrollViewFooter`, scroll component) below the host joins it while its screen is focused.
-3. **Bar** — your own tab bar reads the shared offset with `useScrollViewChromeStyle()` and applies it as an animated style. It has to overlay the screen (absolutely positioned at the bottom) with a resting box exactly `footprint` tall, since hosted footers are lifted by that number.
+1. **Host** - mount `ScrollViewChromeProvider` above the navigator, giving it the bar's `footprint`.
+2. **Screens** - nothing to change. Each `ScrollViewProvider` (and its `ScrollViewHeader`, `ScrollViewFooter`, scroll component) below the host joins it while its screen is focused.
+3. **Bar** - your own tab bar reads the shared offset with `useScrollViewChromeStyle()` and applies it as an animated style. It has to overlay the screen (absolutely positioned at the bottom) with a resting box exactly `footprint` tall, since hosted footers are lifted by that number.
 
 ```tsx
 // app/(tabs)/_layout.tsx
@@ -389,7 +389,7 @@ const styles = StyleSheet.create({
 })
 ```
 
-Screens are written exactly as they were — there is no chrome-specific prop on the happy path:
+Screens are written exactly as they were - there is no chrome-specific prop on the happy path:
 
 ```tsx
 // app/(tabs)/library.tsx
@@ -408,7 +408,7 @@ export default function Library() {
 
 ### Pinning the bar
 
-`useScrollViewChromePin(active)` holds the bar fully revealed — and stops scroll from hiding it — for as long as `active` is `true`. Use it whenever something on screen needs the bar to stay put, such as a focused search field or a multi-select in progress. Pins are counted, so two independent pinners can't release each other, and it works from any component under the host (below a `ScrollViewProvider` too).
+`useScrollViewChromePin(active)` holds the bar fully revealed - and stops scroll from hiding it - for as long as `active` is `true`. Use it whenever something on screen needs the bar to stay put, such as a focused search field or a multi-select in progress. Pins are counted, so two independent pinners can't release each other, and it works from any component under the host (below a `ScrollViewProvider` too).
 
 ```tsx
 function SearchField() {
@@ -418,11 +418,11 @@ function SearchField() {
 }
 ```
 
-`useScrollViewChromeReveal()` returns a function that animates the bar back to fully revealed (200ms) — handy for a tab press or a "scroll to top" action, as in the example above.
+`useScrollViewChromeReveal()` returns a function that animates the bar back to fully revealed (200ms) - handy for a tab press or a "scroll to top" action, as in the example above.
 
 ### Nested providers that aren't screens
 
-A `ScrollViewProvider` nested inside another one never sees the host: every hosted provider clears it for its own children, so a panel inside a screen can't compete with its parent. A picker or form modal is the exception — a portal can re-parent it out from under its screen's provider, and it would then claim the host and drive the bar from its own scrolling. Pass `chrome={false}` to opt those out:
+A `ScrollViewProvider` nested inside another one never sees the host: every hosted provider clears it for its own children, so a panel inside a screen can't compete with its parent. A picker or form modal is the exception - a portal can re-parent it out from under its screen's provider, and it would then claim the host and drive the bar from its own scrolling. Pass `chrome={false}` to opt those out:
 
 ```tsx
 <ScrollViewProvider chrome={false} footerFixed>
@@ -435,18 +435,18 @@ A `ScrollViewProvider` nested inside another one never sees the host: every host
 
 ### What changes for a hosted screen
 
-- **The footer joins the stack.** It sits `footprint` above the screen bottom, translates by the shared offset (clamped to the full hide distance), and pads its bottom by `overhang` instead of the safe-area inset — the bar's `footprint` already includes that inset.
+- **The footer joins the stack.** It sits `footprint` above the screen bottom, translates by the shared offset (clamped to the full hide distance), and pads its bottom by `overhang` instead of the safe-area inset - the bar's `footprint` already includes that inset.
 - **Hide distance.** The stack slides `footprint + max(footerHeight, overhang) + 2` points: the bar, plus the screen's footer (whose measured height already includes the `overhang` padding; with no footer, just the `overhang`), plus 2 points of slack so a soft shadow bleeding past the bar's box doesn't leave a sliver at the screen edge.
 - **Footer snap-back is forced.** A hosted footer follows the host's `snapBack` (default `true`) whatever the provider, `snapBackFooter` or settings values say, so the stack reveals on a short scroll-up from anywhere in a list. The header's own snap-back is untouched.
-- **Scrolling stops at an end.** Hiding tracks the scroll 1:1, so a drag can end with the stack half hidden. When a drag ends without momentum, or momentum ends, the stack animates (200ms) to whichever end is nearer — fully shown or fully hidden, never cut off.
+- **Scrolling stops at an end.** Hiding tracks the scroll 1:1, so a drag can end with the stack half hidden. When a drag ends without momentum, or momentum ends, the stack animates (200ms) to whichever end is nearer - fully shown or fully hidden, never cut off.
 - **Short lists never hide.** A list that can't scroll at least the hide distance would strand the stack half hidden, so it never starts hiding and stays revealed.
 - **Footer Lock keeps it revealed.** A fixed footer (`footerFixed`, `fixed`, or the settings default) stops the scroll handlers from writing the offset, and turning it on while the stack is hidden animates the stack back. The hosted footer still reads the shared offset rather than pinning itself to zero, so the footer and the bar stay equal on every frame, including that animation.
-- **The focused screen owns the bar.** Screens that are mounted but unfocused never write the offset. Whenever ownership changes — switching tabs, or landing on a screen with no `ScrollViewProvider` at all — the stack resets to fully revealed instead of staying wherever the last screen parked it. A pin engaging does the same.
-- **The reserved bottom inset stays constant while hidden.** Scroll content reserves `footprint` plus the overhang (or a fixed footer's height) at the bottom. That space can't animate, so it stays reserved as the bar slides away rather than the list resizing mid-scroll — the last row can always scroll clear of a revealed bar, and nothing shifts when the bar hides.
+- **The focused screen owns the bar.** Screens that are mounted but unfocused never write the offset. Whenever ownership changes - switching tabs, or landing on a screen with no `ScrollViewProvider` at all - the stack resets to fully revealed instead of staying wherever the last screen parked it. A pin engaging does the same.
+- **The reserved bottom inset stays constant while hidden.** Scroll content reserves `footprint` plus the overhang (or a fixed footer's height) at the bottom. That space can't animate, so it stays reserved as the bar slides away rather than the list resizing mid-scroll - the last row can always scroll clear of a revealed bar, and nothing shifts when the bar hides.
 - **`tabBarHeight` is ignored.** The host's `footprint` is the same "reserve this much at the bottom" number, just known exactly, and takes its place.
 - **With a fixed footer floating above the keyboard** (`footerFixed` + `footerAboveKeyboard`), the footer sits above whichever is taller, the bar or the keyboard, instead of floating a whole bar-height above the keyboard.
 
-Outside a host — or in a provider with `chrome={false}` — none of this applies and every behavior in the rest of this README is unchanged. `useScrollViewChromeStyle`, `useScrollViewChromePin` and `useScrollViewChromeReveal` are also inert there (a permanent zero translate, a no-op pin and a no-op reveal), so a shared tab bar component can call them unconditionally.
+Outside a host - or in a provider with `chrome={false}` - none of this applies and every behavior in the rest of this README is unchanged. `useScrollViewChromeStyle`, `useScrollViewChromePin` and `useScrollViewChromeReveal` are also inert there (a permanent zero translate, a no-op pin and a no-op reveal), so a shared tab bar component can call them unconditionally.
 
 ---
 
@@ -465,7 +465,7 @@ const { scrollPosition, scrollHeight, progressing, progress, setProgress, setPro
 | `scrollPosition` | `SharedValue<number>` | Live scroll offset (Reanimated worklet-safe) |
 | `scrollHeight` | `number` | Visible scroll area height (window minus header/footer) |
 | `progressing` | `boolean` | Whether the header progress bar is visible |
-| `progress` | `number \| null` | Progress bar value (0–1), or `null` for indeterminate |
+| `progress` | `number \| null` | Progress bar value (0-1), or `null` for indeterminate |
 | `setProgress` | `(p: number \| null) => void` | Set progress; pass `null` for indeterminate |
 | `setProgressing` | `(b: boolean) => void` | Show/hide the progress bar |
 
@@ -567,8 +567,8 @@ store.dispatch(scrollViewActions.initialize({ snapBack: true, headerFixed: false
 | `headerFixed` | `false` | Pin header globally |
 | `footerFixed` | `false` | Pin footer globally |
 | `snapBack` | `false` | Snap header and footer back when scrolling up |
-| `snapBackHeader` | — | Override `snapBack` for header only |
-| `snapBackFooter` | — | Override `snapBack` for footer only |
+| `snapBackHeader` | - | Override `snapBack` for header only |
+| `snapBackFooter` | - | Override `snapBack` for footer only |
 | `backActionFixed` | `true` | Keep back button visible as header scrolls away |
 
 Settings cascade: `ScrollViewSettingsProvider` → `ScrollViewProvider` → individual scroll component props. More specific values always win.

package/dist/index.js

@@ -956,7 +956,7 @@ var PullSearch = (0, import_react10.forwardRef)(function PullSearch2({ debounce,
     (isHidden, wasHidden) => {
       if (isHidden && !wasHidden) (0, import_react_native_reanimated9.runOnJS)(blurInput)();
     },
-    // scrollPosition has to be listed too, not just read — see useStickyHeaders' useAnimatedReaction
+    // scrollPosition has to be listed too, not just read - see useStickyHeaders' useAnimatedReaction
     // for why: on web, without reanimated's Babel plugin active, an unlisted SharedValue mutation
     // never re-triggers this reaction (confirmed empirically elsewhere in this package).
     [barHeight, headerHeight, blurInput, scrollPosition]
@@ -1393,7 +1393,7 @@ var ScrollViewProvider = ({ blur, chrome, children, fixed = false, footerAboveKe
   (0, import_react17.useEffect)(() => {
     if (!__DEV__ || headerHeight !== null) return;
     const timeout = setTimeout(() => {
-      console.warn("[scroll-view] No ScrollViewHeader ever measured inside this ScrollViewProvider \u2014 scroll content stays hidden (opacity: 0) until one does. Render a <ScrollViewHeader> (it can be empty / zero height) inside this provider.");
+      console.warn("[scroll-view] No ScrollViewHeader ever measured inside this ScrollViewProvider: scroll content stays hidden (opacity: 0) until one does. Render a <ScrollViewHeader> (it can be empty / zero height) inside this provider.");
     }, 3e3);
     return () => clearTimeout(timeout);
   }, [headerHeight]);
@@ -1486,7 +1486,7 @@ function useStickyHeaders(headerFixed, enabled) {
     // Same web-only reanimated gap as useAnimatedStyle elsewhere in this file: this "prepare"
     // function's own SharedValue reads (sectionYPositions, headerHeightShared, scrollPosition,
     // snapBackHeaderShared, headerOffset, pullSearchHeightShared) need to be listed explicitly too
-    // — confirmed empirically that without them, useAnimatedReaction re-evaluates once on mount and
+    // - confirmed empirically that without them, useAnimatedReaction re-evaluates once on mount and
     // then never again on web, permanently freezing activeIndex/the active sticky section.
     [enabled, headerFixed, insetsTop, sectionYPositions, headerHeightShared, scrollPosition, snapBackHeaderShared, headerOffset, pullSearchHeightShared]
   );

package/dist/index.mjs

@@ -900,7 +900,7 @@ var PullSearch = forwardRef(function PullSearch2({ debounce, onChangeText, onHei
     (isHidden, wasHidden) => {
       if (isHidden && !wasHidden) runOnJS3(blurInput)();
     },
-    // scrollPosition has to be listed too, not just read — see useStickyHeaders' useAnimatedReaction
+    // scrollPosition has to be listed too, not just read - see useStickyHeaders' useAnimatedReaction
     // for why: on web, without reanimated's Babel plugin active, an unlisted SharedValue mutation
     // never re-triggers this reaction (confirmed empirically elsewhere in this package).
     [barHeight, headerHeight, blurInput, scrollPosition]
@@ -1337,7 +1337,7 @@ var ScrollViewProvider = ({ blur, chrome, children, fixed = false, footerAboveKe
   useEffect7(() => {
     if (!__DEV__ || headerHeight !== null) return;
     const timeout = setTimeout(() => {
-      console.warn("[scroll-view] No ScrollViewHeader ever measured inside this ScrollViewProvider \u2014 scroll content stays hidden (opacity: 0) until one does. Render a <ScrollViewHeader> (it can be empty / zero height) inside this provider.");
+      console.warn("[scroll-view] No ScrollViewHeader ever measured inside this ScrollViewProvider: scroll content stays hidden (opacity: 0) until one does. Render a <ScrollViewHeader> (it can be empty / zero height) inside this provider.");
     }, 3e3);
     return () => clearTimeout(timeout);
   }, [headerHeight]);
@@ -1430,7 +1430,7 @@ function useStickyHeaders(headerFixed, enabled) {
     // Same web-only reanimated gap as useAnimatedStyle elsewhere in this file: this "prepare"
     // function's own SharedValue reads (sectionYPositions, headerHeightShared, scrollPosition,
     // snapBackHeaderShared, headerOffset, pullSearchHeightShared) need to be listed explicitly too
-    // — confirmed empirically that without them, useAnimatedReaction re-evaluates once on mount and
+    // - confirmed empirically that without them, useAnimatedReaction re-evaluates once on mount and
     // then never again on web, permanently freezing activeIndex/the active sticky section.
     [enabled, headerFixed, insetsTop, sectionYPositions, headerHeightShared, scrollPosition, snapBackHeaderShared, headerOffset, pullSearchHeightShared]
   );

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rific/scroll-view",
-  "version": "0.9.0",
+  "version": "0.9.2",
   "description": "Blur styled scroll system for React Native. Floating headers/footers, keyboard awareness, and scroll-away chrome",
   "keywords": [
     "react-native",
@@ -62,11 +62,11 @@
   "prettier": "@infinitetoken/eslint-config/prettier",
   "devDependencies": {
     "@infinitetoken/eslint-config": "0.2.0",
-    "@infinitetoken/jest-config": "^0.4.0",
-    "@infinitetoken/tsconfig": "^0.5.0",
+    "@infinitetoken/jest-config": "^0.5.1",
+    "@infinitetoken/tsconfig": "^0.6.0",
     "@reduxjs/toolkit": "^2.12.0",
-    "@rific/auto-paper": "^0.12.0",
-    "@rific/core": "^0.2.0",
+    "@rific/auto-paper": "^0.13.3",
+    "@rific/core": "^0.3.1",
     "@testing-library/dom": "^10.4.1",
     "@testing-library/react": "^16.3.2",
     "@types/jest": "^30.0.0",
@@ -80,13 +80,13 @@
     "prettier": "^3.8.3",
     "react": "^19.0.0",
     "react-dom": "^19.0.0",
-    "react-native": "^0.83.0",
-    "react-native-gesture-handler": "^2.32.0",
+    "react-native": "^0.88.0",
+    "react-native-gesture-handler": "^3.3.0",
     "react-native-keyboard-controller": "*",
     "react-native-paper": "^5.12.0",
-    "react-native-reanimated": "^4.5.1",
+    "react-native-reanimated": "^4.7.1",
     "react-native-safe-area-context": "*",
-    "react-native-worklets": "^0.10.3",
+    "react-native-worklets": "^0.13.0",
     "tsup": "^8.0.0",
     "typescript": "^6.0.3"
   },
@@ -95,7 +95,7 @@
     "@rific/core": ">=0.1.1",
     "react": ">=19.0.0",
     "react-native": ">=0.83.0",
-    "react-native-gesture-handler": ">=2.0.0 <3.0.0",
+    "react-native-gesture-handler": ">=2.0.0 <4.0.0",
     "react-native-keyboard-controller": ">=1.0.0",
     "react-native-paper": ">=5.0.0",
     "react-native-reanimated": ">=4.0.0",

package/src/CustomList.tsx

@@ -38,13 +38,13 @@ const CustomListInner = <P extends object>({ chipProps, chipThreshold, component
 
   const { chipHidden, chipStyle, containerStyle, contentInset, contentOffset, contentPadding, footerFixed, headerFixed } = useScrollList({ footerFixed: footerFixedProp, headerFixed: headerFixedProp, keyboardAware, pullSearchHeight, style })
   const { listGeneration, onListUnmount } = useContext(ScrollViewContext)
-  // -1 never matches a real generation (starts at 0, only increments) — the runOnUI call below
+  // -1 never matches a real generation (starts at 0, only increments) - the runOnUI call below
   // corrects it before any scroll event could observe the placeholder.
   const capturedGeneration = useSharedValue(-1)
   // Layout effects (not passive effects): React guarantees all layout-effect cleanups for fibers
   // removed in a commit run before any layout-effect setups for fibers added in that same commit,
   // but gives no such ordering guarantee for passive effects. On a key-forced remount, the outgoing
-  // instance's unmount and the incoming instance's mount land in the same commit — with passive
+  // instance's unmount and the incoming instance's mount land in the same commit - with passive
   // effects, the incoming instance's sync could run before the outgoing instance's bump, permanently
   // capturing a stale generation and silently disabling this instance's onScroll handling forever.
   // Correct ordering alone isn't sufficient, though: the onScroll worklet reads capturedGeneration
@@ -54,7 +54,7 @@ const CustomListInner = <P extends object>({ chipProps, chipThreshold, component
   // own serial queue, so it's guaranteed to run before any onScroll worklet invocation that could
   // only be queued after this component finishes mounting.
   //
-  // Web has no such thread split, though — see ScrollView.tsx's own doc comment on this same
+  // Web has no such thread split, though - see ScrollView.tsx's own doc comment on this same
   // pattern for why runOnUI's deferred-to-next-frame behavior there leaves a real gap, and why a
   // synchronous assignment is the correct fix rather than a workaround.
   useLayoutEffect(() => {

package/src/FlatList.tsx

@@ -30,9 +30,9 @@ export type FlatListProps<T> = Omit<RNFlatListProps<T>, 'onRefresh' | 'refreshin
 
 const FlatListInner = <T,>({ chipProps, chipThreshold, columnWrapperStyle, contentContainerStyle: externalContentContainerStyle, data, initialNumToRender = 20, keyExtractor, maxToRenderPerBatch = 50, numColumns, renderFilters, renderItem, footerFixed: footerFixedProp, gesture, headerFixed: headerFixedProp, horizontal, keyboardAware, ListHeaderComponent: externalListHeaderComponent, onChipPress, onMomentumScrollEnd: externalMomentumScrollEnd, onRefresh, onScrollBeginDrag: externalScrollBeginDrag, onScrollEndDrag: externalScrollEndDrag, pagingEnabled, pullSearchHeight, refreshing, removeClippedSubviews = false, showsHorizontalScrollIndicator, showsVerticalScrollIndicator, style, onContentSizeChange, ref: externalRef, windowSize = 100, ...props }: FlatListProps<T>) => {
   // Plain (non-Animated) FlatList: react-native-reanimated's Animated.FlatList does not reliably
-  // honor the initial `contentOffset` prop on a key-forced remount — the header/list can briefly
+  // honor the initial `contentOffset` prop on a key-forced remount - the header/list can briefly
   // render at the wrong position. A plain FlatList honors it correctly, so scroll position is driven
-  // by a regular JS onScroll callback (useScrollHandlerJS) instead of a Reanimated worklet — which
+  // by a regular JS onScroll callback (useScrollHandlerJS) instead of a Reanimated worklet - which
   // also avoids the "WorkletEventHandler" crash that a worklet handler triggers when attached to a
   // non-Animated component.
   const scrollView = useRef<RNFlatList<T>>(null)
@@ -42,10 +42,10 @@ const FlatListInner = <T,>({ chipProps, chipThreshold, columnWrapperStyle, conte
   // RN's own FlatList implements numColumns by chunking `data` into rows internally, but throws if
   // numColumns ever changes without the caller changing `key` to force a full remount. On iOS,
   // Fabric pools/recycles native ScrollView instances by component type across such a remount, and
-  // the recycled instance's onScroll can silently stop firing for the new React instance entirely —
+  // the recycled instance's onScroll can silently stop firing for the new React instance entirely -
   // a native event-routing issue, not something a JS-side retry loop can detect or correct. Doing
   // the row-chunking ourselves here and always passing numColumns={1} through to the underlying
-  // RNFlatList means numColumns never "changes" from RN's perspective — only `data`/`renderItem`
+  // RNFlatList means numColumns never "changes" from RN's perspective - only `data`/`renderItem`
   // change, which RNFlatList treats as an ordinary prop update with no remount at all, so callers
   // can toggle numColumns freely (e.g. switching a list to a grid) without ever hitting this class
   // of bug.

package/src/PullSearch.tsx

@@ -47,7 +47,7 @@ export const PullSearch = forwardRef<PullSearchHandle, PullSearchProps>(function
     (isHidden, wasHidden) => {
       if (isHidden && !wasHidden) runOnJS(blurInput)()
     },
-    // scrollPosition has to be listed too, not just read — see useStickyHeaders' useAnimatedReaction
+    // scrollPosition has to be listed too, not just read - see useStickyHeaders' useAnimatedReaction
     // for why: on web, without reanimated's Babel plugin active, an unlisted SharedValue mutation
     // never re-triggers this reaction (confirmed empirically elsewhere in this package).
     [barHeight, headerHeight, blurInput, scrollPosition]

package/src/ScrollView.tsx

@@ -32,13 +32,13 @@ const ScrollViewInner = ({ chipProps, chipThreshold, children, contentContainerS
 
   const { chipHidden, chipStyle, containerStyle, contentInset, contentOffset, contentPadding, footerFixed, headerFixed } = useScrollList({ footerFixed: footerFixedProp, headerFixed: headerFixedProp, isHorizontal, keyboardAware, pullSearchHeight, style })
   const { listGeneration, onListUnmount } = useContext(ScrollViewContext)
-  // -1 never matches a real generation (starts at 0, only increments) — the runOnUI call below
+  // -1 never matches a real generation (starts at 0, only increments) - the runOnUI call below
   // corrects it before any scroll event could observe the placeholder.
   const capturedGeneration = useSharedValue(-1)
   // Layout effects (not passive effects): React guarantees all layout-effect cleanups for fibers
   // removed in a commit run before any layout-effect setups for fibers added in that same commit,
   // but gives no such ordering guarantee for passive effects. On a key-forced remount, the outgoing
-  // instance's unmount and the incoming instance's mount land in the same commit — with passive
+  // instance's unmount and the incoming instance's mount land in the same commit - with passive
   // effects, the incoming instance's sync could run before the outgoing instance's bump, permanently
   // capturing a stale generation and silently disabling this instance's onScroll handling forever.
   // Correct ordering alone isn't sufficient, though: the onScroll worklet reads capturedGeneration
@@ -48,12 +48,12 @@ const ScrollViewInner = ({ chipProps, chipThreshold, children, contentContainerS
   // own serial queue, so it's guaranteed to run before any onScroll worklet invocation that could
   // only be queued after this component finishes mounting.
   //
-  // Web has no such thread split, though — react-native-worklets' own runOnUI there (see its
+  // Web has no such thread split, though - react-native-worklets' own runOnUI there (see its
   // threads.js) only enqueues the callback for the NEXT requestAnimationFrame, it doesn't run it
   // synchronously. That opens exactly the gap the native path exists to close: a scroll event
   // (including useScrollInit's own mount-time imperative scrollTo) landing before that deferred
   // frame sees capturedGeneration still at its -1 placeholder, fails the generation check below,
-  // and — since this effect only ever runs once per mount — never gets a second chance, silently
+  // and - since this effect only ever runs once per mount - never gets a second chance, silently
   // disabling scroll tracking (and therefore header/footer scroll-away) for this instance's entire
   // lifetime. Assigning directly is both simpler and provably correct on web: single-threaded JS
   // makes a synchronous write immediately visible to any read that follows it in program order, so

package/src/ScrollViewChromeProvider.tsx

@@ -18,7 +18,7 @@ export type ScrollViewChromeProviderProps = {
   // their bottom by this instead of the safe-area inset, and the hide distance covers it.
   overhang?: number
   // Hosted footers reveal on a short scroll-up instead of only near the top. A bar that hides on
-  // scroll has to be reachable from anywhere in a list, so this is on by default — and there is no
+  // scroll has to be reachable from anywhere in a list, so this is on by default - and there is no
   // "hide but only reveal near the top" mode: `snapBack={false}` turns hiding off entirely, leaving
   // the bar and hosted footers permanently revealed.
   snapBack?: boolean
@@ -30,7 +30,7 @@ export type ScrollViewChromeProviderProps = {
 
 // Mounted once above a navigator (a Tabs layout). Every ScrollViewProvider below it that is focused
 // claims it, and while it does, that screen's scroll handlers drive one shared `offset` that the
-// screen's own ScrollViewFooter AND the persistent bar both translate by — a single value read by
+// screen's own ScrollViewFooter AND the persistent bar both translate by - a single value read by
 // both, so the two move as one rigid stack instead of being two animations that have to be kept in
 // step.
 export const ScrollViewChromeProvider = ({ children, footprint, overhang = 0, snapBack = true, useIsActive = alwaysActive }: ScrollViewChromeProviderProps) => {

package/src/ScrollViewContext.ts

@@ -23,7 +23,7 @@ export type ScrollViewContextType = {
   // Plain (non-Reanimated) counter for JS-thread-only scroll handlers (FlatList's useScrollHandlerJS).
   // A SharedValue is deliberately NOT used here: mutating `.value` from inside a React commit-phase
   // callback (a layout effect) is not synchronously visible even to an immediate subsequent read in
-  // the same callback — Reanimated defers the actual flush — which silently broke the "did another
+  // the same callback - Reanimated defers the actual flush - which silently broke the "did another
   // list instance just unmount" check this counter exists for. A plain ref has no such batching.
   jsListGeneration: RefObject<number>
   listGeneration: SharedValue<number>

package/src/ScrollViewFooter.tsx

@@ -18,7 +18,7 @@ export const ScrollViewFooter = ({ children, style }: ScrollViewFooterProps) =>
   const keyboardHeight = useKeyboardInset()
   // setFooterHeight used to change identity on every real measurement (ScrollViewProvider's
   // useCallback closed over `footerHeight` itself). Depending on it directly here re-ran this
-  // effect on every measurement too — tearing down the PREVIOUS closure as a "cleanup" and calling
+  // effect on every measurement too - tearing down the PREVIOUS closure as a "cleanup" and calling
   // ITS setFooterHeight(null) right after the real height had just been set, permanently clobbering
   // it back to null with no further layout event left to recover it (the DOM node's true size never
   // changed, so onLayout never fires again). The provider's setter is stable now, but the context
@@ -46,11 +46,11 @@ export const ScrollViewFooter = ({ children, style }: ScrollViewFooterProps) =>
   }
   // See ScrollViewHeader's translateStyle/blurStyle/progressStyle for why every SharedValue read
   // here (scrollPosition, headerHeightShared, pullSearchHeightShared, snapBackFooterShared,
-  // footerOffset) also has to be listed explicitly — on web, reanimated doesn't pick up their
+  // footerOffset) also has to be listed explicitly - on web, reanimated doesn't pick up their
   // mutations as reactive triggers unless they're in this array, unlike native.
   const footerStyle = useAnimatedStyle(() => {
     // Hosted, the offset is the ONE value the persistent bar translates by too, so it is always
-    // read straight through — never short-circuited to 0 for footerFixed the way the unhosted path
+    // read straight through - never short-circuited to 0 for footerFixed the way the unhosted path
     // below is. Footer Lock reaches it by animating the shared offset back to 0 instead (see
     // ChromeRegistrar), which keeps this footer and the bar equal on every frame, including the
     // ones where one would otherwise jump and the other animate.
@@ -62,7 +62,7 @@ export const ScrollViewFooter = ({ children, style }: ScrollViewFooterProps) =>
     return { transform: [{ translateY: Math.min(effective, footerHeight ?? 0) }] }
   }, [chromeHosted, footerHeight, footerFixed, headerHeightShared, pullSearchHeightShared, scrollPosition, snapBackFooterShared, footerOffset, stackHeightShared])
   // Floating above the keyboard is done by GROWING this container (via paddingBottom) rather than
-  // translating it. Translating the whole bar left its bottom edge — and the BlurView filling it —
+  // translating it. Translating the whole bar left its bottom edge - and the BlurView filling it -
   // floating above the true screen bottom, exposing a gap of whatever sits behind (visible as a
   // strip above the keyboard, and worse at the keyboard's rounded top corners, which dip below its
   // reported height). Growing the container instead keeps its `bottom: 0` anchor untouched: the
@@ -71,7 +71,7 @@ export const ScrollViewFooter = ({ children, style }: ScrollViewFooterProps) =>
   // as the old translateY did for it.
   const containerPaddingBottom = footerFixed && footerAboveKeyboard ? keyboardHeight : 0
   // Web only, same as ScrollViewHeader's pre-paint measurement: react-native-web's onLayout lands
-  // well after the first paint (a ResizeObserver callback plus a setTimeout measure — over a second
+  // well after the first paint (a ResizeObserver callback plus a setTimeout measure - over a second
   // on a cold load), and until footerHeight is known this footer draws no backdrop (see the
   // BlurView gate below) and the list reserves no room for it, so the row floated bare over the
   // content and its bar only appeared once the measurement arrived. Measuring the row here, after
@@ -90,13 +90,13 @@ export const ScrollViewFooter = ({ children, style }: ScrollViewFooterProps) =>
   }, [])
   // The safe-area bottom inset exists to clear the home indicator at the physical screen edge.
   // Once footerAboveKeyboard has floated this bar's content up above an open keyboard, it's no
-  // longer sitting at that edge — the keyboard itself now occupies that space — so the inset would
+  // longer sitting at that edge - the keyboard itself now occupies that space - so the inset would
   // just be dead space under the content (e.g. under a Save button) for no reason.
   //
   // This has to ramp continuously with keyboardHeight, not flip as a boolean once the keyboard
   // fully closes: containerPaddingBottom above already tracks keyboardHeight every frame, so a
   // step-function padding change here lands in the same frame keyboardHeight hits 0, growing this
-  // row by insets.bottom right as the container finishes shrinking back down — the content visually
+  // row by insets.bottom right as the container finishes shrinking back down - the content visually
   // overshoots to the physical bottom edge and then snaps back up. Ramping this padding by the same
   // keyboardHeight keeps the content's on-screen position moving continuously throughout: for
   // keyboardHeight >= insets.bottom the padding is 0 (unchanged from mid-close), and for the last
@@ -105,7 +105,7 @@ export const ScrollViewFooter = ({ children, style }: ScrollViewFooterProps) =>
   // of dropping past it and correcting back up.
   //
   // Hosted, the bar (which already includes the safe-area inset in its own footprint) sits below
-  // this footer, so the row's bottom padding is only what pokes above the bar (a FAB) — not the
+  // this footer, so the row's bottom padding is only what pokes above the bar (a FAB) - not the
   // inset a second time.
   const bottomPadding = chromeHosted ? chromeOverhang : insets.bottom
   const rowPaddingBottom = footerFixed && footerAboveKeyboard ? Math.max(bottomPadding - keyboardHeight, 0) : bottomPadding
@@ -116,7 +116,7 @@ export const ScrollViewFooter = ({ children, style }: ScrollViewFooterProps) =>
   const footerBottom = chromeHosted && footerFixed && footerAboveKeyboard ? Math.max(tabBarHeight - keyboardHeight, 0) : tabBarHeight
   // A consumer's own `style.paddingBottom` (e.g. tightening the row's vertical rhythm to match a
   // header's actionMargin) is spread after rowPaddingBottom below, so it has to be added to it
-  // rather than assigned after it — plain style-array merge would otherwise let it silently
+  // rather than assigned after it - plain style-array merge would otherwise let it silently
   // replace the safe-area clearance instead of sitting on top of it, leaving the row's real
   // content (buttons, etc.) flush against the home indicator.
   const { paddingBottom: consumerPaddingBottom, ...restStyle } = style ?? {}

package/src/ScrollViewHeader.tsx

@@ -12,12 +12,12 @@ export type ScrollViewHeaderProps = {
   actionSize?: number
   actionStyle?: ViewStyle
   // A plain callback renders the default Appbar.BackAction (themed onSurface, sized/positioned by
-  // actionSize/iconSize below) — the common case, unchanged from before. Passing a ReactNode
+  // actionSize/iconSize below) - the common case, unchanged from before. Passing a ReactNode
   // instead skips that default entirely and renders the given element in its place, same escape
   // hatch trailingAction already gave the other corner: a caller that wants its own color, icon,
   // or component altogether (a colored IconButton, say) isn't stuck fighting Appbar.BackAction's
   // own fixed color/no-customization API to get it. backActionAccessibilityLabel/iconSize below
-  // only apply to the default-rendered case — a custom element carries its own.
+  // only apply to the default-rendered case - a custom element carries its own.
   backAction?: (() => void) | ReactNode
   backActionAccessibilityLabel?: string
   backActionFixed?: boolean
@@ -56,7 +56,7 @@ export const ScrollViewHeader = ({ actionSize = 48, actionStyle, backAction, bac
   const top = topInset ? insets.top : 0
   // Tracks "has this header's own onLayout fired yet" as a SharedValue rather than deriving it from
   // headerHeight (a plain, React-state-backed number) so the worklets below never have to list a
-  // value that flips from null to a real measured number in their dependency arrays — see the
+  // value that flips from null to a real measured number in their dependency arrays - see the
   // comment on translateStyle/blurStyle/progressStyle for why that recreation was a real crash, not
   // just a perf concern.
   const measuredShared = useSharedValue(false)
@@ -70,7 +70,7 @@ export const ScrollViewHeader = ({ actionSize = 48, actionStyle, backAction, bac
   }
   // Web only: measure synchronously before the first paint instead of waiting for onLayout.
   // react-native-web delivers onLayout from a ResizeObserver callback plus a setTimeout measure,
-  // which routinely lands after ScrollViewProvider's two-frame "no header, assume 0" fallback —
+  // which routinely lands after ScrollViewProvider's two-frame "no header, assume 0" fallback -
   // so the first frames painted headerHeight === 0: header absolute with no backdrop, list with no
   // top padding, its first rows (sort/filter chips) drawn up inside the header until the real
   // height arrived. A layout effect runs after the DOM is built but before the browser paints, and
@@ -93,20 +93,20 @@ export const ScrollViewHeader = ({ actionSize = 48, actionStyle, backAction, bac
   const contentMinHeight = actionSize + 2 * actionMargin
   // Same natural height the header renders at in-flow before headerHeight is ever measured (see
   // useScrollList's containerStyle comment for that same "in-flow first, absolute once measured"
-  // pattern) — used as the blur backdrop's own height for that same pre-measurement window, so it
+  // pattern) - used as the blur backdrop's own height for that same pre-measurement window, so it
   // doesn't render as a flat, unblurred box for the ~60-80ms an onLayout round trip takes on web.
   const unmeasuredHeight = top + contentMinHeight
   // Every one of these worklets reads SharedValues only (scrollPosition, snapBackHeaderShared,
-  // headerOffset, pullSearchHeightShared, headerHeightShared, measuredShared) — deliberately NOT the
+  // headerOffset, pullSearchHeightShared, headerHeightShared, measuredShared) - deliberately NOT the
   // plain `headerHeight` context value, even though it holds the same number. `headerHeight` is a
   // React-state-backed `number | null` that changes identity on every measurement (starting at null,
   // then flipping to a real pixel value within a frame of mount); putting it in a useAnimatedStyle
   // dependency array forces Reanimated to tear down and recreate the worklet the moment that happens
-  // — which crashed outright ("[Worklets] Tried to synchronously call a Remote Function") on
+  // - which crashed outright ("[Worklets] Tried to synchronously call a Remote Function") on
   // react-native-worklets 0.10.1. SharedValues never change identity, only their `.value`, so they're
   // safe to depend on and don't retrigger this. They still have to be LISTED here despite that: on
   // web, without the Reanimated Babel plugin's automatic worklet dependency capture, a SharedValue's
-  // mutations aren't picked up as reactive unless its reference appears in this array — omitting one
+  // mutations aren't picked up as reactive unless its reference appears in this array - omitting one
   // silently freezes that value's contribution to the header/blur/progress-bar's scroll tracking at
   // whatever it was when the array last changed.
   const translateStyle = useAnimatedStyle(() => {

package/src/ScrollViewProvider.tsx

@@ -12,7 +12,7 @@ import { ScrollViewSettingsContext } from './ScrollViewSettingsContext'
 export type ScrollViewProviderProps = {
   blur?: boolean
   // Opt out of an enclosing ScrollViewChromeProvider. A screen inside a hosted navigator joins the
-  // host by default; a nested provider that is NOT a screen (a picker or form modal — Paper's Portal
+  // host by default; a nested provider that is NOT a screen (a picker or form modal - Paper's Portal
   // can re-parent those above the clearing this provider does for its own children) has to say so.
   chrome?: boolean
   children: ReactNode
@@ -58,13 +58,13 @@ export const ScrollViewProvider = ({ blur, chrome, children, fixed = false, foot
   const chromeWritable = useSharedValue(!chromeHosted)
   // Only the registrar ever writes this while hosted. If a provider stops being hosted while it stays
   // mounted (chrome flipping to false, the host unmounting), the registrar goes away with it and
-  // would leave the last value behind — possibly false, which would silently switch off this
+  // would leave the last value behind - possibly false, which would silently switch off this
   // provider's own snap-back footer for good.
   useEffect(() => {
     if (!chromeHosted) chromeWritable.value = true
   }, [chromeHosted, chromeWritable])
   const revealChrome = chromeHost?.reveal
-  // Unhosted, the hide distance is simply the footer's own height — the SAME SharedValue, not a
+  // Unhosted, the hide distance is simply the footer's own height - the SAME SharedValue, not a
   // copy, so nothing about existing snap-back behavior changes. Hosted, the whole stack (screen
   // footer + bar + whatever pokes above the bar) has to clear the screen, and the footer's own
   // measured height already includes the overhang as its bottom padding.
@@ -96,7 +96,7 @@ export const ScrollViewProvider = ({ blur, chrome, children, fixed = false, foot
     // react-native-screens' web shim hides an inactive screen via display:none on an
     // ancestor instead of unmounting it, so the header's ResizeObserver-backed onLayout
     // keeps firing while hidden and reports a spurious 0 (no layout box), then again once
-    // revealed. Never let a spurious 0 clobber a real height — only a true remount
+    // revealed. Never let a spurious 0 clobber a real height - only a true remount
     // (headerHeight reset to null) should ever legitimately shrink it back to 0.
     if (h === 0 && headerHeightRef.current) return
     headerHeightRef.current = h
@@ -105,7 +105,7 @@ export const ScrollViewProvider = ({ blur, chrome, children, fixed = false, foot
   // Mirrored into the SharedValue in the same commit as the state, never ahead of it. Writing it
   // straight from onLayout let the header's translate worklet see the new height while the list
   // still had no top padding and scrollPosition hadn't been moved to its resting -headerHeight
-  // (useScrollInit does that in its own layout effect on this commit) — so for the whole re-render
+  // (useScrollInit does that in its own layout effect on this commit) - so for the whole re-render
   // (~50ms on web) the header computed translateY = -headerHeight and slid off-screen, a visible
   // flash of a header-less screen with the list's first rows at the very top.
   useLayoutEffect(() => {
@@ -125,14 +125,14 @@ export const ScrollViewProvider = ({ blur, chrome, children, fixed = false, foot
     if (!__DEV__ || headerHeight !== null) return
     const timeout = setTimeout(() => {
       // eslint-disable-next-line no-console
-      console.warn('[scroll-view] No ScrollViewHeader ever measured inside this ScrollViewProvider — scroll content stays hidden (opacity: 0) until one does. Render a <ScrollViewHeader> (it can be empty / zero height) inside this provider.')
+      console.warn('[scroll-view] No ScrollViewHeader ever measured inside this ScrollViewProvider: scroll content stays hidden (opacity: 0) until one does. Render a <ScrollViewHeader> (it can be empty / zero height) inside this provider.')
     }, 3000)
     return () => clearTimeout(timeout)
   }, [headerHeight])
   // Web-only recovery for a real race: a header's ResizeObserver-backed onLayout can simply never
-  // fire on the very first mount through Expo Router (observed in practice, not just theorized —
+  // fire on the very first mount through Expo Router (observed in practice, not just theorized -
   // content stuck at opacity: 0 indefinitely, with no error, only escaping via an unrelated resize
-  // forcing a fresh layout pass). Native RN doesn't have this race — onLayout is reliable there, and
+  // forcing a fresh layout pass). Native RN doesn't have this race - onLayout is reliable there, and
   // a persistently-null headerHeight really does mean "no header was ever rendered," which the
   // warning above should keep flagging. On web, give a real first layout two frames to arrive before
   // assuming there isn't one; setHeaderHeight(0) is exactly what a genuinely header-less screen would
@@ -154,7 +154,7 @@ export const ScrollViewProvider = ({ blur, chrome, children, fixed = false, foot
       // shim (and a footer's own unmount cleanup below, which now passes null instead of 0 for
       // exactly this reason) can report/force a spurious 0 while a real footer is effectively
       // still on screen (e.g. a wizard cycling through several <ScrollViewFooter> instances).
-      // Never let that clobber a known height — only an explicit null (genuinely no footer
+      // Never let that clobber a known height - only an explicit null (genuinely no footer
       // mounted) may reset it.
       if (h === 0 && footerHeightRef.current) return
       footerHeightRef.current = h

package/src/SectionList.tsx

@@ -36,13 +36,13 @@ const SectionListInner = <ItemT, SectionT extends { data: ReadonlyArray<ItemT> }
 
   const { chipHidden, chipStyle, containerStyle, contentInset, contentOffset, contentPadding, footerFixed, headerFixed, headerHeight } = useScrollList({ footerFixed: footerFixedProp, headerFixed: headerFixedProp, hideUntilMeasured: true, keyboardAware, pullSearchHeight, style })
   const { listGeneration, onListUnmount } = useContext(ScrollViewContext)
-  // -1 never matches a real generation (starts at 0, only increments) — the runOnUI call below
+  // -1 never matches a real generation (starts at 0, only increments) - the runOnUI call below
   // corrects it before any scroll event could observe the placeholder.
   const capturedGeneration = useSharedValue(-1)
   // Layout effect (not passive effect): React guarantees all layout-effect cleanups for fibers
   // removed in a commit run before any layout-effect setups for fibers added in that same commit,
   // but gives no such ordering guarantee for passive effects. On a key-forced remount, the outgoing
-  // instance's unmount and the incoming instance's mount land in the same commit — with passive
+  // instance's unmount and the incoming instance's mount land in the same commit - with passive
   // effects, the incoming instance's sync could run before the outgoing instance's bump, permanently
   // capturing a stale generation and silently disabling this instance's onScroll handling forever.
   // Correct ordering alone isn't sufficient, though: the onScroll worklet reads capturedGeneration
@@ -52,7 +52,7 @@ const SectionListInner = <ItemT, SectionT extends { data: ReadonlyArray<ItemT> }
   // own serial queue, so it's guaranteed to run before any onScroll worklet invocation that could
   // only be queued after this component finishes mounting.
   //
-  // Web has no such thread split, though — see ScrollView.tsx's own doc comment on this same
+  // Web has no such thread split, though - see ScrollView.tsx's own doc comment on this same
   // pattern for why runOnUI's deferred-to-next-frame behavior there leaves a real gap, and why a
   // synchronous assignment is the correct fix rather than a workaround.
   useLayoutEffect(() => {
@@ -71,7 +71,7 @@ const SectionListInner = <ItemT, SectionT extends { data: ReadonlyArray<ItemT> }
   const { activeIndex, clipStyle, measureHeader, overlayStyle, resetPositions } = useStickyHeaders(headerFixed, usesCustomSticky)
 
   // useLayoutEffect (not useEffect) so the reset runs before native layout fires onLayout
-  // for the newly mounted section headers — otherwise the reset would clear correct positions.
+  // for the newly mounted section headers - otherwise the reset would clear correct positions.
   useLayoutEffect(() => {
     if (usesCustomSticky) resetPositions(sections.length)
   }, [sections, usesCustomSticky, resetPositions, headerHeight])

package/src/internal/ChromeRegistrar.tsx

@@ -11,7 +11,7 @@ type ChromeRegistrarProps = {
 
 // Rendered by a hosted ScrollViewProvider as a sibling of its children. It is a component rather
 // than a hook call inside the provider because host.useIsActive is itself a hook, and a provider
-// only sometimes has a host — mounting this only when hosted keeps the hook order stable.
+// only sometimes has a host - mounting this only when hosted keeps the hook order stable.
 //
 // While its screen is active it claims the host; the provider's scroll handlers only write the
 // shared offset (`writable`) while this provider is the claim's owner and nothing has pinned the

package/src/internal/HorizontalDots.tsx

@@ -31,7 +31,7 @@ type DotProps = {
 const Dot = ({ activeColor, index, inactiveColor, pageWidth, scrollPosition }: DotProps) => {
   // Explicit array required on web even though nothing here looks platform-specific: without
   // reanimated's Babel plugin active for the web bundle, useAnimatedStyle has no way to
-  // auto-extract dependencies and throws outright rather than silently under-tracking — omitting
+  // auto-extract dependencies and throws outright rather than silently under-tracking - omitting
   // this array isn't a lesser version of the header/footer bug elsewhere in this package, it's a
   // hard crash (confirmed live on the horizontal-pager demo).
   const circleStyle = useAnimatedStyle(() => {

package/src/internal/ScrollViewChip.tsx

@@ -4,11 +4,11 @@ import { StyleSheet, type ViewStyle } from 'react-native'
 import { Icon, useTheme } from 'react-native-paper'
 import Animated, { type AnimatedStyle } from 'react-native-reanimated'
 
-// 'children' omitted alongside the rest — this chip's own text always comes from `label` (or the
+// 'children' omitted alongside the rest - this chip's own text always comes from `label` (or the
 // isHorizontal-driven 'Start'/'Top' default below), passed as the real JSX children the underlying
 // Chip renders with, which is what actually wins: React always takes the children an element is
 // given between its tags over one merely passed as a "children" prop via spread. A `children` in
-// chipProps would therefore type-check but silently do nothing at runtime — omitting it here means
+// chipProps would therefore type-check but silently do nothing at runtime - omitting it here means
 // TypeScript catches that mismatch instead of a caller finding out the hard way.
 export type ChipProps = Omit<AutoPaperChipProps, 'compact' | 'icon' | 'onPress' | 'children'> & {
   label?: ReactNode
@@ -34,7 +34,7 @@ export const ScrollViewChip = ({ chipProps, isHorizontal, onChipPress, onPress,
   // Rendered via `avatar`, not Chip's own `icon` prop: react-native-paper's MD3 Chip hardcodes
   // `icon`'s color to theme.colors.primary and ignores `selectedColor` entirely (its own doc
   // comment: "With theme version 3 selectedColor doesn't apply to the icon. If you want [a]
-  // custom color for the icon, render your own Icon component") — a chip whose own background
+  // custom color for the icon, render your own Icon component") - a chip whose own background
   // IS theme.colors.primary (this library's callers all set that; see Hangman's own vivid-chip
   // convention) renders that icon invisible against itself. `avatar` has no such override; it
   // clones whatever element/color it's given. Falls back to the same default Paper itself would

package/src/internal/useScrollHandlerJS.ts

@@ -33,17 +33,17 @@ export type ScrollHandlerJS = {
 // Plain JS-thread scroll handler for a non-Animated scrollable. Reanimated shared values are
 // readable/writable from any thread, so driving them via a regular onScroll callback (rather than
 // a useAnimatedScrollHandler worklet, which requires an Animated-wrapped component to attach to at
-// the native level) works fine here — the header/footer animations just pick up the change on
+// the native level) works fine here - the header/footer animations just pick up the change on
 // their next UI-thread frame. This trades a small amount of latency for a plain scrollable that
 // reliably honors the initial `contentOffset` prop on (re)mount, which Animated.FlatList does not.
 export function useScrollHandlerJS({ capturedGeneration, chipHidden, chipThreshold = 100, footerFixed, headerFixed, isHorizontal, jsListGeneration, remountTarget = null, scrollTo }: UseScrollHandlerJSOptions): ScrollHandlerJS {
   const { chromeHosted, chromeWritable, footerOffset, headerHeightShared, headerOffset, pullSearchHeightShared, scrollPosition, snapBackFooterShared, snapBackHeaderShared, stackHeightShared } = useContext(ScrollViewContext)
   const snapUpAccum = useRef(0)
   const fromBottomBounce = useRef(false)
-  // On a remount, the very first native position after mount isn't reliable — Fabric can skip
+  // On a remount, the very first native position after mount isn't reliable - Fabric can skip
   // reapplying `contentOffset` when the target is numerically unchanged from before, and native
   // scroll settling can overshoot or undershoot it. Rather than trust either the declarative prop
-  // or a single imperative scrollTo call, keep correcting (without hiding anything — content stays
+  // or a single imperative scrollTo call, keep correcting (without hiding anything - content stays
   // visible throughout) until an onScroll event actually confirms the intended resting position.
   const pendingRemountTarget = useRef(remountTarget)
   const remountAttempts = useRef(0)
@@ -127,7 +127,7 @@ export function useScrollHandlerJS({ capturedGeneration, chipHidden, chipThresho
 
   // Hosted: scroll tracks 1:1, so it can stop with the stack half hidden; it settles to fully shown
   // or fully hidden instead, since the bar is the app's primary navigation. `revealing` is whether
-  // the 10pt scroll-up latch has already started animating the offset back to 0 — settling on the
+  // the 10pt scroll-up latch has already started animating the offset back to 0 - settling on the
   // in-flight value instead could pick "hidden" and reverse a deliberate reveal.
   const settle = useCallback(
     (revealing: boolean) => {

package/src/internal/useScrollList.ts

@@ -29,7 +29,7 @@ export function useScrollList({ footerFixed: footerFixedProp, headerFixed: heade
 
   const headerFixed = isHorizontal ? true : (headerFixedProp ?? contextHeaderFixed)
   // Hosted, the footer and the bar share ONE offset that the provider's registrar reveals when Footer
-  // Lock turns on — and the registrar only sees the provider-level flag. A per-list override that
+  // Lock turns on - and the registrar only sees the provider-level flag. A per-list override that
   // turned the handlers off on its own would leave the stack stuck wherever it was hidden.
   const footerFixed = isHorizontal ? true : chromeHosted ? contextFooterFixed : (footerFixedProp ?? contextFooterFixed)
 
@@ -37,12 +37,12 @@ export function useScrollList({ footerFixed: footerFixedProp, headerFixed: heade
     pullSearchHeightShared.value = usesContentInset ? (pullSearchHeight ?? 0) : 0
   }, [pullSearchHeight, pullSearchHeightShared])
 
-  // First render (headerHeight===null): flex:1, sitting naturally below the in-flow header —
+  // First render (headerHeight===null): flex:1, sitting naturally below the in-flow header -
   // same visual position content ends up in after the swap below (absoluteFill + paddingTop
   // matching the now-measured headerHeight), so no hiding is needed for this transition on its
   // own. hideUntilMeasured is only for SectionList: its key={headerHeight>0?1:0} forces a real
   // remount of the underlying native list on this exact transition, and that remount is what
-  // needs hiding, not this container swap itself — ScrollView/FlatList/CustomList never remount
+  // needs hiding, not this container swap itself - ScrollView/FlatList/CustomList never remount
   // here, so unconditionally hiding this container regressed a real "flash of blank" on every
   // fresh mount for them (2026-08-03).
   const containerStyle = useMemo(() => (headerHeight === null ? [{ flex: 1, opacity: hideUntilMeasured ? 0 : 1 }, style] : [StyleSheet.absoluteFill, style]), [headerHeight, hideUntilMeasured, style])
@@ -53,7 +53,7 @@ export function useScrollList({ footerFixed: footerFixedProp, headerFixed: heade
   // ScrollViewFooter's own paddingBottom).
   //
   // When footerAboveKeyboard opts the (fixed) footer into floating above the keyboard instead of
-  // sitting behind it, footerHeight ALREADY includes the current keyboardHeight — ScrollViewFooter
+  // sitting behind it, footerHeight ALREADY includes the current keyboardHeight - ScrollViewFooter
   // grows its own container by keyboardHeight to float (see its containerPaddingBottom), rather
   // than translating a fixed-height bar, so onLayout reports the combined height. Adding
   // keyboardHeight again here would double-count it. Otherwise (not floating) ScrollViewFooter pins
@@ -64,7 +64,7 @@ export function useScrollList({ footerFixed: footerFixedProp, headerFixed: heade
   // is actually taller right now.
   //
   // Hosted, tabBarHeight is the bar's footprint and it already contains the safe-area inset, so the
-  // base reserve is only what pokes above the bar (chromeOverhang) — not insets.bottom a second
+  // base reserve is only what pokes above the bar (chromeOverhang) - not insets.bottom a second
   // time. Hosted also reserves the screen footer's own height whether or not it is fixed: unlike an
   // unhosted footer (whose position is a function of scroll, so scrolling to the end always hides
   // it), a hosted stack settles wherever the last gesture left it, so a revealed footer at the end
@@ -82,7 +82,7 @@ export function useScrollList({ footerFixed: footerFixedProp, headerFixed: heade
     return { bottom, top: headerHeight ?? 0 }
   }, [chromeHosted, chromeOverhang, footerAboveKeyboard, footerFixed, footerHeight, insets.bottom, tabBarHeight, headerHeight, keyboardAware, keyboardHeight])
   // Outside inset mode the same geometry is applied as content padding instead; contentInset is
-  // zeroed (not omitted) so consumers' offset math — scroll-to-top targets, minHeight — stays
+  // zeroed (not omitted) so consumers' offset math - scroll-to-top targets, minHeight - stays
   // correct in the raw 0-based coordinate space those platforms actually scroll in.
   const contentInset = usesContentInset ? insetGeometry : ZERO_INSET
   const contentPadding = useMemo(() => (usesContentInset || isHorizontal ? null : { paddingBottom: insetGeometry.bottom, paddingTop: insetGeometry.top }), [insetGeometry, isHorizontal])
@@ -90,19 +90,19 @@ export function useScrollList({ footerFixed: footerFixedProp, headerFixed: heade
   // Use hideY offset only when this component mounted with headerHeight already known (mode switch).
   // On initial load, headerHeight is null at mount so we start at showY and let useScrollInit
   // call scrollTo after the phase transition. On mode switch, headerHeight is already set so we
-  // can position the FlatList at hideY atomically via contentOffset — no scrollTo needed.
+  // can position the FlatList at hideY atomically via contentOffset - no scrollTo needed.
   const [startedWithHeader] = useState(headerHeight !== null)
   const insetContentOffset = useMemo(() => ({ x: 0, y: headerHeight !== null ? -headerHeight + (startedWithHeader && !isHorizontal && pullSearchHeight ? pullSearchHeight : 0) : 0 }), [headerHeight, isHorizontal, pullSearchHeight, startedWithHeader])
   const contentOffset = usesContentInset ? insetContentOffset : ZERO_OFFSET
 
   const chipHidden = useSharedValue(1)
   // chipHidden/snapBackHeaderShared/headerOffset/scrollPosition/pullSearchHeightShared/
-  // headerHeightShared all need to be listed here too, not just read — see ScrollViewHeader's
+  // headerHeightShared all need to be listed here too, not just read - see ScrollViewHeader's
   // translateStyle for why (web-only reanimated reactivity gap: a SharedValue's mutations don't
   // retrigger useAnimatedStyle unless the value itself is in this array). headerHeightShared is
   // used here rather than the plain `headerHeight` context value specifically because the latter
   // changes identity (null -> a real number) shortly after mount, which forces Reanimated to
-  // recreate this worklet — a crash on react-native-worklets 0.10.1, not just a perf concern. See
+  // recreate this worklet - a crash on react-native-worklets 0.10.1, not just a perf concern. See
   // ScrollViewHeader's translateStyle/blurStyle/progressStyle for the full explanation.
   const chipStyle = useAnimatedStyle(() => {
     const pointerEvents = chipHidden.value ? ('none' as const) : ('box-none' as const)

package/src/internal/useStickyHeaders.ts

@@ -26,7 +26,7 @@ export function useStickyHeaders(headerFixed: boolean, enabled: boolean): Sticky
     contentIndexShared.value = activeIndex
   }, [activeIndex, contentIndexShared])
 
-  // JS-side source of truth — sectionYPositions is a snapshot pushed to the worklet.
+  // JS-side source of truth - sectionYPositions is a snapshot pushed to the worklet.
   // Reading sectionYPositions.value from JS returns the UI-thread's stale copy, so
   // rapid async measure callbacks would overwrite each other; refs avoid that.
   const positionsCache = useRef<number[]>([])
@@ -65,7 +65,7 @@ export function useStickyHeaders(headerFixed: boolean, enabled: boolean): Sticky
     // Same web-only reanimated gap as useAnimatedStyle elsewhere in this file: this "prepare"
     // function's own SharedValue reads (sectionYPositions, headerHeightShared, scrollPosition,
     // snapBackHeaderShared, headerOffset, pullSearchHeightShared) need to be listed explicitly too
-    // — confirmed empirically that without them, useAnimatedReaction re-evaluates once on mount and
+    // - confirmed empirically that without them, useAnimatedReaction re-evaluates once on mount and
     // then never again on web, permanently freezing activeIndex/the active sticky section.
     [enabled, headerFixed, insetsTop, sectionYPositions, headerHeightShared, scrollPosition, snapBackHeaderShared, headerOffset, pullSearchHeightShared]
   )
@@ -74,7 +74,7 @@ export function useStickyHeaders(headerFixed: boolean, enabled: boolean): Sticky
   // header as it slides above the sticky line during a push transition.
   // Every SharedValue read below (headerHeightShared, scrollPosition, snapBackHeaderShared,
   // headerOffset, pullSearchHeightShared, and for overlayStyle also contentIndexShared/
-  // sectionYPositions/sectionHeights) has to be listed in the array too — see
+  // sectionYPositions/sectionHeights) has to be listed in the array too - see
   // ScrollViewHeader's translateStyle for why: on web, reanimated doesn't treat mutations to a
   // SharedValue as a reactive trigger for useAnimatedStyle unless it's in this array.
   const clipStyle = useAnimatedStyle(() => {

package/src/redux/scrollViewSlice.ts

@@ -2,7 +2,7 @@ import { createSettingsSlice } from '@rific/core'
 
 import { defaultScrollViewSettings, type ScrollViewSettings } from '../ScrollViewSettingsContext'
 
-// scrollView has no per-field setters, just a full-replace initialize — matches the previous
+// scrollView has no per-field setters, just a full-replace initialize - matches the previous
 // hand-rolled slice exactly (action type 'scrollView/initialize', full-state-replace behavior).
 const scrollViewSlice = createSettingsSlice<ScrollViewSettings>('scrollView', {
   initialState: defaultScrollViewSettings,

package/src/useKeyboardInset.ts

@@ -23,6 +23,6 @@ const useKeyboardInsetNative = () => {
 
 const useKeyboardInsetWeb = () => 0
 
-// react-native-keyboard-controller has no web implementation — its handler hook must never be
+// react-native-keyboard-controller has no web implementation - its handler hook must never be
 // called there. Platform is constant for the life of the bundle, so this select is hook-safe.
 export const useKeyboardInset = Platform.OS === 'web' ? useKeyboardInsetWeb : useKeyboardInsetNative

package/src/useScrollInit.ts

@@ -12,7 +12,7 @@ const REMOUNT_PRIME_FRAMES = 40
 const SNAP_VERIFY_TOLERANCE = 1
 const SNAP_VERIFY_MAX_ATTEMPTS = 5
 // Long enough to comfortably outlast RN's default animated scrollTo duration (iOS's native
-// setContentOffset:animated: for a typical pull-search distance settles well within this) — see
+// setContentOffset:animated: for a typical pull-search distance settles well within this) - see
 // the comment on scheduleSnapVerification for why a native onMomentumScrollEnd event can't be used
 // as this signal instead.
 const SNAP_VERIFY_INITIAL_DELAY_MS = 400
@@ -51,7 +51,7 @@ export function useScrollInit({ listHeaderComponent, onMomentumScrollEnd: extern
   // switch). Only enter 'measuring' on the very first mount when headerHeight hasn't been set yet.
   const [phase, setPhase] = useState<'measuring' | 'ready'>(hasPullSearch && !headerHeight ? 'measuring' : 'ready')
   const [refreshing, setRefreshing] = useState(false)
-  // A plain-ref mirror of `refreshing`, read from inside the deferred timeout below — that
+  // A plain-ref mirror of `refreshing`, read from inside the deferred timeout below - that
   // callback can fire well after the render that scheduled it, so it needs the *current* value,
   // not whatever `refreshing` closed over at schedule time.
   const refreshingRef = useRef(refreshing)
@@ -60,7 +60,7 @@ export function useScrollInit({ listHeaderComponent, onMomentumScrollEnd: extern
   }, [refreshing])
   const dragStartY = useRef<number | null>(null)
   // Which pull-search resting position (showY or hideY) a drag-release most recently committed
-  // to, so a late fallback in handleMomentumScrollEnd knows not to fight it — see
+  // to, so a late fallback in handleMomentumScrollEnd knows not to fight it - see
   // scheduleSnapVerification below for how this actually gets enforced.
   const pendingSnapTarget = useRef<number | null>(null)
   const snapVerifyTimeout = useRef<ReturnType<typeof setTimeout> | null>(null)
@@ -69,9 +69,9 @@ export function useScrollInit({ listHeaderComponent, onMomentumScrollEnd: extern
   // Verifies a pull-search drag-release (handleScrollEndDrag) actually landed on `target`, and
   // keeps correcting (non-animated, so it lands immediately) until it does. This is deliberately
   // time-based rather than triggered by onMomentumScrollEnd: a slow/controlled release with near-
-  // zero velocity fires onMomentumScrollEnd within a couple of milliseconds of the drag ending —
+  // zero velocity fires onMomentumScrollEnd within a couple of milliseconds of the drag ending -
   // long before the *animated* scrollTo call issued moments earlier has had any chance to actually
-  // move — so reacting to that event by immediately snapping (non-animated) to the target replaced
+  // move - so reacting to that event by immediately snapping (non-animated) to the target replaced
   // the intended smooth spring-back animation with a jarring instant jump on every normal pull,
   // not just the pathological case this was built for. Waiting out a fixed delay long enough for a
   // normal animated scrollTo to have finished, then checking the *actual* position via
@@ -111,7 +111,7 @@ export function useScrollInit({ listHeaderComponent, onMomentumScrollEnd: extern
     []
   )
 
-  // Remount sync: this instance mounted with headerHeight already known — a key-forced remount
+  // Remount sync: this instance mounted with headerHeight already known - a key-forced remount
   // (e.g. numColumns toggling between a list and a grid), not a true first mount. The native
   // scroll view's actual position right after such a remount isn't reliable (Fabric's ScrollView
   // recycling and Reanimated's Animated.FlatList can both leave it at a stale or zeroed offset
@@ -159,7 +159,7 @@ export function useScrollInit({ listHeaderComponent, onMomentumScrollEnd: extern
     }, REMOUNT_SYNC_FALLBACK_MS)
     return () => clearTimeout(fallback)
     // Intentionally runs once per mount only, using whatever remountTarget was captured at
-    // construction — not a dep that should retrigger this effect.
+    // construction - not a dep that should retrigger this effect.
     // eslint-disable-next-line react-hooks/exhaustive-deps
   }, [])
 
@@ -170,10 +170,10 @@ export function useScrollInit({ listHeaderComponent, onMomentumScrollEnd: extern
     setPhase('ready')
   }, [phase, headerHeight, pullSearchHeight, scrollPosition])
 
-  // Effect A applies ONLY on an actual remount (remountTarget !== null — this instance mounted with
+  // Effect A applies ONLY on an actual remount (remountTarget !== null - this instance mounted with
   // headerHeight already known, e.g. a key-forced remount elsewhere in the tree). It syncs
   // scrollPosition synchronously before first paint and issues a short bounded chain of imperative
-  // scrollTo calls, alternating between two offsets far enough apart (30pt — comfortably more than
+  // scrollTo calls, alternating between two offsets far enough apart (30pt - comfortably more than
   // any plausible rounding/measurement noise) to guarantee at least one call can't be mistaken for a
   // no-op. The declarative `contentOffset` prop alone isn't enough on a remount: when the target is
   // numerically identical to what it was before (headerHeight/pullSearchHeight don't change across a
@@ -181,7 +181,7 @@ export function useScrollInit({ listHeaderComponent, onMomentumScrollEnd: extern
   // be left at whatever position it actually drifted to. Worse, iOS's imperative scrollToOffset
   // short-circuits with a CGPointEqualToPoint check against the native view's *actual* current
   // contentOffset before it will fire the native scroll-finished callback that RN turns into an
-  // onScroll event — so a single differing call can still go unnoticed if it happens to race content
+  // onScroll event - so a single differing call can still go unnoticed if it happens to race content
   // that's still growing. Alternating across the *entire* correction window, not just the first
   // couple of frames, forces a real scroll-finished callback so drift becomes observable and the
   // onScroll-driven retry loop in useScrollHandlerJS can correct it.
@@ -189,7 +189,7 @@ export function useScrollInit({ listHeaderComponent, onMomentumScrollEnd: extern
   // On a true first mount (remountTarget === null) this effect does nothing beyond a single
   // insurance call against the destination view silently ignoring the very first scroll command
   // because it isn't fully installed in the window hierarchy yet (e.g. mid native-stack push
-  // transition) — a fresh, non-recycled native view reliably honors the declarative contentOffset
+  // transition) - a fresh, non-recycled native view reliably honors the declarative contentOffset
   // prop otherwise. Repeating or oscillating that call here fights Effect B below, whose entire job
   // on a true first mount with pull-search is to push the position on from here to hideY: if this
   // effect keeps re-asserting its own target for tens of frames, it can win the race and leave the
@@ -277,7 +277,7 @@ export function useScrollInit({ listHeaderComponent, onMomentumScrollEnd: extern
       if (pullSearchHeight && headerHeight && !refreshing && pendingSnapTarget.current === null) {
         // No drag committed to a target above (e.g. a fast fling whose whole reveal/overscroll
         // motion happened during momentum, never during the drag itself, so handleScrollEndDrag
-        // never saw a y near the pull-search zone) — fall back to auto-closing if we've ended up
+        // never saw a y near the pull-search zone) - fall back to auto-closing if we've ended up
         // revealed without ever meaning to.
         const y = e.nativeEvent.contentOffset.y
         const hideY = -headerHeight + pullSearchHeight