feat: memoize fox page domain complex values [PoC]

[gomesalexandre]

Description

Proof of concept validating whether or not react-memo/require-usememo makes sense for us, fixing lint warnings across the Fox Page.

• Wraps callbacks in useCallback
• Extracts inline arrow functions to useCallback whenever possible
  • When an arrow function is in fact required because we're passing a variable from the current scope, use the eslint-disable-next-line to disable the rule https://github.com/shapeshift/web/blob/d77e58ab59d406819bb5ca1dd2abf44ba914d5a2/src/plugins/foxPage/foxPage.tsx#L197-L198
• Wraps complex (non primitive) expressions as props in useMemo. Two patterns were used here, so we can decide which one works better:
  1. Making style props individual variables wrapped in useMemo() https://github.com/shapeshift/web/blob/d77e58ab59d406819bb5ca1dd2abf44ba914d5a2/src/plugins/foxPage/components/Total.tsx#L17-L36
  2. Extracting all complex (non primitive) style props in a single object as variable, wrapped in useMemo() https://github.com/shapeshift/web/blob/d77e58ab59d406819bb5ca1dd2abf44ba914d5a2/src/plugins/foxPage/components/FoxTab.tsx#L27-L57

I would be inclined towards the latter whenever possible, as wrapping individual props might be very verbose very fast.

Notice

• [x] Have you followed the guidelines in our Contributing guide?
• [x] Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Pull Request Type

• [ ] :bug: Bug fix (Non-breaking Change: Fixes an issue)
• [ ] :hammer_and_wrench: Chore (Non-breaking Change: Doc updates, pkg upgrades, typos, etc..)
• [x] :nail_care: New Feature (Breaking/Non-breaking Change)

Issue (if applicable)

N/A

Risk

Testing

• Fox Page shows no regressions

Engineering

• Refer to top-level notes
• Memoized values properly reflect the previously passed down complex values
• Naming looks sane
• CI is happy

Operations

• Refer to top-level notes

Screenshots (if applicable)

[gomesalexandre]

Current dependencies on/for this PR:

• develop
  • PR #2699 👈

This comment was auto-generated by Graphite.

[gomesalexandre]

Current dependencies on/for this PR:

• develop
  • PR #2691
    • PR #2693
      • PR #2698
        • PR #2699 👈
      • PR #2697

This comment was auto-generated by Graphite.

[NeOMakinG]

As discussed in pm, I'm in favor of the second implementation as it's way less verbose

It will lead to some naming hell with nested elements, but it may also help us integrate in a more atomic and reusable way.

Btw, this could be voted into an ADR, to track the decision and specify it properly!

[0xdef1cafe]

mr @gomesalexandre do we want to merge or close this?

[gomesalexandre]

mr @gomesalexandre do we want to merge or close this?

Let's close it, too much pain to keep up-to-date as a separate PR. Instead let's try and ensure new code is properly memoized and touched files in PRs are memoized whilst in the neighborhood

[gomesalexandre]

Comment