Support Images about react-rte

[sstur]

Thanks for checking in @angelo-romano. I'll try to get this feature done before the end of October. Hopefully next few days. Even if it's not working perfectly for all edge cases, I think something is better than nothing, and we can improve on it as we go.

[gregziegan]

Done @rgbkrk

[anewusr]

I think we need to lay off the author. He's the only one really advancing this repo, and he's completely overwhelmed with other work. We can't expect him to take the time to really make this library do everything perfectly.

All open source projects of this kind inevitably fall by the wayside so we shouldn't be making unreasonable demands of him. H's just one guy, and the scope of this project is absolutely enormous.

[gregziegan]

I started work on this today following @sstur's steps above. I will make a WIP PR this weekend here's a gif teaser!

Still need to modify the markdown exporter.
Working on resizing and a naive insert now with the button i just added in the toolbar.

[chadoh]

I love how much you've thought this through. Yeah, it's a lot of work! I found a super quick and diiiirty way to implement image uploading in my app, for now, so don't rush on my behalf! But I look forward to using react-rte someday instead!

[EdwardTrecxs]

any updates on this? Know you're all busy with a 1000 things. It's been quiet for some time now, so I thought I ask if this is still in progress :)

[sstur]

Thanks @rgbkrk! I totally plan to implememnt inline images very soon. There's a TODO list in the README, it's just so hard to prioritize what to do next since there's so much that needs to be done before this is really usable in people's projects.

For the moment, I'm focusing on writing tests, then I will probably fix CSS and then add images.

As for the Markdown parser, the current one is based on chjj/marked but it has been modified a lot (to parse to a synthetic DOM rather than a string).

The more tests I write, the more markdown parsing bugs I'm noticing, so I will probably move to wooorm/remark very soon.

I'll find a better way to communicate the current TODO and what's being worked on.

Thanks!

[simpixelated]

I'll find a better way to communicate the current TODO and what's being worked on.

@sstur issues with an in-progress label/assignee work really well! Plus you can link to them from the readme. Thanks for making this editor btw, it's really awesome.

[rgbkrk]

@wooorm is good peoples

[chadoh]

Hey @sstur! I just started digging into DraftJS today, and got to the part where I had to persist data to the server and was like

– it looks like react-rte will solve the problem! Awesome! Thanks!

For a project I'm working on right now, I've been asked to get inline images working by the end of this week. I'm considering digging into this library and implementing some version of images—it probably wouldn't be super polished because of time constraints, but it'd be a start!

I wanted to check if you've already broken ground on this. No point in duplicating efforts.

[sstur]

Hi @chadoh! I'm excited to get inline images working also. I have done some planning around this but have not started yet.

My plan is this:

