[RNMobile] Unify HTML in SocialIcons #24306
Conversation
lukewalczak
added
Mobile App - i.e. Android or iOS
|
Size Change: +88 B (0%) Total Size: 1.16 MB
ℹ️ View Unchanged
|
| return () => { | ||
| updateSocialIconName( false ); | ||
| }; |
There was a problem hiding this comment.
- What happens when the post is saved while the social icon is being edited?
- What happens if I try to Undo right after adding the social icon? (risk of undo trap, "Undo trap": Avoid getting stuck in an editing state #8119)
There was a problem hiding this comment.
- What happens when the post is saved while the social icon is being edited?
Works properly
- What happens if I try to Undo right after adding the social icon? (risk of undo trap, "Undo trap": Avoid getting stuck in an editing state #8119)
Good catch, there is an undo trap :( Do you have any suggestion how to avoid that?
There was a problem hiding this comment.
Basically I need to have full social icon name e.g.: core/social-link-wordpress, so I have one more idea to extend selector getBlockName to return name with service for native platforms:
export function getBlockName( state, clientId ) {
const block = state.blocks.byClientId[ clientId ];
if ( Platform.OS !== 'web' && block?.name === 'core/social-link' ) {
const attributes = state.blocks.attributes[ clientId ];
const { service } = attributes;
return service ? `core/social-link-${ service }` : block.name;
}
return block ? block.name : null;
}
wdyt?
There was a problem hiding this comment.
Good catch, there is an undo trap :( Do you have any suggestion how to avoid that?
In general, it's a strong anti-pattern to trigger an attribute change that isn't a direct consequence of a user interaction. For example: the user types a letter, it updates the content attribute; the user checks "Enable drop cap", that toggles dropCap; etc. These are all clean scenarios that don't affect the ability to undo.
The undo trap issues always arise from automated attribute setting. For example: while a Gallery block is loading with partial attributes (e.g. { images: [ { id: 42 } ] }, it calls getMedia to get more data, and automatically updates the attributes once the request resolves ({ images: [ { id: 42, src: '...', alt: '...' } ] }). The present case with Social Icons is identical, but without even a request.
In all these cases, there's a call to setAttributes that arises not from an event (e.g. user input), but — directly or indirectly — from a state:
- Directly: state is
blockName === 'core/social-link'-> callsetState - Indirectly: state is missing image data -> make REST API request -> call
setState
so I have one more idea to extend selector getBlockName to return name with service for native platforms
Yeah, that might work, as long as there is never a change to attributes (e.g. to touch service). And, naturally, with the understanding that this is a patch until you can confidently let the mobile editor handle variations of core/social-link naturally. :)
…/unify-html-social-icons
…/unify-html-social-icons
Description
According to the discussion that PR reverts changes in parser to unify generate HTML code.
How has this been tested?
Please follow Social Icon test cases:
Social Icons - 1
Social Icons - 2
Screenshots
Checklist: