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

Port the core/code block to be used by the ReactNative mobile GB app #5816

Merged
merged 42 commits into from May 4, 2018

Conversation

hypest
Copy link
Contributor

@hypest hypest commented Mar 27, 2018

Description

This PR introduces the minimal set of changes to make the core/code block ready to be consumed by a ReactNative app, in the road to implement a "native" mobile GB editing experience as per the Make post.

Among the goals is to eventually be able to introduce patterns for how to share code between GB the webapp and GB the native mobile app. Please, feel free to open PRs against this one with proposals towards that goal.

TODO before lifting the "In progress" label:

  • Make sure the (web) GB build and webapp work normally
  • Factorize the RN platform dependent files to minimize code duplication between Android and iOS
  • Have a proposal ready for how to change the core/code block definition so its high level definition is shared among the 3 platforms (web, Android, iOS)
    For the time being, the .native.js variants of key files (index.js among which is the most important ones) will serve as the method we provide compatibility with an RN app. The goal is still to come up with a "common language" down the road but we need to port more code before patterns on what the common language is emerge.

Types of changes

  • What types of changes does your code introduce?

Introduces .native.js variants of various key files. Those are picked up instead of the corresponding .js files when the code is imported in an RN build. The regular Gutenberg build just ignores the .native.js files.

The specialized index.native.js files play a key role: They are importing only the submodules needed by the RN implementation. These submodules will gradually be ported and only where appropriate.

  • New feature (non-breaking change which adds functionality)

Ports the core/code block into a RN compatible component.

  • Breaking change (fix or feature that would cause existing functionality to not work as expected)

None.

Checklist:

* CSS related imports are suppressed
* classnames are left in only to minimize diff among the files but do not play a role, nor style the elements
So far, that's the only way I found to have the android-specific jest tests succeed.
@hypest hypest added the [Status] In Progress Tracking issues with work in progress label Mar 27, 2018
@hypest hypest requested a review from gziolo March 27, 2018 12:32
@hypest
Copy link
Contributor Author

hypest commented Mar 27, 2018

👋 @gziolo , please feel free to add more reviewers to this PR if you think it's good they keep an open eye to this PR. Thanks!

👋@maxme , feel free to add more TODO items to the list. Thanks!

@aduth
Copy link
Member

aduth commented Mar 27, 2018

Have a proposal ready for how to change the core/code block definition so it's high level definition is shared among the 3 platforms (web, Android, iOS)

May also tie into #2751 (registration of said high-level definition on the server).

@gziolo
Copy link
Member

gziolo commented Mar 27, 2018

Have a proposal ready for how to change the core/code block definition so it's high level definition is shared among the 3 platforms (web, Android, iOS)

May also tie into #2751 (registration of said high-level definition on the server).

In general, we are looking into having a way to define all blocks on the server (minus JS specific bits like edit, save or other function based properties). See #5802. At some point, we will have to wrap it with REST API endpoint to make it easy to consume by the platforms that don't use HTML to expose data from the server. At the moment those definitions are serialized as JSON and assigned to the global JS variable _wpBlocks.

@gziolo gziolo added [Type] Technical Prototype Offers a technical exploration into an idea as an example of what's possible [Feature] Extensibility The ability to extend blocks or the editing experience labels Mar 27, 2018
@gziolo gziolo added this to To do in Extensibility via automation Mar 27, 2018
@gziolo gziolo added the Mobile Web Viewport sizes for mobile and tablet devices label Mar 27, 2018
@gziolo gziolo moved this from To do to In progress in Extensibility Mar 27, 2018
@hypest
Copy link
Contributor Author

hypest commented Mar 28, 2018

Collapsed (with 8ee1a4e) platform specific code into .native.js files instead of individual (android, ios) ones. Thanks @gziolo for the tip!

@hypest
Copy link
Contributor Author

hypest commented Mar 29, 2018

Update:

  • Merged from master and fixed any conflict
  • Lifted the #pragma override of the JSX Babel transformer plugin
  • Added the mobile native source files (.native.js and friends) to the eslint ignore list. Those files are currently processed via Flow and Prettier on the RN project side.
  • Tests now pass

@hypest hypest removed the [Status] In Progress Tracking issues with work in progress label Apr 30, 2018
@hypest
Copy link
Contributor Author

hypest commented Apr 30, 2018

After some discussion with @gziolo I've :

  • cleaned up the "todo-looking" comments
  • minimized the PR even further
  • changed the target branch back to master
  • updated from master and fixed any incompatibilities (e.g. due to file structure change)
  • updated the PR description
  • lifted the [Status] In Progress label.

