Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
[RNMobile] update mobile to not use ListEdit #17070
This update is in response to changes made on the web side in #15113
Sharing Logic Between Web and Mobile
I pushed a new commit moving away from ^that approach. Instead, I am now separating the logic by extracting the web-only part of the component to a separate
A similar approach would be to just give mobile an empty component for all of the components used on web but not on mobile (fedbdc8 shows what this PR would look like with that approach). The disadvantage of this imo is that it makes it less obvious to determine after-the-fact where the behavior of mobile and web differs as compared to having the single
How has this been tested?
Without the changes in this PR, attempting to bundle gutenberg's
Tested that this PR causes no changes on the web side. In particular, verified that the changes added in #15113 work as they did before with ordered lists:
etoledom left a comment •
I do prefer this approach too.
This solves the building error and seems to work fine on Mobile
I wonder what would happen when we load a list block using these new props on mobile.
Well that is concerning! I just double-checked this and everything seems to be working fine for me when I run a local dev server. I checked that I was actually observing the changes from my branch on my local dev server by observing that running the server off of my branch shows the new options if no changes are made, but if I made changes that broke the new options then those options did not appear for me (in other words, my breaking the feature during development was most-definitely just a part of my carefully-considered and oh-so-thorough testing strategy, it definitely wasn't that I just messed something up
If you're still not seeing the additional options on web, let's sync up and figure out what we're doing differently.
etoledom left a comment
Thank you for the update, great job
I managed to run locally gutenberg-web successfully now, and I noticed something that I thought might happen:
So, gutenberg-mobile loads the block properly, except that it doesn't take into account the new parameters. This is expected since we haven't implemented that functionality on Aztec.
The problem is that if we modify the list block in any way, the new settings will be lost and will override what was done on web.
This is probably difficult to fix and will have us implementing that functionality, so I think the best would be to merge this and solve the build error, and to create a ticket with this issue to keep it in mind.
Thank you again @mchowning for tacking this!
Good catch @etoledom ! I'll make the ticket.
UPDATE: Created gutenberg-mobile#1304