SSR Footer: Use an empty state for Automattic branding before set the final value

[WBerredo]

Related to #77696
Fixes #77799

Proposed Changes

SSR requires the initial state to be the same for the client and server version, thus having a random text on the footer makes it always use the client version.

In order to align the initial state for both cases, the initial state for the Automattic branding will be only the "Automattic" part, and the text will be added later.

Testing Instructions

Trunk

• On a logged-out tab
• Go to a page that displays the footer. Ex: /theme/miniature
• Reload the page
• Open the console and you SHOULD see an error stating there is a mismatch between the client and server version and you'll see the client version on the screen

This branch

• On a logged-out tab
• Go to a page that displays the footer. Ex: /theme/miniature
• Scroll down to the bottom of the page
• Reload the page
• You should see only Automattic at first, and then the correct branding
• Open the console and you SHOULD NOT see any errors

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-70069

Jetpack Cloud live (direct link)

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

[matticbot]

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

App Entrypoints (~28 bytes added 📈 [gzipped])

name           parsed_size           gzip_size
entry-stepper        +69 B  (+0.0%)      +28 B  (+0.0%)
entry-main           +69 B  (+0.0%)      +28 B  (+0.0%)
entry-login          +69 B  (+0.0%)      +28 B  (+0.0%)

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

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.

[matticbot]

This PR modifies the release build for happy-blocks

To test your changes on WordPress.com, run install-plugin.sh happy-blocks fix/ssr-footer on your sandbox.

To deploy your changes after merging, see the documentation: PCYsg-r7r-p2

[jsnajdr]

Looks good, thanks for addressing all feedback 👍

[gcsecsey]

Looks good to me too, and works as described.

[noahtallen]

By the way useLayoutEffect has been causing warnings in the React 18 PR #77046. There's more info about it here: https://gist.github.com/gaearon/e7d97cdf38a2907924ea12e4ebdf3c85

But the core idea is that since effects don't run on the server in SSR, useLayoutEffect can be problematic because its purpose is to update content before people see it. When SSR generates a layout without using the effect, that content wouldn't include what the layout effects expects to add.

Thankfully, this isn't a problem for us because the default content is just the Automattic logo, so we have a graceful fallback.

What I did to fix the warning in #77046 was to conditionally define useLayoutEffect in SSR mode like this:

const useIsomorphicEffect = typeof window !== 'undefined' ? useLayoutEffect : useEffect;

And it seems to resolve the issue. Just wanted to drop a comment here as well.

[noahtallen]

Interestingly, it looks like this warning will be removed in a future React version: facebook/react#26395

[jsnajdr]

This particular code would be better off if it used just useEffect. Without SSR, the benefit of useLayoutEffect would be that the version of the page with the incomplete footer would never be actually painted. The first paint would occur only after the layout effect sets the footer to the final random value.

But with SSR, the initial version is always painted, because it's a part of the initial HTML markup. useLayoutEffect doesn't make any difference compared to useEffect.