profileLinks: migrate to @tanstack/react-query

[flootr]

Proposed Changes

This PR covers a few migrations with <ProfileLinks />

• Migrate data fetching and mutations from our legacy data layer and Redux to using @tanstack/react-query. We follow the guideline to place the hooks alongside where they're used and therefore those can all be found in client/me/profile-links/data.
• Migrate any components to TypeScript
• Migrate any class components to function components

Previously we had a few different profile links related directories in client/me. I rearranged them to all be in client/me/profile-links. They're not used anywhere else and for me it makes more sense to have them contained in a single directory.

While generally profile links should behave exactly the same we introduce some UX improvements:

• show busy states in case a mutation is running (when adding or removing profile links)
• when adding links we now account for the case where we could have multiple errors and success when adding links from WordPress.com and show an error or success notice per link
• show notices when removing profile links

Testing Instructions

• Go to /me and smoke test the profile links section
• Try adding and removing links, verify those work correctly
• Try error cases (adding the same link twice) or block network requests (via your browser devtools)
• Verify unit tests pass and there are no type errors

If you're wondering where those profile links show up after adding them, go to https://gravatar.com/:wpcom-username and you should see the list there.

Pre-merge Checklist

• Has the general commit checklist been followed? (PCYsg-hS-p2)
• Have you written new tests for your changes?
• Have you tested the feature in Simple (P9HQHe-k8-p2), Atomic (P9HQHe-jW-p2), and self-hosted Jetpack sites (PCYsg-g6b-p2)?
• Have you checked for TypeScript, React or other console errors?
• Have you used memoizing on expensive computations? More info in Memoizing with create-selector and Using memoizing selectors and Our Approach to Data
• Have we added the "[Status] String Freeze" label as soon as any new strings were ready for translation (p4TIVU-5Jq-p2)?
• For changes affecting Jetpack: Have we added the "[Status] Needs Privacy Updates" label if this pull request changes what data or activity we track or use (p4TIVU-ajp-p2)?

[github-actions]

Calypso Live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-87713

Jetpack Cloud live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-87713&env=jetpack

[matticbot]

Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:

App Entrypoints (~275 bytes removed 📉 [gzipped])

name                 parsed_size           gzip_size
entry-subscriptions       -507 B  (-0.0%)     -136 B  (-0.0%)
entry-stepper             -507 B  (-0.0%)     -127 B  (-0.0%)
entry-main                -507 B  (-0.0%)     -126 B  (-0.0%)
entry-login               -507 B  (-0.0%)     -124 B  (-0.0%)

Common code that is always downloaded and parsed every time the app is loaded, no matter which route is used.

Sections (~2426 bytes removed 📉 [gzipped])

name                   parsed_size           gzip_size
security                   -6205 B  (-0.7%)     -797 B  (-0.3%)
privacy                    -6192 B  (-0.9%)     -794 B  (-0.4%)
notification-settings      -6192 B  (-0.7%)     -798 B  (-0.3%)
me                         -6192 B  (-0.9%)     -794 B  (-0.4%)
help                       -6192 B  (-0.8%)     -794 B  (-0.4%)
account-close              -6192 B  (-0.8%)     -795 B  (-0.4%)
account                    -6192 B  (-0.7%)     -796 B  (-0.3%)
site-blocks                -5689 B  (-0.8%)     -699 B  (-0.3%)
purchases                  -5689 B  (-0.3%)     -701 B  (-0.1%)
hosting                    -2486 B  (-0.4%)     -541 B  (-0.3%)
concierge                  -2486 B  (-0.6%)     -525 B  (-0.4%)

Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to.

Async-loaded Components (~551 bytes removed 📉 [gzipped])

name                                            parsed_size           gzip_size
async-load-calypso-lib-account-settings-helper      -2486 B  (-1.6%)     -551 B  (-1.2%)

React components that are loaded lazily, when a certain part of UI is displayed for the first time.

Legend

What is parsed and gzip size?

Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory.
Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.

Generated by performance advisor bot at iscalypsofastyet.com.

[flootr]

I think this is generally ready for a first round of reviews.

/cc @digitalwaveride

[tyxla]

This PR covers a few migrations with :

• Migrate data fetching and mutations from our legacy data layer and Redux to using @tanstack/react-query. We follow the guideline to place the hooks alongside where they're used and therefore those can all be found in client/me/profile-links/data.
• Migrate any components to TypeScript
• Migrate any class components to function components

Seems like this PR is doing a bit too much. Could we split the PR to one PR per migration at least? I'd say that we could ideally do 1 PR per migration per file even, otherwise, we'll still be doing too much in a single PR. WDYT?

[tyxla]

Some of these types seem arbitrary and could be inlined at no cost. ProfileLink[] is even shorter than ProfileLinkResponse.

[tyxla]

Are we clearing this cache properly when the user logs out / logs in? Should we key them by user ID?