Downshift: Support contentEditable

[maikelrobier]

• downshift version: 1.29.1

What you did:
I tried using Downshift using a contenteditable div element instead of an input element.

What happened:
It doesn't show the autocomplete list. (Expected, since there is getInputProps but not something like getContentEditableProps)

Reproduction repository:
https://codesandbox.io/s/67y5xk23r

Problem description:
I'd love to use Downshift in a scenario where I need to use contenteditable, but getInputProps won't work since is probably meant to be used for input elements only as the name suggests.

Suggested solution:
Add getContentEditableProps function (or something similar) to the render function props. It would return props/event handlers specific to <div contentEditable /> so it can be used with Downshift.

[kentcdodds]

Hi @maikelrobier!

This is a good question. I think it'd be good to support this. I've given it a start here: https://codesandbox.io/s/mqkmq2zx8p

The basic idea is that you wrap downshift with your own component that manages including getContentEditableProps. It works pretty well actually (though we'll probably want to expose a few things to make it easier).

You shouldn't need changes in downshift to support this, but if it's not a lot of work/code, then I may accept a PR for adding it directly in the library. Seems like a reasonable use case especially when I consider use cases for Draft.js :)

Give it some work and let us know when you've got something you're happy with and we can discuss what it would take to include it in the library directly.

[maikelrobier]

Thanks @kentcdodds for the quick response! Your idea sounds good. I'm playing with it right now to see how it works for my use case.

[kentcdodds]

Any thoughts here? I'm preparing [email protected] and it'd be cool to be able to say we support content editable (even if it's just a simple example, or another lib built on top of downshift). What do you think?

[maikelrobier]

Hi. I'm glad to hear there is a new release of downshift coming soon. About my original issue, I had to take a different path (using Draft.js) because for my specific purpose using contentEditable directly was too painful. Then I found a small package on top of Draft.js that helped me with the autocomplete feature, so, because of my timing restrictions I didn't get too far on this, but your example made sense to me, I think it just needed a way of handling the key events and moving the selected index.

Exploring this solution I learned that there are some problems with keeping contentEditable state in react, especially with the cursor position, so I tried using react-contenteditable which solves some of those problems, but it has to be passed different props (html, onChange, it will ignore, dangerouslySetInnerHTML or onInput), but finally I ended up using Draft.js. It's a shame I didn' have time to experiment using downshift with Draft.js although it was a very attractive idea, but the way to make it work would be very different to the contentEditable version or the react-contenteditable version. So my point is that maybe, to solve more practical use cases, it worths considering a more abstract approach that attempts to support any custom input-like component (Draft.js would be super cool), rather than solving specifically for contentEditable. Or maybe it would be better to have separate libraries to support each one those 3. Just random thoughts I wanted to share :)

[kentcdodds]

Technically we already support contentEditable, the user just has to do all the work. An example integration with Draft.js would be very cool, but I don't think we'll build in first class support.

I'm glad you got your stuff working. Best of luck to you!

[matt-erhart]

Here's some code I used to learn how to combine downshift and slate (like draftjs). It's a crappy figure stuff out script, but some might find it helpful: https://codesandbox.io/s/1qj5918w5l