-
Notifications
You must be signed in to change notification settings - Fork 58
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
Conversation
a310bc4
to
d1c4d90
Compare
Issues remaining:
|
src/jetpack-editor-setup.js
Outdated
@@ -19,7 +19,7 @@ const supportedJetpackBlocks = { | |||
}, | |||
}; | |||
|
|||
const setJetpackData = async ( { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 } ); |
There was a problem hiding this comment.
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 👍
There was a problem hiding this comment.
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.
src/jetpack-editor-setup.js
Outdated
|
||
const jetpackData = setJetpackData( jetpackState ); | ||
|
||
require( '../jetpack/extensions/editor' ); |
There was a problem hiding this comment.
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
@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 |
There was a problem hiding this 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 } ); |
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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?
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? |
@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): After jetpack PR (commit fd39dd9)
|
See differences in App.js files as well, before and after the update. Looks like it should be negligible.
|
Thanks @cameronvoell - By |
This is a work in progress
See Jetpack PR: Automattic/jetpack#15389
PR submission checklist:
RELEASE-NOTES.txt
if necessary.