Skip to content

[RNMobile] Added layoutGridBlock enabling capabilities flag to mobile gutenberg bridge #31777

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.

Sign up for GitHub

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

Closed
enejb wants to merge 1 commit into from
Closed

[RNMobile] Added layoutGridBlock enabling capabilities flag to mobile gutenberg bridge #31777

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions ...id/react-native-bridge/src/main/java/org/wordpress/mobile/WPAndroidGlue/GutenbergProps.kt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,6 +4,7 @@ import android.os.Bundle

data class GutenbergProps @JvmOverloads constructor(
val enableContactInfoBlock: Boolean,
val enableLayoutGridBlock: Boolean,
val enableMediaFilesCollectionBlocks: Boolean,
val enableMentions: Boolean,
val enableXPosts: Boolean,
Expand Down Expand Up @@ -41,6 +42,7 @@ data class GutenbergProps @JvmOverloads constructor(
putBoolean(PROP_CAPABILITIES_MENTIONS, enableMentions)
putBoolean(PROP_CAPABILITIES_XPOSTS, enableXPosts)
putBoolean(PROP_CAPABILITIES_CONTACT_INFO_BLOCK, enableContactInfoBlock)
putBoolean(PROP_CAPABILITIES_LAYOUT_GRID_BLOCK, enableLayoutGridBlock)
putBoolean(PROP_CAPABILITIES_MEDIAFILES_COLLECTION_BLOCK, enableMediaFilesCollectionBlocks)
putBoolean(PROP_CAPABILITIES_UNSUPPORTED_BLOCK_EDITOR, enableUnsupportedBlockEditor)
putBoolean(PROP_CAPABILITIES_CAN_ENABLE_UNSUPPORTED_BLOCK_EDITOR, canEnableUnsupportedBlockEditor)
Expand Down Expand Up @@ -68,6 +70,7 @@ data class GutenbergProps @JvmOverloads constructor(

const val PROP_CAPABILITIES = "capabilities"
const val PROP_CAPABILITIES_CONTACT_INFO_BLOCK = "contactInfoBlock"
const val PROP_CAPABILITIES_LAYOUT_GRID_BLOCK = "layoutGridBlock"
const val PROP_CAPABILITIES_MEDIAFILES_COLLECTION_BLOCK = "mediaFilesCollectionBlock"
const val PROP_CAPABILITIES_MENTIONS = "mentions"
const val PROP_CAPABILITIES_XPOSTS = "xposts"
Expand Down
1 change: 1 addition & 0 deletions packages/react-native-bridge/ios/GutenbergBridgeDelegate.swift
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -17,6 +17,7 @@ public struct MediaInfo: Encodable {
/// Definition of capabilities to enable in the Block Editor
public enum Capabilities: String {
case contactInfoBlock
case layoutGridBlock
case mediaFilesCollectionBlock
Comment on lines 19 to 21
Copy link
Contributor

@chipsnyder chipsnyder May 21, 2021

Choose a reason for hiding this comment

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

@mchowning @hypest I'd be curious to get your thoughts on these three capabilities (contactInfoBlock, mediaFilesCollectionBlock, and layoutGridBlock). This becomes a not so secretive passthrough for jetpack content. I wonder if we should make this more universal by changing this capability to something like additionalSupportedBlocks that contains an array of the block names the client wants to support.

audioBlock might be a good candidate to include in this as well. WDYT?

To be clear @enejb is following the established pattern here and incorporating my change suggestion would increase the scope of this PR so I'm happy to take that on under a different PR. I wanted to see if there was any existing context or if it's just the evolution of the architecture.

Copy link
Contributor

@mchowning mchowning May 21, 2021

Choose a reason for hiding this comment

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

I wonder if we should make this more universal by changing this capability to something like additionalSupportedBlocks that contains an array of the block names the client wants to support.

I agree. I think it's fine for this PR, but this is something we should fix.

Copy link
Contributor

@mzorz mzorz May 21, 2021

Choose a reason for hiding this comment

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

Agreed as well. I think it's easier to see this when you have enough occurrences that it starts to become a pattern. That's the right time to make an abstraction with the characteristics that are common to all 👍

Copy link
Contributor

@hypest hypest May 24, 2021

Choose a reason for hiding this comment

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

+1 to what the fine folks above be already said, for generalizing/abstracting the "block offerability" flags.

case mentions
case xposts
Expand Down