question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Expose owned module settings to client

See original GitHub issue

Feature 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 in createSettingsStore should be updated to accept an optional keys 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 optional ownedSettingsSlugs argument (string[]) which should default to an empty array
  • A new haveOwnedSettingsChanged selector should be generated in the resulting store definition which uses haveSettingsChanged internally; returning true if any owned setting has changed, otherwise false
    • If the module has no owned settings, this should always return false
  • 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 the haveSettingsChanged selector as per the AC.

In assets/js/googlesitekit/modules/create-module-store.js:

  • Add optional ownedSettingsSlugs argument to createModuleStore and create the haveOwnedSettingsChanged selector in the resulting store definition as per the AC.
    • In the implementation of haveOwnedSettingsChanged:
      • If ownedSettingsSlugs was passed to createModuleStore call haveSettingsChanged( ownedSettingsSlugs ) to check if the owned settings have changed.
      • Otherwise, return false.

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.

Test Coverage

  • Add tests for the new haveSettingsChanged selector, and update tests for createModuleStore 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:closed
  • Created a year ago
  • Comments:6

github_iconTop GitHub Comments

1reaction
aaemnnosttvcommented, May 6, 2022

@aaemnnosttv we already have the haveSettingChanged selector in createSettingsStore. Maybe we shouldn’t change the haveSettingsChanged selector and just use multiple haveSettingChanged calls in the haveOwnedSettingsChanged selector?

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 flexible haveSettingChanged selector that is capable of operating on a subset.

I think the haveOwnedSettingsChanged selector should be created regardless the module has owned settings or not. If it has those slugs, we will check whether those settings have been changed or not. If the module doesn’t have owned settings, then we should return false and that’s it. It will help us avoid a need to check whether a module has that selector. What do you think?

Yes, better 👍

I’ve updated the ACs accordingly. Thanks all!

0reactions
wpdarrencommented, May 24, 2022

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.

Read more comments on GitHub >

github_iconTop 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 >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found