Ideas for getting rid of Global config object

JavaScript
1

Hi,

Our company builds / maintains a large number of websites. In these sites there are many php and / or javascript plugins that add additional functionality such as feeds, video players, ads…

The approach the company has used for a number of years ( pre-dates me working there ) is to setup a global JS variable like:

 var Company = {"adConfig":{"site":"a.com","msite":"a.m",...} }

It has many different objects inside the Company variable that contain info that many of the JavaScript and PHP plugins write to and retrieve.

The issue is just like any global, this has started to become problematic as several of the plugins overwrite the same value and cause other plugins to fail.

So I pose this question to other developers to see if other than the ideas I outline below, what other possibilities may exist:

  1. Create a Configuration class that is instantiated with a base set of values that can be overridden relative to each individual plugin needs. The good part is that each instance of config would not affect other instances. The bad part is that each instance would need to be registered as being ‘paired’ with a plugin which inevitably mean a Factory + Registry; another type of global
  2. Create a Configuration Observer class. Good part is that the config could be maintained locally and sync any subscribers. The subscribers could decide to accept the updated ( synced changes ) or keep their existing config. There fore the subscriber could override the default confgiuration. The bad part is that this is a more complicated code scenario and it would force each plugin developer to put the subscriber logic into their plugins.

Keep in mind that this solution also has to provide the purely JavaScript plugins the ability to get the right global configuration data.

Do you have any thoughts on other ways this might be done?

Your thoughts are appreciated.

Regards,
Steve

2

I usually just use pseudo namespaces by prefixing something that should make them unique eg.

app1_ Company =
app2_ Company =
app3_ Company =

3

I’d like the understand the problem a little better first. In your sample config, the first key is “adConfig”. I presume then that each plugin’s config data is namespaced under the plugin’s name? So how does one plugin end up overwriting another’s values?

4

Thanks @Mittineague

@Jeff_Mott: Each of the plugins use the same data stored in this single JavaScript object. For example, the video plugin uses the ck, sk, nk, adsite, and ad unit parameters so does the Ads plugin. Now the video plugin just reads these values but he Ads plugin reads / writes… then come the Elastic Search Plugin, It too needs these values but it can read / write. In special contexts the Elastic Search Plugin will need the ck and sk values to change so it will write new values which can cause the Ads and Video plugin to fail. This is a somewhat contrived example but it may help you better understand.

Regards,
Steve

5

So video and ads plugins both read and/or write to ck, sk, and others. Are ck, nk, etc supposed to be the same value across those plugins? Or are they unrelated values but for the unhappy coincidence that they have the same name?

6

The ck and nk values are supposed to match the current page category and garner their values from the page. Sometimes the search plugin will change ( override ) these values so the video player can cue up ads that are related to the search; however, the Analytics plugin cannot use the overridden values as it needs to base the analytics on the actual page values.

7

Sounds like you need objects that inherit from other objects. The base object contains the page values and the video player uses an object that inherits from that base object and overrides specific properties with its own copy.

8

Yes inheritance is one way to deal with this. The one thing I worry about is that many of the Junior developers that are working on these sites build class based plugins that are not based on best practices. It shows me that they don’t yet understand well structured, encapsulated, extensible, and flexible code.

Inheritance can get a bit tricky for some. I was hoping to do something that allows a lower-barrier of entry for these devs as they work in different offices / countries and we cannot practically enforce conformance to this.

You are right that this is well suited to inheritance.

There just doesn’t seem to be a magic bullet that can be used here. This is why the Observer Idea can work as subscriber code can be very basic; easy to communicate. This, like inheritance will allow each subscriber to maintain a unique instance of the config and override the observer synced config or use it.

Regards,
Steve

9

eek. That’s a shame. I was going to suggest the same thing as felgall. I figured it would be the least disruptive to how things currently work. Something like…

var baseConfig = {
    'ck': '...',
    'nk': '...',
    'etc': '...',
};

var videoPluginConfig = Object.create(baseConfig);

// reading ck inherits from base
console.log(videoPluginConfig.ck);

// writing ck affects only videoPluginConfig
videoPluginConfig.ck = 'special_context';
10

Yes it seems that inheritance is the least disruptive. I’ll bounce the inheritance idea off my director and see if they think this could fly across our company developer domains?

Many thanks for your help!

Regards,
Steve