refactor(registerObserver): preserve observer reference

[adnasa]

1. returns observer when calling registerObserver
2. supercedes Prevent PerformanceObserver from getting destroyed over time. #26
3. extends tests

---

Tech debt

1. Missing possibility to mock logToConsole
2. consider using takeRecords or another option over callback
   One problem I found with the current implementation of passing callback into window.PerformanceObserver is that we "leaking" or "imposing" external functions into the instantiation of window.PerformanceObserver, which makes it hard or rather unintuitive to mock and test. One option to consider over this is to return a promise resolving the entries of the observer, but this is anti-pattern to Observers in general. A more optimal solution is a follow up and continuation to returning the instance is having callback removed and allow consumers to registerOberserver to use takeRecords which fulfills two purpose:
   • empty the store
   • process data. Given this; we give raw records back and let consumers for themselves decide how they want to process this (optimal but breaking change)

[adnasa]

this is a devtool for chrome + firefox. no need to polyfill.
Writing add-ons/extensions for IE is a whole different problem

[flxwu]

see #52, we'll polyfill for older browsers if we somewhen find a proper polyfill for the API :)

[adnasa]

the if-statement function name clearly indicates that we are logging to console. a comment on this is superfluous

[nitin42]

Oops! Yup, totally.

[nitin42]

I think if we go for observer.takeRecords() then users of this hook will receive the raw measures (not parsed and aggregated), and hence this goes against the usage of this hook. The main purpose of this hook is to provide users with options to get parsed measures so that they can send it over to their analytics server. If we undo this, then we may wanna expose utility functions too along with registerObserver to parse the measures. And I'm afraid that this will increase the API surface area. I just wanted to keep things minimal. Let me know what you think!

[adnasa]

The main purpose of this hook is to provide users with options to get parsed measures so that they can send it over to their analytics server.

This is exactly what I had in mind when I discussed takeRecords. There is nothing stopping us from returning the following shape upon instantiation:

return {
  // raw oberserver with it's API
  observer,
  // list of entries that were already processed with
  // `generateDataFromMeasures` and `getReactPerformanceData`
  // by react-perf-devtool
  compiledMeasurements,
}

which would serve the two main purposes with this change:

1. a reference of observer is received
2. a list of measurements are received

---

hmm.. I realised now that yes, you're right. You're right because the problem with my suggestion is that consumer can not receive new measurements as soon as they are updated.

let's leave this as is. please review :)

[nitin42]

I'll review your PR soon (by the end of this week). I am just busy doing interviews for full-time gig. Although the code changes looks good to me but I'll still pull the changes manually on my machine for behavioural testing. Thank you for all the contribution you've made to this project. I really appreciate your help 😄

[adnasa]

... 24 days later ... 😆 🤣

[flxwu]

maybe you should then also adapt the README as in #26 to make sure the user declares the observer in the global scope

[flxwu]

LGTM, tested locally aswell!