Onboarding: Don't use site title as default domain query if it'll just error

[p-jackson]

We've been defaulting the domain query to the site title since it seems like a good place to start when looking for a domain. However the domain API returns an error for queries that only include "non-latin" characters, so if a site title is Japanese then the domain step will be in an error state as soon as the user navigates there.

An example of what the user might see when they navigate to the domain step:

(also working on the incorrect network error here: #47985)

By not defaulting to the site title in this case the user will either:

• Type the site title themselves into the search box, in which case they'll get an error, but it'll make more sense given they've triggered it themselves
• Maybe they're going to try a traditional "latin-only" domain name anyway

Changes proposed in this Pull Request

• Add isGoodDefaultDomainQuery helper function
• Don't auto fill domain query with the site title if isGoodDefaultDomainQuery returns false

Testing instructions

• Use the /new flow and experiment using the flow with and without valid site titles and seeing how the domain picker responds to this.
• We also have a domain picker in the in-editor launch flow, so make sure we don't have the same issue there

Partial #37665

[matticbot]

Test live: https://calypso.live/?branch=update/dont-use-site-title-as-default-domain-query-in-some-locales

[matticbot]

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

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

name                 parsed_size           gzip_size
entry-gutenboarding       +145 B  (+0.0%)      +75 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.

[andrewserong]

This is testing nicely for me for the domain search. I didn't manage to test it out in the created site's launch flow, because of I believe a different issue where using a Japanese site title caused creating the site to fail (I was attempting to create a site with the title "私のサイトのタイトル").

In this case, I left the site title empty, and the blog_name sent to the new site request still used the site title, which appears to be why it was erroring out for me:

I don't have exact testing steps for recreating this, but I tried entering my site title, going to the domain step, entering a search, then clearing the search out completely and skipping the domain step, and then proceeding to attempt to create the site.

I think this line is the culprit as it's falling back to the siteTitle for the domain:

https://github.com/automattic/wp-calypso/blob/trunk/client%2Flanding%2Fgutenboarding%2Fstores%2Fonboard%2Factions.ts#L58

[lsl]

permalink

That looks about right, reproduced in /new/en using non latin chars. Fails site creation if you skip the domain step without providing english text.

Dug a little bit, the underlying error is {error: "blog_name_required", message: "Please enter a site name."}

Turns out we just ignore anything non english and act like nothing was given 👍

$string = preg_replace( '/[^a-z0-9]/i', '', $string );

Probably best to fix in the endpoint and provide some default text to the create step in this case. We can also try to translit any accented ascii.

[lsl]

LGTM, added todo on #37665 for the failure mode @andrewserong discovered.

[p-jackson]

Thanks for investigating the failure mode @lsl 👍