Uh oh!
There was an error while loading. Please reload this page.
[react devtools] Pass a CachedSettingsStore to connectToDevTools - #34903
Closed
rbalicki2 wants to merge 1 commit into
Closed
[react devtools] Pass a CachedSettingsStore to connectToDevTools#34903rbalicki2 wants to merge 1 commit into
connectToDevTools#34903rbalicki2 wants to merge 1 commit into
Conversation
rbalicki2force-pushed
the
pass-settings-store
branch
from
October 9, 2022 00:10
2902b69 to
85193eaComparefacebook-github-bot
commented
Oct 9, 2022
Contributor
@rbalicki2 has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
rbalicki2force-pushed
the
pass-settings-store
branch
from
October 9, 2022 00:15
85193ea to
cb6bb11Comparefacebook-github-bot
commented
Oct 9, 2022
Contributor
@rbalicki2 has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
analysis-bot
commented
Oct 9, 2022
Base commit: 24efebf |
Base commit: 1fc27c4 |
rbalicki2force-pushed
the
pass-settings-store
branch
2 times, most recently
from
October 10, 2022 21:43
f855cdf to
cb6bb11Comparerbalicki2 added a commit
to react/react
that referenced
this pull request
Oct 25, 2022
# Summary * This PR adds support for persisting certain settings to device storage, allowing e.g. RN apps to properly patch the console when restarted. * The device storage APIs have signature `getConsolePatchSettings()` and `setConsolePatchSettings(string)`, in iOS, are thin wrappers around the `Library/Settings` turbomodule, and wrap a new TM that uses the `SharedPreferences` class in Android. * Pass device storage getters/setters from RN to DevTools' `connectToDevtools`. The setters are then used to populate values on `window`. Later, the console is patched using these values. * If we receive a notification from DevTools that the console patching fields have been updated, we write values back to local storage. * See react/react-native#34903 # How did you test this change? Manual testing, `yarn run test-build-devtools`, `yarn run prettier`, `yarn run flow dom` ## Manual testing setup: ### React DevTools Frontend * Get the DevTools frontend in flipper: * `nvm install -g react-devtools-core`, then replace that package with a symlink to the local package * enable "use globally installed devtools" in flipper * yarn run start in react-devtools, etc. as well ### React DevTools Backend * `yarn run build:backend` in react-devtools-core, then copy-paste that file to the expo app's node_modules directory ### React Native * A local version of React Native can be patched in by modifying an expo app's package.json, as in `"react-native": "rbalicki2/react-native#branch-name"` # Versioning safety * There are three versioned modules to worry about: react native, the devtools frontend and the devtools backend. * The react devtools backend checks for whether a `cachedSettingsStore` is passed from react native. If not (e.g. if React Native is outdated), then no behavior changes. * The devtools backend reads the patched console values from the cached settings store. However, if nothing has been stored, for example because the frontend is outdated or has never synced its settings, then behavior doesn't change. * The devtools frontend sends no new messages. However, if it did send a new message (e.g. "store this value at this key"), and the backend was outdated, that message would be silently ignored.
rickhanlonii pushed a commit
to react/react
that referenced
this pull request
Dec 3, 2022
# Summary * This PR adds support for persisting certain settings to device storage, allowing e.g. RN apps to properly patch the console when restarted. * The device storage APIs have signature `getConsolePatchSettings()` and `setConsolePatchSettings(string)`, in iOS, are thin wrappers around the `Library/Settings` turbomodule, and wrap a new TM that uses the `SharedPreferences` class in Android. * Pass device storage getters/setters from RN to DevTools' `connectToDevtools`. The setters are then used to populate values on `window`. Later, the console is patched using these values. * If we receive a notification from DevTools that the console patching fields have been updated, we write values back to local storage. * See react/react-native#34903 # How did you test this change? Manual testing, `yarn run test-build-devtools`, `yarn run prettier`, `yarn run flow dom` ## Manual testing setup: ### React DevTools Frontend * Get the DevTools frontend in flipper: * `nvm install -g react-devtools-core`, then replace that package with a symlink to the local package * enable "use globally installed devtools" in flipper * yarn run start in react-devtools, etc. as well ### React DevTools Backend * `yarn run build:backend` in react-devtools-core, then copy-paste that file to the expo app's node_modules directory ### React Native * A local version of React Native can be patched in by modifying an expo app's package.json, as in `"react-native": "rbalicki2/react-native#branch-name"` # Versioning safety * There are three versioned modules to worry about: react native, the devtools frontend and the devtools backend. * The react devtools backend checks for whether a `cachedSettingsStore` is passed from react native. If not (e.g. if React Native is outdated), then no behavior changes. * The devtools backend reads the patched console values from the cached settings store. However, if nothing has been stored, for example because the frontend is outdated or has never synced its settings, then behavior doesn't change. * The devtools frontend sends no new messages. However, if it did send a new message (e.g. "store this value at this key"), and the backend was outdated, that message would be silently ignored.
jerrydev0927 added a commit
to jerrydev0927/react
that referenced
this pull request
Jan 5, 2024
# Summary * This PR adds support for persisting certain settings to device storage, allowing e.g. RN apps to properly patch the console when restarted. * The device storage APIs have signature `getConsolePatchSettings()` and `setConsolePatchSettings(string)`, in iOS, are thin wrappers around the `Library/Settings` turbomodule, and wrap a new TM that uses the `SharedPreferences` class in Android. * Pass device storage getters/setters from RN to DevTools' `connectToDevtools`. The setters are then used to populate values on `window`. Later, the console is patched using these values. * If we receive a notification from DevTools that the console patching fields have been updated, we write values back to local storage. * See react/react-native#34903 # How did you test this change? Manual testing, `yarn run test-build-devtools`, `yarn run prettier`, `yarn run flow dom` ## Manual testing setup: ### React DevTools Frontend * Get the DevTools frontend in flipper: * `nvm install -g react-devtools-core`, then replace that package with a symlink to the local package * enable "use globally installed devtools" in flipper * yarn run start in react-devtools, etc. as well ### React DevTools Backend * `yarn run build:backend` in react-devtools-core, then copy-paste that file to the expo app's node_modules directory ### React Native * A local version of React Native can be patched in by modifying an expo app's package.json, as in `"react-native": "rbalicki2/react-native#branch-name"` # Versioning safety * There are three versioned modules to worry about: react native, the devtools frontend and the devtools backend. * The react devtools backend checks for whether a `cachedSettingsStore` is passed from react native. If not (e.g. if React Native is outdated), then no behavior changes. * The devtools backend reads the patched console values from the cached settings store. However, if nothing has been stored, for example because the frontend is outdated or has never synced its settings, then behavior doesn't change. * The devtools frontend sends no new messages. However, if it did send a new message (e.g. "store this value at this key"), and the backend was outdated, that message would be silently ignored.
mrizwanashiq pushed a commit
to mrizwanashiq/react
that referenced
this pull request
Jun 25, 2026
# Summary * This PR adds support for persisting certain settings to device storage, allowing e.g. RN apps to properly patch the console when restarted. * The device storage APIs have signature `getConsolePatchSettings()` and `setConsolePatchSettings(string)`, in iOS, are thin wrappers around the `Library/Settings` turbomodule, and wrap a new TM that uses the `SharedPreferences` class in Android. * Pass device storage getters/setters from RN to DevTools' `connectToDevtools`. The setters are then used to populate values on `window`. Later, the console is patched using these values. * If we receive a notification from DevTools that the console patching fields have been updated, we write values back to local storage. * See react/react-native#34903 # How did you test this change? Manual testing, `yarn run test-build-devtools`, `yarn run prettier`, `yarn run flow dom` ## Manual testing setup: ### React DevTools Frontend * Get the DevTools frontend in flipper: * `nvm install -g react-devtools-core`, then replace that package with a symlink to the local package * enable "use globally installed devtools" in flipper * yarn run start in react-devtools, etc. as well ### React DevTools Backend * `yarn run build:backend` in react-devtools-core, then copy-paste that file to the expo app's node_modules directory ### React Native * A local version of React Native can be patched in by modifying an expo app's package.json, as in `"react-native": "rbalicki2/react-native#branch-name"` # Versioning safety * There are three versioned modules to worry about: react native, the devtools frontend and the devtools backend. * The react devtools backend checks for whether a `cachedSettingsStore` is passed from react native. If not (e.g. if React Native is outdated), then no behavior changes. * The devtools backend reads the patched console values from the cached settings store. However, if nothing has been stored, for example because the frontend is outdated or has never synced its settings, then behavior doesn't change. * The devtools frontend sends no new messages. However, if it did send a new message (e.g. "store this value at this key"), and the backend was outdated, that message would be silently ignored.
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 freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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
Libraries/Settings/Settings) that namespaces all gets/setsconnectToDevTools.Test plan
See react/react#25452
Changelog
[General] [Added] Pass
cachedSettingsStoretoconnectToDevToolsto support persisted settings.Android
Settings/Settingsmodule is not implemented for Android. However, all calls tocachedSettingsStoreare wrapped in try/catch blocks, so we're good — this will be implemented as a follow up.