Link follow to notifications in article pages

[aracho1]

What does this change?

• Couple follow and notifications: Following a contributor now automatically enables notifications, and unfollowing disables them.
• Auto-follow users with existing notifications: On load, if a user has notifications turned on for a contributor but isn't following them, the tag follow is automatically enabled to keep the two states consistent.
• Replace the notifications button with a text label that shows the current notification state and directs users to Settings to change it.

Why?

We are making a stronger link between follow and notifications, by making users follow something before they can set notifications for the subject.

Screenshots

Not following	Notification On	Notification Off

[github-actions]

Deploy build 25661 of dotcom:rendering-all to CODE

All deployment options

• Deploy build 25661 of dotcom:rendering-all to CODE
• Deploy parts of build 25661 to CODE by previewing it first
• What's on CODE right now?

---

From guardian/actions-riff-raff.

[github-actions]

Deploy build 1066 of dotcom:ab-testing to CODE

All deployment options

• Deploy build 1066 of dotcom:ab-testing to CODE
• Deploy parts of build 1066 to CODE by previewing it first
• What's on CODE right now?

---

From guardian/actions-riff-raff.

[aracho1]

I've assumed it's ok to create a new Sentry error type for this but please let me know if I should just use an existing one e.g. `'bridget-getTagClient-isFollowing-error'

[aracho1]

Moved the block list check into a useEffect because the original code was calling setState directly during render

[JamieB-gu]

Why does showFollowTagButton require a useState? It looks like it depends on four properties:

1. blockList, which is static and never changes.
2. id, which is a prop, and will cause a re-render if changed¹.
3. isMyGuardianEnabled, which is a separate state variable, and will cause a re-render if changed².
4. isBridgetCompatible, which is a separate state variable, and will cause a re-render if changed.

In other words, it looks like it can entirely derived from these, and can therefore just be a value calculated in the body of the component. 1) cannot change, and any changes to 2), 3) or 4) will cause a re-render that will re-calculate this derived value in the body.

Footnotes

1. https://react.dev/learn/passing-props-to-a-component#how-props-change-over-time ↩

2. https://react.dev/reference/react/useState#setstate ↩

[github-actions]

Hello 👋! When you're ready to run Chromatic, please apply the run_chromatic label to this PR.

You will need to reapply the label each time you want to run Chromatic.

Click here to see the Chromatic project.

[JamieB-gu]

Looks good, one question.

[JamieB-gu]

Why does showFollowTagButton require a useState? It looks like it depends on four properties:

1. blockList, which is static and never changes.
2. id, which is a prop, and will cause a re-render if changed¹.
3. isMyGuardianEnabled, which is a separate state variable, and will cause a re-render if changed².
4. isBridgetCompatible, which is a separate state variable, and will cause a re-render if changed.

In other words, it looks like it can entirely derived from these, and can therefore just be a value calculated in the body of the component. 1) cannot change, and any changes to 2), 3) or 4) will cause a re-render that will re-calculate this derived value in the body.

Footnotes

1. https://react.dev/learn/passing-props-to-a-component#how-props-change-over-time ↩

2. https://react.dev/reference/react/useState#setstate ↩