Too many calls for storeChild.onUpdate()

[princiya]

STR:

• In lightbeam.js, storeChild.onUpdate() add a console.statement

• Reset Lightbeam
• Open https://mozvr.com/
• When the graph is loaded, one each thirdParty and firstParty are shown

• But storeChild.onUpdate() gets called too many times. This number is variable, I get 12, 15, 19 etc.

These unnecessary calls might slow down the browser.

[biancadanforth]

Thanks @princiya for making this issue; on closer inspection, store.setThirdParty calls store.setWebsite once for the first party and once for the third party. Then, later on it callsstore.updateChild, even though store.updateChild is already called inside the store.setWebsite method. There is duplication here.

setWebsite(hostname, data) {
    // some stuff...
    if (newSite) {
      this.updateChild(this.outputWebsite(hostname, websites[hostname]));
    }
  },
  setThirdParty(origin, target, data) {
    // ... some stuff
    this.setWebsite(origin, firstParty);
    this.setWebsite(target, thirdParty);

    if (newThirdParty) {
      this.updateChild(this.outputWebsite(target, data, origin));
    }
  },

[jonathanKingston]

if (newThirdParty) { within setThirdParty needs to check if both firstParty and thirdParty already existed if they don't then this shouldn't fire.

Basically this line should only pass when third and first party already exist but don't have a connection between them. This might lead to more calls to update than the exact number however there currently will be a slight increase over that with this code.

The following code should probably check the return value and store if it existed first before changing to a blank object:

const firstParty = this.getWebsite(origin) || {};
const thirdParty = this.getWebsite(target) || {};

I wanted to make sure lightbeam.js is resiliant to this type of over updating, the liklihood as the code gets more complex this will happen we should check this first.

Currently the update numbers is likely: nfp + ntp + ntpc + etpc

Where:

• nfp = new first party
• ntp = new third party
• ntpc = new third party connections
• etpc = new third party connections on existing nodes

Fixing this will make the algo: nfp + ntp + etpc

[jonathanKingston]

Ugh calculating the O notation is painful, anyways... it's not going to exponentially grow with the size of the graph. This should make this a p2 at least.

[jonathanKingston]

Also I probably wasn't clear but there will be more updates than there are new nodes added to the graph. Fixing that line should make it send update on new edges and new nodes which could be slightly higher than just third parties + first parties.