@hypest hypest changed the title WIP: Port the core/code block to be used by the ReactNative mobile GB app Port the core/code block to be used by the ReactNative mobile GB app Apr 30, 2018
Copy link
Member

@gziolo gziolo left a comment

Choose a reason for hiding this comment

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

I left some minor comments. In general, I'm okey with the proposed solution, because everything happens in RN specific files. I think it would be a good idea to move all edit components to their own files anyway. We can help with that if others agree that it is a way to move forward.

@mtias, @aduth, @youknowriad any thoughts?

*/
import { PlainText } from '../../blocks';

export function edit( { attributes, setAttributes, style } ) {
Copy link
Member

Choose a reason for hiding this comment

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

It can be exported as export default function ....

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Makes sense, done with 0edfb18.

} from '@wordpress/blocks';

/**
* Internal dependencies
*/
import './editor.scss';
import { edit } from './edit'; // import the specialized `edit` function. Is is different between the web and native mobile.
Copy link
Member

Choose a reason for hiding this comment

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

This comment can be removed as we should probably do the same for all edit implementations :)

edit can be exported as default to have:

import edit from './edit';

// and later
{ 
     ...
    edit,
    ...
}

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The comment can be considered trivial if one reads the PR and has an understanding of the .native.js pattern. I had added it to help people pick up the pattern but, i'm perfectly fine with removing it 👍 . Done with 9b68ba3.


export function edit( { attributes, setAttributes, style } ) {
return (
<View>
Copy link
Member

Choose a reason for hiding this comment

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

Shouldn't be style applied to View rather than PlainText to mirror web implementation?

Copy link
Contributor Author

@hypest hypest Apr 30, 2018

Choose a reason for hiding this comment

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

Yes and no. Unfortunately, styling in RN is not cascading by default and we will need more work on establishing a pattern on how to pass and style the blocks/components/containers.

In this particular case for example, the style includes the fontFamily property which is supported by the PlaintText component (because it's a TextInput under the hood) but not by the View component.

All in all, styling should be considered alpha at this stage as well and i'd suggest we work on it in a different PR, if that's OK with you too @gziolo . I'll update the PR description to include some relative info.

Copy link
Member

Choose a reason for hiding this comment

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

That would be awesome to have it documented in the code next to RN version of the edit component.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done with 0377c73.

@@ -0,0 +1,9 @@
.blocks-plain-text {
Copy link
Member

Choose a reason for hiding this comment

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

Did you check if it isn't included in web build by accident?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not extensively, I didn't. What I only tested was modifying values in the style file and see if GB-web picks those up, visually. Tried out adding a background-color for example. Any practical way to test it out more thoroughly perhaps?

Copy link
Member

Choose a reason for hiding this comment

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

I can test it myself before merging, but I think if you put background-color: pink in the RN version, it shouldn't get applied in the web version. That's all we need to ensure :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's grand, that was the test I did and it succeeded (color wasn't picked up) so, feel free to test is your side as well, thanks!

@hypest
Copy link
Contributor Author

hypest commented Apr 30, 2018

Thanks for the review @gziolo , ready for another pass! FYI, I made a minor change in the meantime (5c93331).

Copy link
Member

@gziolo gziolo left a comment

Choose a reason for hiding this comment

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

I tested web version and it still works properly. I would defer the final decision to @aduth and @youknowriad, but speaking myself it's good to go.

@gziolo
Copy link
Member

gziolo commented May 4, 2018

Let's get it and iterate with further PRs.

@gziolo gziolo merged commit 881617f into master May 4, 2018
Extensibility automation moved this from In progress to Done May 4, 2018
@gziolo gziolo deleted the rnmobile/port-code-block branch May 4, 2018 07:09
@gziolo gziolo added this to the 2.9 milestone May 4, 2018
@mtias
Copy link
Member

mtias commented May 4, 2018

Good to see this happening :)

@gziolo gziolo added Mobile App - i.e. Android or iOS Native mobile impl of the block editor. (Note: used in scripts, ping mobile folks to change) and removed Mobile Web Viewport sizes for mobile and tablet devices labels Oct 10, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Extensibility The ability to extend blocks or the editing experience Mobile App - i.e. Android or iOS Native mobile impl of the block editor. (Note: used in scripts, ping mobile folks to change) [Type] Technical Prototype Offers a technical exploration into an idea as an example of what's possible
Projects
No open projects
Extensibility
  
Done
Development

Successfully merging this pull request may close these issues.

None yet

5 participants