no-use-before-define

[thomasttvo]

Reanimated has a hard requirement that a worklet must be defined before the worklet that calls it is. Otherwise, the app will crash. At the same time there's no linter that would apply the rule only for worklets, so we have to turn it on for everything. Quite inconvenient, but gets us one step toward reanimated for now, and can be revisited for future improvements.

There's no logic change in this PR. Only functions getting moved around.

---

Note

Refactors and reorders code to comply with no-use-before-define, extracting shared logic into hooks/helpers and adjusting call sites without changing behavior.

• Introduces useZoomSubject (measurement) and useDebugPoints (pinch debug) hooks, and moves zoom step calc to helper/getNextZoomStep
• Updates ReactNativeZoomableView to use new hooks, replaces inline helpers, and reorders pan/gesture handlers and setup
• Minor formatting and eslint-disable annotations in AnimatedTouchFeedback, StaticPin, and debug helpers; map files added

^{Written by Cursor Bugbot for commit 16483a8. Configure here.}

[thomasttvo]

bugbot run

[cursor]

✅ Bugbot reviewed your changes and found no bugs!

---

Comment @cursor review or bugbot run to trigger another review on this PR

[thomasttvo]

@claude please review this PR

[thomasttvo]

@claude review

[claude]

🟣 Five PanResponder callbacks in the empty-deps useLayoutEffect close directly over the render-scope props variable, permanently capturing initial-mount values and ignoring all later prop updates. This is a pre-existing issue carried forward unchanged by the refactor: onPanResponderTerminate, onPanResponderTerminationRequest, onShouldBlockNativeResponder, onStartShouldSetPanResponderCapture, and onMoveShouldSetPanResponderCapture should be wrapped with useLatestCallback the same way the other four handlers are.

Extended reasoning...

Root cause

In src/ReactNativeZoomableView.tsx, PanResponder.create is called inside a useLayoutEffect(() => { ... }, []) — a one-time mount effect. The five inline arrow functions passed to the PanResponder each directly reference the function-component's props variable:

onPanResponderTerminate: (evt, gestureState) => {
  _handlePanResponderEnd(evt, gestureState);
  props.onPanResponderTerminate?.(evt, gestureState, _getZoomableViewEventObject());
},
onPanResponderTerminationRequest: (evt, gestureState) =>
  !!props.onPanResponderTerminationRequest?.(evt, gestureState, _getZoomableViewEventObject()),
onShouldBlockNativeResponder: (evt, gestureState) =>
  props.onShouldBlockNativeResponder?.(evt, gestureState, _getZoomableViewEventObject()) ?? true,
onStartShouldSetPanResponderCapture: (evt, gestureState) =>
  !!props.onStartShouldSetPanResponderCapture?.(evt, gestureState),
onMoveShouldSetPanResponderCapture: (evt, gestureState) =>
  !!props.onMoveShouldSetPanResponderCapture?.(evt, gestureState),

Because the useLayoutEffect runs only once (empty deps), JavaScript's closure captures the props object from the very first render. On every subsequent render, React creates a new props object — but the callbacks still call the initial prop functions.

Why the fix pattern exists but was not applied here

The other four main handlers — _handlePanResponderEnd, _handlePanResponderMove, _handlePanResponderGrant, _handleStartShouldSetPanResponder — are all wrapped with useLatestCallback. That hook stores the latest function in a useRef (updated each render) and returns a stable wrapper that always calls ref.current. This correctly breaks the stale-closure problem.

The five inline callbacks above were never given the same treatment, making them permanently stale after the first render.

Concrete proof

Suppose a parent component conditionally toggles onShouldBlockNativeResponder based on a piece of state:

const [blocking, setBlocking] = useState(true);
<ReactNativeZoomableView
  onShouldBlockNativeResponder={() => blocking}
/>
// Later: setBlocking(false)

After setBlocking(false), the view re-renders with a new props.onShouldBlockNativeResponder that returns false. However, the PanResponder was created once at mount with the closure capturing the original props, which returned true. Every subsequent native gesture event will still call the stale function and return true, so native scroll containers will always be blocked regardless of what the parent passes.

