Adrian/add storage solution

[adrianviquez]

This PR adds a context to the Codecov product to hold state and functionality to save/get data to/from the url and local storage. This context is used in the CodecovProvider that will be the main wrapper for all things Codecov. This is the preferred approach over this pr.

Notes

• When I name things "Codecov" here, I'm referring it as a product and not as the company. So thinking of it as a "feature" or "product" such as "replay" or "issues". It might be unnecessary for some cases (like the persistence/url), but I think it makes sense for the provider/context pieces. Open to thoughts here!
• CodecovProvider: this is the main code that will act as a wrapper for everything in the Codecov product. It instantiates and initializes the CodecovContext component, as well as sets functions to manipulate the context.
• CodecovContext: the context itself. Has some helper methods, one of note being initializeCodecovContext. This will initialize the context with data from the url or local storage.
• Persistence.tsx and url.tsx these have helper methods to interact with url and local storage. More specifics in the files below. I'm currently missing a function to set data into the URL. I'm also open to changing the "Codecov"-ness of these methods as they shouldn't necessarily be Codecov specific.

Thanks!

[adrianviquez]

You'll see both methods here are get/setCodecovData... . As stated in the description, I'm thinking of Codecov here more as a product, so the idea with these helper methods is to help choose the correct key and decode the data that's needed according to what this method expects.

Thinking it through though, I think we could make it more generic and be something like this

export function getDataFromLocalStorage<T>(
  localStorageKey: string,
): T | null {
  const value = localStorage.getItem(localStorageKey);

  if (!value) {
    return null;
  }

  let decoded: T;

  try {
    decoded = JSON.parse(value);
  } catch (err) {
    captureException(err);
    return null;
  }

  return {...decoded}
}

And elevate the key to the caller. And do something similar for the setter. Wdyt?

[adrianviquez]

I actually went back and did this, so new fn follows this. Also did that for setting data to local storage and query data from the url

[adrianviquez]

Similar to the comment above, there's probably a way to generically request fields from the query param and validate those, having a harder time thinking about that one as each field probably has a different validation based on it's data type, but I suppose we could do some validation based on the type you're expecting, so making a mapping that says something like "repository": string, "branches": string[], "date": datetime, and have methods that do like getString, getArray, etc.

Edit: addressed this here

[adrianviquez]

Currently redundant; could extend from the type in the Context component if this eventually grows or simply reuse it. Leaning towards reusing the original instead of extending.

[adrianviquez]

Trying this approach to comment functionality, not sure how I feel but wanted opinions.

Edit: Got rid of it, already talked myself out of it 😂