Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Contact Info jetpack native blocks behind DEV flag #1934

Merged
merged 17 commits into from
Apr 17, 2020

Conversation

Tug
Copy link
Contributor

@Tug Tug commented Feb 19, 2020

This is a work in progress

See Jetpack PR: Automattic/jetpack#15389

PR submission checklist:

  • I have considered adding unit tests where possible.
  • I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

@Tug Tug requested review from cameronvoell and ceyhun February 19, 2020 13:43
@Tug Tug self-assigned this Feb 19, 2020
@Tug Tug force-pushed the try/jetpack-native-blocks branch from a310bc4 to d1c4d90 Compare February 26, 2020 14:43
@Tug Tug marked this pull request as ready for review February 26, 2020 15:30
@cameronvoell
Copy link
Contributor

cameronvoell commented Apr 8, 2020

Issues remaining:

  • Save a block and return, it should still show as a contact block - b3c364c
  • Add a contact info on the web, edit on mobile, it should work - b3c364c
  • Fix weird focus problem where you can type in address/email/phone without the inner block showing as selected Automattic/jetpack@97092d7

@@ -19,7 +19,7 @@ const supportedJetpackBlocks = {
},
};

const setJetpackData = async ( {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Without removing this, we would start parsing html to blocks before the jetpack blocks got registered. I'm not sure if this changes our existing thoughts on when we should check for jetpack permission. Perhaps it should be done on the app side. But it will at least have to block the parsing of HTML to blocks otherwise existing jetpack blocks will show up as unknown blocks.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed block parsing (and thus loading the editor) should be done afterwards. We can delay the loading of the editor for a bit but it wouldn't be a great UX if it happened each time. It would be nice if we could get jetpack data from the parent app, or at least cache here it somehow.

@@ -55,6 +56,7 @@ export class RootComponent extends React.Component {
super( props );
setupLocale( props.locale, props.translations );
setupApiFetch();
setupJetpackEditor( props.jetpackState || { blogId: 1, isJetpackActive: true } );
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'll have to make this async when we actually fetch the data from the site, but for now let's keep it that way 👍

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good. Just going to note here that if we make an async call to check if we're enabling jetpack blocks, then we need to block the action of parsing raw html to blocks until after that function returns, otherwise jetpack blocks will show up as not enabled, even if api response says they should be enabled.


const jetpackData = setJetpackData( jetpackState );

require( '../jetpack/extensions/editor' );
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we need to add a DEV flag here

@cameronvoell
Copy link
Contributor

@iamthomasbishop As we mentioned in the chat this feature is initially being added behind a DEV flag while we iterate on some of the API requirements. In the mean time, it can be tested in it's current state on iOS using AppCenter build number: 27246 (test PR with link here).

I created this issue for tracking design review and api requirements for enabling this block in production: #2166

Copy link
Contributor

@cameronvoell cameronvoell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Verified it's disabled behind the DEV flag, looks good! I added one comment and one question that is related to code that's likely remaining for the API code that is still in progress. I believe we're ready to merge though.

@@ -55,6 +56,7 @@ export class RootComponent extends React.Component {
super( props );
setupLocale( props.locale, props.translations );
setupApiFetch();
setupJetpackEditor( props.jetpackState || { blogId: 1, isJetpackActive: true } );
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good. Just going to note here that if we make an async call to check if we're enabling jetpack blocks, then we need to block the action of parsing raw html to blocks until after that function returns, otherwise jetpack blocks will show up as not enabled, even if api response says they should be enabled.

tracksUserData: userData,
wpcomBlogId: blogId,
};
global.window[ JETPACK_DATA_PATH ] = jetpackEditorInitialState;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just want to ask you @Tug about this line since it's hard to understand with the API calls temporarily disabled. Are we utilizing global.window here so jetpack code can access jetpackEditorInitialState when initializing, similar to how they're doing it on the web side in jetpack/extensions/editor.js?

@cameronvoell cameronvoell changed the title Try jetpack native blocks Contact Info jetpack native blocks behind DEV flag Apr 17, 2020
@cameronvoell cameronvoell merged commit fd39dd9 into develop Apr 17, 2020
@maxme
Copy link
Contributor

maxme commented Apr 21, 2020

I was wondering if the bundle went bigger with the dependency to Jetpack (and sub-dependencies). Can we also check if loading times went up?

@Tug Tug deleted the try/jetpack-native-blocks branch April 21, 2020 09:38
@cameronvoell cameronvoell restored the try/jetpack-native-blocks branch April 21, 2020 16:53
@Tug Tug deleted the try/jetpack-native-blocks branch April 21, 2020 16:59
@cameronvoell
Copy link
Contributor

I was wondering if the bundle went bigger with the dependency to Jetpack (and sub-dependencies). Can we do a sanity check

@maxme I just performed yarn bundle on gutenberg-mobile develop before and after this PR is merged and I didn't see any increase in the size of the bundle directory.

Before jetpack PR (commit ca78090):
5.0M bundle/ios/assets
24M bundle/ios
5.0M bundle/android/raw
24M bundle/android
48M bundle

After jetpack PR (commit fd39dd9)
5.0M bundle/ios/assets
24M bundle/ios
5.0M bundle/android/raw
24M bundle/android
48M bundle

also verify if the loading times?
I can check this too, but figure it's worth clarifying first since I think you might have had a typo. If I'm understanding you correctly, a robust check of bundle load times would be to test how long it takes to launch the gutenberg editor in WPiOS and WPAndroid before and after the jetpack code is added. Let me know if that's what you meant, or it was something else.

@cameronvoell
Copy link
Contributor

See differences in App.js files as well, before and after the update. Looks like it should be negligible.

  Before Jetpack After Jetpack differences
android App.js 8523434 8523915 -481
android App.js.map 11217927 11231035 -13108
       
ios App.js 8541370 8541748 -378
ios App.js.map 11269901 11283125 -13224

@maxme
Copy link
Contributor

maxme commented Apr 23, 2020

Thanks @cameronvoell - By also verify if the loading times? I meant Can we also check if loading times went up? ;) - but let's forget that since the bundle size didn't change much.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants