Mobile Contact Info Block

[cameronvoell]

Changes proposed in this Pull Request:

This PR adds .native.js equivalents of 5 files related to the jetpack/extensions contact-info block in order to make the contact-info block usable in the gutenberg-mobile editor used by the WordPress Android and iOS apps.

See related gutenberg-mobile PR: wordpress-mobile/gutenberg-mobile#1934 for integrating the jetpack block into the mobile editor from the jetpack repo.

• This change is only adding .native.js versions of existing files in order to enable utilizing the contact-info block within the mobile gutenberg editor on Android and iOS (using React Native).

Is this a new feature or does it add/remove features to an existing part of Jetpack?

• Internal reference: p9ugOq-Zb-p2

Testing instructions:

• For testing Steps, see Gutenberg-mobile PR: Contact Info jetpack native blocks behind DEV flag wordpress-mobile/gutenberg-mobile#1934

Proposed changelog entry for your changes:

• No change log needed, as the contact info block will initially be hidden from users in the WordPress mobile apps behind a DEV flag.

[jetpackbot]

Thank you for the great PR description!

When this PR is ready for review, please apply the [Status] Needs Review label. If you are an a11n, please have someone from your team review the code if possible. The Jetpack team will also review this PR and merge it to be included in the next Jetpack release.

Scheduled Jetpack release: May 5, 2020.
Scheduled code freeze: April 28, 2020

Generated by 🚫 dangerJS against 91ed9da

[jeherve]

I know this is still a work in progress, but as a React Native newbie I would have a few questions:

• Should we extend our current configuration and set up custom linting rules for all React Native files?
• Are there specific gotchas / things to keep in mind when working on React Native files? Maybe generic recommendations for developing / testing? If so, it may make sense to add documentation for all contributors here maybe.

[cameronvoell]

@jeherve Thanks for adding the labels and for your comment with helpful links.

• Should we extend our current configuration and set up custom linting rules for all React Native files?

So far we have done pretty well sharing linting rules with React JS web files with the gutenberg repository, with only rare exceptions for files with .native.js extentions. So I think we should be good abiding by the current jetpack configuration and only proposing exceptions for .native.js files if they come up.

Are there specific gotchas / things to keep in mind when working on React Native files?

Despite our ongoing efforts to minmimize gotchas, a few that come to mind include no <div> in JSX for .native files (we often use a View component from react-native package instead), and a lack of a complete jsdom implementation for using within React Native.

Maybe generic recommendations for developing / testing? If so, it may make sense to add documentation for all contributors here maybe.

Recommendations for Testing/Developing mobile is a work in progress for gutenberg web core blocks maintainers as well, as we currently still require XCode or Android Studio to be installed. I think to start out we can add instructions to the extensions README for testing mobile blocks by providing some context and pointing to the gutenberg-mobile getting started instructions. I started a branch here for adding mobile instructions https://github.com/Automattic/jetpack/compare/rnmobile/add-generic-testing-developing-readme?expand=1.

@Tug any extra thoughts about my answers above?

[jeherve]

I have one more, maybe stupid, question. :)

We currently do not ship any raw, unbuilt files in Jetpack's stable version. We only ship JavaScript bundles that are built from all the unbuilt files. How will things work with React native files? Will you need to build a new bundle from all the native files, that will be called only from the editor in the mobile app?

[cameronvoell]

We currently do not ship any raw, unbuilt files in Jetpack's stable version. We only ship JavaScript bundles that are built from all the unbuilt files. How will things work with React native files? Will you need to build a new bundle from all the native files, that will be called only from the editor in the mobile app?

@jeherve That is a good question! My first thought is that the current Jetpack stable release process should not need to include any bundled mobile code (.native.js files).

We currently create JavaScript bundles within tagged versions of our Gutenberg-mobile repo that are then saved as a "Gutenberg Mobile Editor Release" that is then included in the WordPress iOS and Android Apps release process.

So our requirements for integrating mobile jetpack code would probably be periodically tagging a snapshot of the jetpack repo as a “Jetpack Blocks Mobile Release” which would correspond to an equivalent "Gutenberg Mobile Editor Release", and "WordPress app release". The jetpack tag would be just to ensure that we can access the raw JavaScript source files snapshot at a specific version if we need to recreate the Jetpack mobile blocks dependency for the respective Gutenberg Mobile and WordPress Mobile app Releases.

One natural question that might arise from what I’ve stated above is, why include the mobile versions of blocks within the jetpack repo if they are not being built as part of the Jetpack stable release process you mentioned? The main reason we would still like mobile code in the jetpack repo is to facilitate keeping the mobile and web versions of blocks in synch, with them utilizing many shared “cross platform components”, working towards a future where web and mobile blocks can use either exactly the same code, or code that is reasonable to be developed and maintained simultaneously.

It's worth noting that working out the details for integrating jetpack blocks into the WordPress Mobile apps via the .org Gutenberg Editor is still a work in progress, so there may be still more learnings to come regarding our release process, and how we can integrate most smoothly with the existing Jetpack release process. I'll ping @Tug here in case he has anything to add to my answer.

[cameronvoell]

@jeherve I have one question for you regarding the codeclimate failed scores. Can you let us know what your current conventions are for improving codeclimate scores before merging? I see a fail in CI with 13 issues to fix, and some of the suggestions look like good advice. But do you always address all of the issues, or is there some convention you follow for acceptable scores, or a discussion you can point me to? Forgive me, I'm not familiar with codeclimate, or CI that goes this extra step past automated tests and lint rules. I do like it though.

[jeherve]

That makes sense, thank you for the explanation.

I have one question for you regarding the codeclimate failed scores. Can you let us know what your current conventions are for improving codeclimate scores before merging?

Our CodeClimate configuration is still a work in progress. We need to tweak things some more so it can provide only useful information. Until then, at times it will give useful advice or give you a good alternative point of view on your code that may inspire you to refactor some things. And at times, its advice will be useless. :)
In short, don't worry too much about it, those CodeClimate issues are definitely not blockers, more like pointers you can choose to ignore. If you'd like you can log in to CodeClimate with your GitHub account and you'll be able to mark those as "wontfix" or "invalid".

[Tug]

Code looks good to me for this first iteration 👍

I think there is still a lot to be done, especially in terms of collaborating with the Jetpack team and aligning our designs.
For instance we might want to share the registerJetpackBlock function and handle "paid blocks" on mobile as well.

@Automattic/jetpack-crew could you maybe have a look at this one?
Please note that as @cameronvoell confirmed, it should not impact the web build in any way (and if it does it should be considered a blocker).
Moreover, this will not land in production in the mobile apps as it will first be hidden behind a feature flag.

Regarding having a good documentation this is something we want to work on in the next few weeks as we make progress on our ".com/.org code separation" project. Given that Jetpack blocks on mobile are still experimental we're not welcoming external contributions at this point as we need to make progress on porting the gutenberg-mobile code to gutenberg first (see Monorepo effort).

[Tug]

@cameronvoell One thing we will need to handle as well is updating our i18n script to include jetpack translations into our (mobile) bundles.

I'm not familiar with how translations are extracted from source files on jetpack but if it works the same way as on gutenberg, then strings inside .native.js files won't be included in jetpack's glotpress project as they won't be part of the web build. I think it's fine for a start though and we can try to restrict the strings we use to the ones already available in jetpack web.

[jeherve]

could you maybe have a look at this one?

Before we merge this, I'd recommend the following:

1. Add native.js to the list of things we should ignore here:
   

   jetpack/tools/build-release-branch.sh

   Lines 58 to 69 in 22eb790

   	echo "/extensions/**/*.css" >> .gitignore
   	echo "/extensions/**/*.gif" >> .gitignore
   	echo "/extensions/**/*.jpeg" >> .gitignore
   	echo "/extensions/**/*.jpg" >> .gitignore
   	echo "/extensions/**/*.js" >> .gitignore
   	echo "/extensions/**/*.json" >> .gitignore
   	echo "/extensions/**/*.jsx" >> .gitignore
   	echo "/extensions/**/*.md" >> .gitignore
   	echo "/extensions/**/*.png" >> .gitignore
   	echo "/extensions/**/*.sass" >> .gitignore
   	echo "/extensions/**/*.scss" >> .gitignore
   	echo "/extensions/**/*.svg" >> .gitignore

   
   

   jetpack/.svnignore

   Lines 66 to 79 in 90f7e1e

   	extensions/**/*.css
   	extensions/**/*.gif
   	extensions/**/*.jpeg
   	extensions/**/*.jpg
   	extensions/**/*.js
   	extensions/**/*.json
   	extensions/**/*.jsx
   	extensions/**/*.md
   	extensions/**/*.png
   	extensions/**/*.sass
   	extensions/**/*.scss
   	extensions/**/*.svg
   	extensions/**/*.snap
   	extensions/.eslintrc.js

2. Add a mention of the files to the main Extensions' readme here:
   

   jetpack/extensions/README.md

   Line 24 in 9d1d1ed

   └── view.scss ← styles loaded on the frontend

   
   Even if this is still a work in progress, it will be useful to mention it there as a12s looking to contribute new blocks may be curious about those files and what to do about them when they look at existing blocks.

Once you're all done, feel free to update the labels on the PR and we'll take a look.

Thank you!

[Tug]

Wouldn't the extensions/**/*.js patterns already match the *.native.js files as well?

About the extensions README, it seems to me that the "Extension Structure" is more or less instructions on how a block or plugin should be organized. It doesn't list extra files such as index.js so I'm not sure we should add a vague .native.js file (which could be any of those file).
We could however add a section on mobile/native support for blocks.
I'm thinking something as simple as:

## Native support

React Native support for Jetpack blocks is being added as part of the WordPress [Android](https://github.com/wordpress-mobile/WordPress-Android) and [iOS](https://github.com/wordpress-mobile/WordPress-iOS) apps. This is still very experimental and subject to change.
A react-native build configuration will attempt to resolve `.native.js` extensions before `.js` ones, making `.native.js` a simple approach to write "cross-platform" code.

WDYT?

[jeherve]

Wouldn't the extensions/**/*.js patterns already match the *.native.js files as well?

Yeah you're right, it may do the trick!

About the extensions README

That little snippet is perfect 👍

[cameronvoell]

I updated the status to "Needs review" since I think we addressed the items from here: #15389 (review)

In short, don't worry too much about it, those CodeClimate issues are definitely not blockers, more like pointers you can choose to ignore. If you'd like you can log in to CodeClimate with your GitHub account and you'll be able to mark those as "wontfix" or "invalid".

I didn't see anything clickable on CodeClimate even after logging in with my Github, so I may be missing some permission to update the status of the issues there (see screenshot):

Also it seems Tug update to the README might have triggered the matticbot to add the "Touches WP.com" label and add the wpcom CI test that is failing. Perhaps we can just remove this label since we're only updating extensions .js files and the README?

[matticbot]

Caution: This PR has changes that must be merged to WordPress.com
Hello cameronvoell! These changes need to be synced to WordPress.com - If you 're an a11n, please commandeer, review, and approve D41967-code before merging this PR. Thank you!
This revision will be updated with each commit to this PR

[jeherve]

r205932-wpcom