Pre-existing nature

The same stale-closure pattern existed in the old code before this PR. The diff shows the removed lines had identical direct props.onPanResponderTerminate?., props.onShouldBlockNativeResponder?., etc. references inside the same one-time useLayoutEffect. This PR is a pure code reorganization (no-use-before-define compliance) and does not change this behavior in either direction.

Fix

Wrap each of the five callbacks with useLatestCallback before passing them to PanResponder.create, identical to how the four main handlers are handled.

[claude]

🟣 lodash is imported at runtime in ReactNativeZoomableView.tsx but is listed only in peerDependencies, which are not automatically installed by package managers for library consumers. Any consumer project that does not explicitly add lodash to their own dependencies will get a hard crash (Cannot find module 'lodash') at runtime. Move lodash to the dependencies field so it is always installed automatically. Note: this is a pre-existing issue (lodash was previously in devDependencies, also not auto-installed), but this PR makes it more visible by moving it to peerDependencies.

Extended reasoning...

What the bug is and how it manifests

lodash is a hard runtime dependency of this library — ReactNativeZoomableView.tsx imports debounce and defaults from lodash at the top of the file. These are called during normal component lifecycle (defaults is applied on every render to merge prop defaults; debounce wraps a pinch handler). Despite being a runtime requirement, lodash appears only in peerDependencies (and previously was in devDependencies), never in dependencies. Package managers (npm, yarn classic v1) do NOT auto-install peerDependencies for library consumers, so any consumer who has not independently installed lodash will encounter a hard crash.

The specific code path that triggers it

In src/ReactNativeZoomableView.tsx:

• Line 1: import { debounce, defaults } from 'lodash';
• defaults is called when building the component's resolved props on every render cycle.
• debounce is used to wrap debouncedOnStaticPinPositionChange which is invoked during pinch gesture handling.

Both usages are in the hot path of the component. There is no dynamic require, no try/catch fallback, and no optional chaining around the lodash calls.

Why existing code does not prevent it

peerDependencies communicates to consuming projects: 'you must install this yourself'. The library's own package.json has no entry in the dependencies field for lodash, so npm/yarn will never automatically install lodash for a consumer. If a consumer does npm install react-native-zoomable-view into a fresh project with no lodash, they will get no error during install — the crash only appears at runtime when the component is first mounted.

Impact

Any consumer project that does not already have lodash installed will encounter:

Error: Cannot find module 'lodash'

...the moment ReactNativeZoomableView is first rendered. This is a hard crash with no graceful degradation. Consumer projects built around this library (especially RN apps bootstrapped from a clean template) have no lodash by default, so this affects a realistic portion of users.

How to fix it

The simplest fix: move lodash from peerDependencies to dependencies in package.json:

"dependencies": {
  "lodash": "^4.17.21"
}

Remove it from peerDependencies entirely (or keep it there if you want to allow version deduplication). An alternative fix is to inline the two usages (debounce is available in react-native's bundled scheduler utilities; defaults can be replaced with Object.assign or spread syntax) and remove lodash as a dependency altogether.

Step-by-step proof

1. Consumer runs: npm install react-native-zoomable-view
2. npm resolves dependencies[] for the library (empty, lodash is not there). peerDependencies are noted but not installed.
3. Consumer project has no lodash in their own package.json.
4. Consumer renders <ReactNativeZoomableView> in their app.
5. Metro bundler (or Node.js) attempts to resolve the import from 'lodash'.
6. Module resolution fails — lodash is not on disk anywhere in node_modules.
7. Hard crash: Error: Cannot find module 'lodash'.

Pre-existing note

Before this PR, lodash was in devDependencies (also not auto-installed for consumers). This PR moves it to peerDependencies, which is marginally better (it at least communicates the requirement), but still does not automatically install lodash. The root fix — placing lodash in dependencies — has never been applied. This issue is pre-existing but worth flagging because the PR touches package.json and is an opportunity to resolve it properly.