Draft-js: Media Wrapper

[tasti]

Follow up on the discussion in https://github.com/facebook/draft-js/pull/67 (cc: @nikgraf).

I think as a baseline implementation, there should be some sort of MediaWrapper to take care of contentEditable and data-offset-key.

Along with the MediaWrapper, I discussed with @hellendag ways to support selection/highlighting media blocks. For example, clicking on a media block would have an overlay above it showing that it's selected. Or, if a media block is between text and you use the arrow key to move towards it, then it would gain selection.

In terms of how media is passed in, I can't really see any use-cases of blockRendererFn for a block type that isn't media. Maybe Custom Block Components should be handled at the Entity level rather than at the Block level.

[hellendag]

Maybe we should be calling the media block type something like atomic instead.

[oyeanuj]

In terms of how media is passed in, I can't really see any use-cases of blockRendererFn for a block type that isn't media. Maybe Custom Block Components should be handled at the Entity level rather than at the Block level.

@tasti What about rich embeds or link previews? Maybe they would behave the same way as media..

[tasti]

@oyeanuj Yeah, those seem like they would behave as media/atomic.

If you look at DraftBlockType (https://github.com/facebook/draft-js/blob/master/src/model/constants/DraftBlockType.js), media is pretty much a fallback for anything that isn't built-in. So always checking if (block.getType() === 'media') { ... } seems redundant in blockRendererFn if that's always the case.

[nikgraf]

@tasti what if someone wants to have something else than media? I'm working on stickers implementation that would have type 'sticker'. Could be a subtype of atomic/media, but should have custom component.

[hellendag]

The component can be anything you choose, but the block type could be the same. You could use an entity type to differentiate.

[nikgraf]

Ahh, right. Makes sense :+1:

[tasti]

I mean should the blockRendererFn API take in an Entity instead and then check if (entity.getType() === 'sticker') { ... }?

[hellendag]

I mean should the blockRendererFn API take in an Entity instead and then check if (entity.getType() === 'sticker') { ... }?

Right now the API is a little awkward, but I'm not sure we can always assume an entity. The custom block component will receive the complete ContentBlock, from which you can retrieve the entity instance and make type comparisons there.

I have thought that it probably makes sense to have an EntityBlock (similar to or sibling of ContentBlock) that doesn't bother with text, and is represented by an atomic entity. The tricky thing then is to refactor the modifiers and transaction functions to be aware of these blocks. It's doable, though.

I can't really see any use-cases of blockRendererFn for a block type that isn't media

I don't think we should restrict it, at least not yet. For instance, I may want to render a text block with some floated 'X' control to remove the entire block. A custom block would be the way to do this, even though the block type might be unstyled -- my blockRendererFn may branch on some value other than type.

[angelf]

I don't think we should restrict it, at least not yet. For instance, I may want to render a text block with some floated 'X' control to remove the entire block. A custom block would be the way to do this, even though the block type might be unstyled -- my blockRendererFn may branch on some value other than type.

I'm doing exactly this. I've got a WrappedBlock that contains a DraftEditorBlock. I use WrappedBlock to create custom UI around the block.

[tasti]

Good to know these use-cases exist :+1:

[thesunny]

@angelf May I ask how you created the WrappedBlock? Doesn't look like DraftEditorBlock is publicly exposed.

[hellendag]

Yeah, we need to expose that.

[ianstormtaylor]

+1 to the idea of AtomicBlock. Would it then be possible to do as @angelf is doing and instead of using entity information inside the block to wrap the AtomicBlock instead? Reaching a pseudo-entity seems a bit weird, vs. inheriting and adding custom functionality to the block itself instead. (But I might be misunderstanding!)

[hellendag]

media has been renamed to atomic and editability can now be set via the custom block configuration, so we effectively have wrapper support.

Enabling block-level selection for non-editable blocks is very much still worthwhile, but perhaps belongs as a separate issue and discussion. :)

[apfelfabrik]

Enabling block-level selection for non-editable blocks is very much still worthwhile, but perhaps belongs as a separate issue and discussion. :) (@hellendag)

Was that discussion continued somewhere? I'm very interested in that feature!