[ciospettw]

Description

Fixes #4192

Added cameraChangedThrottleInterval to MapView so apps can opt into native throttling for onCameraChanged during gesture-heavy interactions.

The default remains 0, so existing behavior is unchanged unless the new prop is explicitly set.

This PR also updates the Map Handlers example and synchronizes the related docs so the new prop is discoverable and easy to validate.

Checklist

• I've read CONTRIBUTING.md
• I updated the doc/other generated code with running yarn generate in the root folder
• I have tested the new feature on /example app.
  • In V11 mode/ios
  • In New Architecture mode/ios
  • In V11 mode/android
  • In New Architecture mode/android
• I added/updated a sample - if a new feature was implemented (/example)

Screenshot OR Video

Not included.

Component to reproduce the issue you're fixing

<MapView
  cameraChangedThrottleInterval={250}
  onCameraChanged={(state) => {
    // Throttled intermediate camera updates.
  }}
  onMapIdle={(state) => {
    // Final settled camera state.
  }}
/>

Notes

• cameraChangedThrottleInterval is fully opt-in and defaults to 0, so omitting it preserves the current event behavior.
• I manually synchronized docs/MapView.md and docs/examples.json in this checkout.
• I left the yarn generate checklist item unchecked because node .yarn/releases/yarn-3.6.1.cjs generate currently fails locally in this environment with TypeError: Yallist is not a constructor from hosted-git-info on Node 22.
• Targeted validation completed: jest __tests__/components/MapView.test.js passes.

[krisgerhard]

We incorporated this as a patch and find it very useful. Thank you!

[mfazekas]

Thanks a lot for this, @ciospettw, and sorry for the long wait.

We dug into the pinch-zoom lag and found the main cause elsewhere: on Android every MarkerView reported its position to JS and re-rendered on every frame. #4359 removes that round-trip. In our measurements, janky frames while panning went from about 94% to about 50% with 500 markers, and from about 57% to about 12% with 200.

So I'm closing this for now rather than adding a throttle on top. Once #4359 lands, could you re-measure your case on it? If camera-change events are still a measurable bottleneck, we'll happily reconsider a native throttle. I'll keep #4192 open for that.