• Treat inline images as a single character with an entity attached to it (I will probably choose character ~ because it's by far the best ascii character). The styling/decoration for the character will need to wrap it in a span, set the text color to transparent, add a background image and set a width and height. So it will feel like an image. The reason for this plan is that selection should treat it as one text character and that will work well with the data model.
• Data about the image will be attached to the entity (src, width, height, originalWidth, originalHeight, alt, etc)
• There will need to be a UI for adding an image. Initially this can be as simple as the current link button.
• Initially, we will just allow adding an image by entering it's src URL.
• Some code will need to be in place to convert the image entity to/from HTML and Markdown (we will not allow an image inside inline styles like <strong> or <em>)
• There will need to be a way to select, move, resize and delete the image. We will listen for selection change and if the image character is the only range selected, we will show some draggable resize handles (this part alone is a full day's work I think)
• There will need to be a way to insert an image from your filesystem by dragging or clicking a button to open a file select dialog. This shouldn't be too hard.
• There should be hooks to listen for images being dropped/selected and optionally initiate an upload to a server somewhere. Possibly showing a progress overlay on the image while it is uploading. And a way to swap out the image src when/if the upload completes. This alone is almost enough to justify a separate module.
• There will need to be a UI dialog or popover to add/change options about the image (float left/right, vertical align, alt, title, link, etc)

This is quite a task which is why I've been putting it off, but if we could tackle just a few items from this list that would be a huge win. I'm totally open to pull requests. If not I'll try to get to this soon (but can't promise anything by the end of the week).

[rgbkrk]

Super slick!

I'm assuming you would aim towards

![](http://kindersay.com/files/images/goat.png)

for the markdown export eventually?

[rgbkrk]

SO GOOD

[gregziegan]

Working on this now

There will need to be a way to select, move, resize and delete the image. We will listen for selection change and if the image character is the only range selected, we will show some draggable resize handles (this part alone is a full day's work I think)

Someone else has done resize and dragging work here
https://github.com/bkniffler/draft-wysiwyg/

But images are treated as custom block components and the resizing looks ugly for now. I'm currently reading the code to see if it should be built upon from his components... but I prefer this single inline character approach.

[sstur]

Wow, @thebritican, this is great work!

[gregziegan]

Thanks! And there's still some bugs but...

I need to clean up the code tomorrow but I'll make this PR soon.

You'll probably have minor PRs to review for draft-js-utils, draft-js-export-html, and draft-js-export-markdown;

[sstur]

So awesome!

[gregziegan]

So a small issue I'm currently stuck on with this approach: @sstur

Since the image is only a background image in the editor, selection only shows on the transparent ~.

There will need to be a way to select, move, resize and delete the image. We will listen for selection change and if the image character is the only range selected, we will show some draggable resize handles (this part alone is a full day's work I think)

This is actually all done, but it's quite weird to see only a transparent character selected when moving the image. I believe I can fake the selection by applying more CSS to the span, but I'm not sure how to make the browser actually select it natively.

Here's a playground to see what I mean (try selecting the goat)
https://codepen.io/thebritican/pen/wGywmM

Let me know what you think is a good way forward on this!

[sstur]

Ahh, I see. TBH, this is all an untested plan : )

Few things come to mind.

The first thing we probably want to do is add an on-click on the span to select it when clicked (this emulates the default browser behavior of an <img> in a contentEditable).

Then use CSS ::selection (which you're doing) to remove the default selection style. Then add different styles like a border/outline/box-shadow to the span.

This whole thing is a little hacky. I mean using a <span> in place of an <img>. But the reason I suggested it is because DraftJS wants us to render the exact amount of text characters in an entity that we've got in the state. Mostly for selection reasons.

But I'm beginning to wonder what will happen if we render an <img> after all. I know it's outside the scope of what DraftJS recommends but maybe it will work. The crappy part is testing it in all the browsers but I guess we have to do that either way.

If you can share your code, I can help you figure this out. I can add you to a private GH repo if you like.

[gregziegan]

Ya i'll make a WIP PR today. I just had to do a bunch of build changes when i couldn't figure out how to get it running in issue #31 . No need for closed source!

[sstur]

Thanks @thebritican! I have been playing with that codepen and have a few thoughts.

First off, .image-span::selected should be .image-span::selection. From playing with it, ::selection is kinda strange, it acts like a psuedo element that sits behind or wraps our text so styling it doesn't affect the span with the background image (meaning we can't add border/outline using this selector). We will probably need to manually add/remove a .selected class name.

I think we should render an invisible character (maybe a zero-width space \u200B or \uFEFF) instead of a "~" so we don't have to set the color to transparent. We can still keep whatever character we like in the ContentState. Actually rendering the ~ was helpful for debugging, but besides that it was maybe a poor suggestion from my part.

Also, we need to get rid of the nested <span>s. It messes with cursor position and selection.

I've also played with text-align: right to get the blinking cursor where we might expect it (directly after the image). Conveniently, the cursor will jump there when we click the image.

I'm thinking maybe we should listen for selection change and when the cursor is directly after the image we add a class to the span. We can style it with a dashed outline or something similar to how we will do when it is clicked/selected.

Updated Pen: http://codepen.io/sstur/pen/ONQRvB

[gregziegan]

👍 I was thinking of the invisible space character myself. This still feels a bit hacky but I tried using a standard img tag and was not happy with the results. And I agree that ::selection is not the path to continue on.

The nested spans are a product of me wrapping the ImageSpan with a resize-able higher order component. I think if we set contentEditable={false} on the relevant components, the cursor selection should work properly regardless of nesting inline elements.

Things I'll do on my PR now:

• correctly align cursor with text-align: right
• toggle a selected css class for when the cursor is immediately next to image

My strategy for selecting the image span and moving it within the editor is to utilize react-draggable like I currently am via the Resizable component (currently a third party lib). I will see if that has limitations inside the editor, but let me know if you have any thoughts on the matter!

[sstur]

Small note, I'd suggest differentiating between the class name for selected (this will be when there is a non-collapsed selection that contains the image) and has-cursor where the cursor is placed after.

As for the dragging of the image, if we use native selection, will the browser not handle moving for us?

I can make a Resizable purely using outline and absolutely-positioned empty elements (for drag handles) without needing to nest elements (have done this before). I'll tackle this after we get the main issues figured out. Also, I noticed in your GIF, we need to lock the selection on drag-start to prevent unwanted text selection.

[gregziegan]

Moving with the native selection does work fine via the browser, but, like you saw in the GIF, that was only possible when I selected the transparent ~ character. If it's an invisible space character, would clicking and moving the span properly move the desired character? I understand making the selection look valid with CSS on the span w/ the background image, just not how clicking and dragging it will sync with the space character.

I'll just begin the checklist I posted above with (distinguishing selected and has-cursor) and perhaps my questions will be answered for me!

[sstur]

If it's an invisible space character, would clicking and moving the span properly move the desired character?

I think it will. If we adjust the selection on click/mousedown. It will be just like moving a selection of text (because it is text under the hood). Just a matter of making sure the text is actually selected without the user having to do anything.

[gregziegan]

Hey sorry i've been quiet on this. I've almost got the selection working properly. I'll be plugging away at this soon. I was originally working in another repo until you resolved the build issue. That's why you're not seeing commits on the WIP PR.

I should have that PR updated with selection support by Friday!

P.S. I also refactored the code to look more like LinkDecorator. So there is an ImageDecorator now.

[sstur]

No worries. I've been busy too. I appreciate you working on this. I did get all your dependent PR's merged to those other repos. That should all be on npm now. Let me know if I'm incorrect.

[gregziegan]

Finally got back to this. Faking selection is almost ready. However, there is no way to detect the current browser/OS selection color. So, does anyone have a fair strategy on how to set the ImageSpan's background color on selection?

Currently, i'm just forcing the editor's selection color with ::selection and then using that same color as the image span's background-color.

[gregziegan]

Faking selection is a bigger challenge than I originally thought. Since image spans are just decorated entities, they have no access to the editorState, and therefore the only way to change their state is via Entity.mergeData() or Entity.replaceData().

While this should work rather immediately to update the entities, their decorated components are not re-rendered since I am using entity.getData() in the render() method (to get width, height, src, selected, etc). Since there is no way to affect the props of these decorated components with editor state changes, and entity data changes are not part of their props, I need a different approach.

My currently "plan" is to have a SELECTED_IMAGE as well, and swap out entities during selection state changes. This is very involved, though, and I'm becoming less convinced of this being the way forward. If I'm missing something simple, let me know!

There is talk facebookarchive/draft-js#185 to get entity data moved into the ContentState, but upon a quick ready I'm not convinced that would make this specific problem easier.

[sstur]

I think I understood most of what you're saying. I do think getting entity data into ContentState is going to happen and that should help anyone who is doing advanced stuff with entities like we are. If you can point me to your working branch, I might take a stab at this also and see the issues I run into.

[gregziegan]

The PR #33 i referenced above is my working branch. @sstur So feel free to work from there. It currently changes the background color on selection but does not toggle off. And it only updates the selection when the decorated components are re-rendered (usually losing focus with the editor). This is because, as I mentioned above, entity data is not part of the decorated component's props.

[sstur]

Cool. I've rebased that onto master (after I updated master with a few things) and I started the branch image-support which corresponds with #40. I'll try to help solve some of the issues you've run into.

[sstur]

Just so you know, I've been continuing work on this with @RaoHai on the branch mentioned above.

[sstur]

I think we will run into an issue when trying to implement click to drag image to another part of the text. The normal behavior when you click on text and drag is to select text. The normal behavior when you click on a selection and move it is to do what we want. So we need the image to be the selected text before you click and drag. I will try selecting it on mousedown but I suspect that is too late.

[oeddyo]

Hi guys,

May I ask when are we planning to support image? Not really being pushy, but we are simply evaluating timeline of our project

Apprciate this great project! Thanks

[sstur]

Hi @oeddyo. I have been too busy to get this feature finished, but I will try to get it across the finish line soon. Sorry I don't have a solid timeline, but please feel free to bump this again if you don't hear anything! Thanks for using react-rte.

[oeddyo]

thanks @sstur Bumping :)

Sincerely Appreciate the great project and your hard work

[angelo-romano]

hello, wanted to ask if there's any news regarding the image support. Thank you for your effort and hard work, by the way!

[leejunkit]

Hello :) Just wanted to politely bump images support. Thank you for creating this!

[sstur]

Haha, thanks @anewusr. I appreciate the support.

I also hear you all about getting this feature done. It's been promised for a while. Stay patient and we'll keep trying!

[avkozlov4]

I see commit with images support. Can i somehow install it like npm module?

[bherila]

You can try it out! Simply install the latest version from npm and let us know if you have any issues.

[The-Code-Monkey]

@sstur does this exist yet or is this still in development

[sabina-kv]

Hi. I was wondering if there is any props to take the image option away?

[bigmac44]

Hi. I was wondering if there is any props to take the image option away?

I've had luck using drafts-filters to strip out images that are pasted in. https://github.com/thibaudcolas/draftjs-filters