Expose owned module settings to client
See original GitHub issueFeature Description
With the behavioral changes coming to settings edit interfaces in #4825, it will be necessary to identify which settings are owned and particularly when they have changed.
Do not alter or remove anything below. The following sections will be managed by moderators only.
Acceptance criteria
- The
haveSettingsChanged
selector increateSettingsStore
should be updated to accept an optionalkeys
parameter (string[]
)- If passed, the selector should return its result based on a subset of settings identified by the given list of keys
- If not passed, it should continue to work as today (comparing the full object of settings)
createModuleStore
should be updated to accept an optionalownedSettingsSlugs
argument (string[]
) which should default to an empty array- A new
haveOwnedSettingsChanged
selector should be generated in the resulting store definition which useshaveSettingsChanged
internally; returningtrue
if any owned setting has changed, otherwisefalse
- If the module has no owned settings, this should always return
false
- If the module has no owned settings, this should always return
- Module store definitions on the client should be updated to register their owned settings (see
Setting_With_Owned_Keys_Interface
)
Implementation Brief
In assets/js/googlesitekit/data/create-settings-store.js
:
- Add
keys
parameter to thehaveSettingsChanged
selector as per the AC.
In assets/js/googlesitekit/modules/create-module-store.js
:
- Add optional
ownedSettingsSlugs
argument tocreateModuleStore
and create thehaveOwnedSettingsChanged
selector in the resulting store definition as per the AC.- In the implementation of
haveOwnedSettingsChanged
:- If
ownedSettingsSlugs
was passed tocreateModuleStore
callhaveSettingsChanged( ownedSettingsSlugs )
to check if the owned settings have changed. - Otherwise, return
false
.
- If
- In the implementation of
For each PHP Module that implements Setting_With_Owned_Keys_Interface
, review the list of keys in the module’s implementation of get_owned_keys
and update the corresponding JS-side call to Modules.createModuleStore
, passing the list of owned keys in as ownedSettingsSlugs
.
- AdSense:
- Analytics:
- Analytics GA4:
- Optimize:
- Search Console:
- Subscribe With Google:
- Tag Manager:
Test Coverage
- Add tests for the new
haveSettingsChanged
selector, and update tests forcreateModuleStore
to reflect the new behaviour. - Fix any failing tests.
QA Brief
- Setup each module in Site Kit and modify settings; they should continue to work as-normal. No changes should be noticed as part of this change to the behaviour of saving settings, disconnecting/reconnecting modules and their settings, etc.
Changelog entry
- Expose owned module settings to client.
Issue Analytics
- State:
- Created a year ago
- Comments:6
Top Results From Across the Web
Expose and reuse functionality between modules
Learn how to make elements of your module available for reuse by other modules and how to to use elements exposed by other...
Read more >Common modularization patterns - Android Developers
This page gives an overview of some general rules and common patterns that you can employ when developing multi module Android apps.
Read more >Understanding Java 9 Modules - Oracle
In this article, I introduce the Java 9 Platform Module System (JPMS), the most important new software engineering technology in Java since its...
Read more >Documentation - Modules - TypeScript
Modules are executed within their own scope, not in the global scope; this means that variables, functions, classes, etc. declared in a module...
Read more >What's the difference between exposing environment ...
Environment variables that are placed in the .env file would be available only on the server-side, if you want to make your env...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I think if this were implemented elsewhere (e.g. in a component) that would make more sense. However, since we’re at the selector level with access to
state
it’s simpler (and probably more efficient) to leverage a more flexiblehaveSettingChanged
selector that is capable of operating on a subset.Yes, better 👍
I’ve updated the ACs accordingly. Thanks all!
QA Update: ✅
Verified:
Tested this with Dashboard Sharing feature flag enabled and disabled. (not sure if that matters but wasn’t mentioned in the QAB, so didn’t want to take any risks 😄)
Setup each module in Site Kit and modified settings; they continue to work as-normal.
No changes on the behaviour of saving settings.
Disconnecting/reconnecting modules worked as expected.
Checked Admin settings to make sure they functioned as expected.