Main Dashboard: improve performance by loading React dash only when connected / in dev mode

[enejb]

Improved the loading performance of the connection page my making sure that we don't load the admin.js file.

This results in a much faster appearance of the connection button the jetpack dashboard page.

Before:
https://cloudup.com/csvrz9kD32W

After:
https://cloudup.com/cvBU_z__CQa

Notes

This makes use of a React portal to hook 2 extra links to the footer, now relying on PHP for all links but those 2.

This introduces 2 issues:

1. It breaks tracking on the footer links.
2. It removes the "Reset" and "Dev Tools" buttons when not connected to WordPress.com / not in dev mode.

Testing instructions:

• Activate the jetpack plugin. Notice that the banner shows up as before.
• Navigate to the Jetpack Dashboard. Notice that the page loads noticeably faster.
• Also test when in development mode, and in different connection scenarios.

Proposed changelog entry for your changes:

• Improves the loading of the dashboard when Jetpack is not connected.

[jetpackbot]

	Warnings
⚠️	pre-commit hook was skipped for one or more commits

This is an automated check which relies on PULL_REQUEST_TEMPLATE. We encourage you to follow that template as it helps Jetpack maintainers do their job. If you think 'Testing instructions' or 'Proposed changelog entry' are not needed for your PR - please explain why you think so. Thanks for cooperation 🤖

Generated by 🚫 dangerJS against 7097a29

[delawski]

Tested it and works great! The code looks good, too.

[tyxla]

This did improve the performance in an obvious way. Nice work Enej! 👏

[jeherve]

This is breaking the dashboard for sites using Jetpack's Development mode.

[enejb]

True the notice is not there any more. Since it is baked into the admin.js bundle which this PR removed on purpose.

To read the notice. I think it would make more sense to rething the notices in the first place.
Right now that notice is not super useful for me.
I think it does help users that run the Jetpack beta version of the plugin but but they already see what version is being run in the admin bar.

cc @keoshi for some ideas here.

[jeherve]

By Development mode, I meant this:
https://jetpack.com/support/development-mode/

The dashboard does not load at all in this mode anymore since we're now only loading the bundle if Jetpack is connected to WordPress.com.

[keoshi]

@enejb and I just chatted a bit about this and I agree that we can do without the notice, especially if Jetpack is much more performant without loading these assets.

A proposed solution would be to add a little flag at the top of the page, as well as note if the user is using Beta/staging environment/etc. in the footer.

Quick and dirty mock:

One thing left to consider is that we'd be removing the Submit Beta feedback link. In p1569845703354400-slack-jpop-support I've asked if we have any data on the amount of feedback we receive. Depending on that we might add the link to the top or bottom.

[jeherve]

Quick and dirty mock:

We can talk about this a bit more in a different issue, but it's worth noting that we already have such badges when the site is connected to a WordPress.com sandbox:

--

jetpack/_inc/client/components/masthead/index.jsx

Line 55 in 3dd06e7

sandboxedBadge = this.props.sandboxDomain ? (

We also have this notice when using Jetpack Dev mode:

--

jetpack/_inc/client/components/masthead/index.jsx

Line 54 in 3dd06e7

const devNotice = this.props.siteConnectionStatus === 'dev' ? <code>Dev Mode</code> : '',

[enejb]

Thanks for the clarification and great work catching that! I didn't test it in that mode at all.

[enejb]

Thanks the fix you suggested works as tested.
However now when I am not connected but a user that can't connect I end up stairing at the blank screen.
I wonder if we should show a nicer notice to the user in that case.
Or not even allow the user to end up there.

[jeherve]

This change also causes some footer links (including the Debug link that can be used to diagnose connection issues) to disappear:

Before

After

We may want to keep those, even for unconnected users.

[jeherve]

Would it be an option to drop the whole footer implementation from the React dashboard, and only use PHP to display that footer?

We could then do the tracking from the PHP / JS side as well, since we load the tracks js client on all pages already.

[jeherve]

I pushed a change to remove a duplicate, and extract the link building process. I was hoping that this would help me bring Tracks back on those links. Unfortunately it is not that easy. While I can add some tracking with the data-jptracks-name and data-jptracks-prop attributes on links, those props won't exactly match the ones that were defined when the links were built within the React interface.

Another problem this PR introduces is the lack of "Reset" and "Dev Tools" options when the site is not connected to WordPress.com. Those buttons are useful when developing Jetpack.

None of this may be blocking, especially since this PR will introduce significant performance improvements for folks connecting Jetpack to WordPress.com for the first time. That said, I'd love to have another Crew member's final opinion on this.

[kraftbj]

Another problem this PR introduces is the lack of "Reset" and "Dev Tools" options when the site is not connected to WordPress.com. Those buttons are useful when developing Jetpack.

I would consider that non-blocking for this PR (the performance enhancement for regular users is worth it) but we can/should re-add them in another PR. Either in the footer there or the Jetpack Debug page (which I should take a pass at now that most interesting bits of that page are in the Site Health now).

[tyxla]

Nice work folks 👏