feat: JS-only implementation on top of core safe area primitives - #752
Draft
janicduplessis wants to merge 3 commits into
Draft
feat: JS-only implementation on top of core safe area primitives#752janicduplessis wants to merge 3 commits into
janicduplessis wants to merge 3 commits into
Conversation
When core reports safe area insets through the onSafeAreaInsetsChange view prop (react/react-native#57967), the library needs no native code: - SafeAreaProvider renders a plain View with the prop; the payload is identical to onInsetsChange. - SafeAreaView promotes the existing web implementation to every platform: insets come from the provider context and are applied per-edge as padding or margin, preserving the native shadow node semantics (off/additive/maximum). Core's synchronous event dispatch keeps both same-frame. Gated on the RN version so older versions keep the native path. The jest environment reports RN 1000.0.0, so the test suite exercises the new path.
Core reports window safe area insets through Dimensions (same native code as the onSafeAreaInsetsChange view prop), which removes the need for the RNCSafeAreaContext native module.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Prototype of what the library looks like on top of the core safe area primitives proposed in react/react-native#57967 — opened for discussion, not for landing: it gates on a placeholder version (RN ≥ 0.88) and can only run against a React Native checkout that includes that PR.
With core reporting insets itself, the library needs no native code:
SafeAreaProviderrenders a plainViewwith the coreonSafeAreaInsetsChangeprop. The payload is identical to ouronInsetsChange, so nothing else changes. Also coversSafeAreaListener.SafeAreaViewpromotes the existing web implementation to every platform: insets come from the provider context and are applied per-edge as padding or margin in JS, with the sameedges/modesemantics as before.initialWindowMetricsreadsDimensions.get('window').safeAreaInsets, which the core PR exposes using the same native inset computation as the view prop, so theRNCSafeAreaContextmodule is not needed either.The part that makes the JS implementations viable is that core dispatches the inset event synchronously: the padding derived from the insets is mounted in the frame the insets changed in, so the JS
SafeAreaViewkeeps the no-flicker behavior that previously required the native shadow node.On React Native versions before the core prop exists, everything falls back to the current native path —
SUPPORTS_CORE_SAFE_AREA_INSETSinsrc/coreSafeAreaInsets.tsis the single gate.Test Plan
yarn validate:jest— 22 tests pass. The jest environment reports RN 1000.0.0, so the suite exercises the new JS path (snapshots updated accordingly); the legacy native path is covered by mocking the gate.yarn validate:typescriptpasses.