Improve site status check for json format

[nightnei]

How AI was used in this PR

AI helped to write the code and we had a few iterations to adjust teh approach

Proposed Changes

1. For site status --format=json we receive emoji which doesn't make sense for machine-readable output and it forces to use .includes('Online') instead of direct check via === 'Online'
2. We have localization, so it complicates a lot the condition. As a workaround so far, I found out that we can check for existance of autoLoginUrl, but it's jsut workaround.

So I propose to introduce isOnline: boolean for json.

Testing Instructions

1. npm run cli:build
2. node apps/cli/dist/cli/main.mjs site status --path=~/Studio/my-wordpress-website --format=json
3. Assert that you see isOnline: boolean
4. node apps/cli/dist/cli/main.mjs site status --path=~/Studio/my-wordpress-website
5. Assert that no regresion and you don't see isOnline: boolean

[wpmobilebot]

📊 Performance Test Results

Comparing 260fef0 vs trunk

app-size

Metric	trunk	260fef0	Diff	Change
App Size (Mac)	1384.34 MB	1423.91 MB	+39.57 MB	🔴 2.9%

site-editor

Metric	trunk	260fef0	Diff	Change
load	1685 ms	1662 ms	23 ms	⚪ 0.0%

site-startup

Metric	trunk	260fef0	Diff	Change
siteCreation	9553 ms	8604 ms	949 ms	🟢 -9.9%
siteStartup	4955 ms	4953 ms	2 ms	⚪ 0.0%

---

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change (<50ms diff)

[fredrikekelund]

This is fine, but I could also see us adding an optional jsonValue property to siteData entries to avoid outputting emoji in the JSON objects. I'll leave it up to you, @nightnei

[nightnei]

This is fine, but I could also see us adding an optional jsonValue property to siteData entries to avoid outputting emoji in the JSON objects. I'll leave it up to you, @nightnei

Sorry, I didn't understand what you meant by "an optional jsonValue property". Could you please elaborate? This?

[fredrikekelund]

There's already an optional jsonKey property that determines which object key we use when --format=json. What I meant by my previous comment was that we could do something similar for values with a jsonValue property. I.e., something like this:

{
	key: __( 'Status' ),
	jsonKey: 'status',
	jsonValue: isOnline ? 'online' : 'offline',
	value: status,
}

Totally up to you!

[nightnei]

There's already an optional jsonKey property that determines which object key we use when --format=json. What I meant by my previous comment was that we could do something similar for values with a jsonValue property. I.e., something like this:

{
	key: __( 'Status' ),
	jsonKey: 'status',
	jsonValue: isOnline ? 'online' : 'offline',
	value: status,
}

Totally up to you!

Got it, thanks for the explanation.
I was thinking about this option and, from code perspective, your proposition looks indeed a bit better.
But from consumer perspective, I find better to provide a predicate as isOnline and check the status with if (status.isOnline) ... instead of using keyword as if (status.status === 'online').

Let's go with status.isOnline.