I'm trying to implement something like Twitter's tweet box, specifically:
- Automatically highlights text in a red background when the overall length exceeds 140 characters.
- Automatically highlights links, mentions, and hashtags in blue.
These should happen automatically aka when a user types.
By the semantic markup I'm seeing on Twitter, it looks like they're using a contentEditable
div. And the DOM inside is modified whenever a mention/hashtag/link is detected, or when the length is exceeded over 140 characters:
<div aria-labelledby="tweet-box-mini-home-profile-label" id="tweet-box-mini-home-profile" class="tweet-box rich-editor notie" contenteditable="true" spellcheck="true" role="textbox" aria-multiline="true" dir="ltr" aria-autocomplete="list" aria-expanded="false" aria-owns="typeahead-dropdown-6">
<div>hello world <a class="twitter-atreply pretty-link" href="/testMention" role="presentation"><s>@</s>testMention</a> text <a href="/search?q=%23helloWorld" class="twitter-hashtag pretty-link" role="presentation"><s>#</s>helloWorld</a> text <a href="http://www.google.com" class="twitter-timeline-link" role="presentation">http://www.google.com</a> text text text text text text text text text text text text text text <em>overflow red text here</em>
</div>
</div>
What I have done so far
Currently, I'm using a contentEditable field. It triggers a function onChange/onInput
that parses the text. Check if it has a username/link/hashtag via regexr and replace them with the respective tags (I'm just using a simple <i>
tag to enclose username and hashtag for now).
The problem I'm having is that because I'm changing/modifying the DOM of the contentEditable, the caret cursor position becomes lost.
I looked at this thread Persisting the changes of range objects after selection in HTML and it works fine only if the DOM isn't changed (which it is in my case, surrounding tags/hashtags with <i>
tags, links with <a>
tags, and overflow with <b>
tags.
Fiddle: http://jsfiddle.net/4Lsqjkjb/
Does anyone have any alternative solutions/approaches on how to tackle this problem? Maybe I shouldn't use contentEditable
? Or some way that doesn't directly modify the DOM of the contentEditable
field so the caret position is maintained? Any help would be appreciated! I tried playing around with window.getSelection()
and saving it before DOM change, but it always seem to reset after DOM changes are applied.
This is not a direct answer with source code building the part of your application to your spec.
This is really not an easy thing to do.
You're right - the way to solving this problem is to use a
contenteditable="true"
container. But I'm afraid that from there it gets much much more complicated.Enter DraftJS - A javascript solution to rich-text editing which does most of the heavy lifting for you.
Both of my solutions below require the use of both React and DraftJS
The Plug-&-Play Solution:
The React + DraftJS + Someone Else's "Plugin" solution is already here. You can check out draft-js-plugins.com. And here's the Github source code.
Personally, I wouldn't go this way. I would rather study their GitHub source code and implement my own DraftJS
entities
. Because I think that React-JS-Plugins feels a little bit clunky and overweight for just Links and Mentions. Plus, where are you "mentioning" from? Your own Application? Twitter? Doing it this way lets you have control over where you're grabbing the so-called "mentions".The DIY Solution:
The best way I have found is to build your own set of working
entities
on top of a DraftJS based rich-text editor.This of course also requires that you're using React.
Forgive me for not actually building a complete set of working code. I was interested in doing something similar for an App I'm building in Meteor with React on the front-end. So this really made sense to me because I'd only be adding one more library (DraftJS) and the rest would be my custom
entities
coded out.What I did is kind of a hack but works quite well as a workaround solution.
I've got a simple textarea (not contenteditable because of what's next, I'll explain below) and a div which is absolute positioned behind the textarea. Using javascript, I copy the content from the textarea to the div while splitting it at 140 chars and putting all extra characters inside an
<em />
tag.Well, it's a little bit more complicated because twitter algorithm to compute a tweet length is different (links doesn't count as their real value, because of t.co url shortening). The exact method can be found as part of the official twitter/twitter-txt repository.
Step-by-step code.
Wrap a simple textarea into a div to simplify the css:
CSS is just making the textarea and the div right above each other and highlight the text.
Now the fun part, this is implemented using jQuery but that's not the important thing.
Add some event handler on change, and te common document ready and you're done. See the codepen link below.
Note that the div placed behind can be created using js too, when loading the page:
Full example
See working example over here: http://codepen.io/hussard/pen/EZvaBZ
Turns out this is really not an easy thing to do. I've been struggling with it for the past few days, and I'm not very close to a solution.
Your best drop-in solution currently is the At.js library, which is still being maintained, but definitely isn't perfect. One of the examples shows how you can kind of do a text highlight.
The most annoying part of this problem is that Twitter has a beautiful solution that seemingly works perfectly staring us right in the face. I took some time investigating the way they implement their "tweet box," and it's definitely not trivial. It looks like they're doing almost everything manually, including emulating undo/redo functionality, intercepting copy/pastes, providing custom code for IE/W3C, custom-coding Mac/PC, and more. They use a contenteditable div, which is in-and-of-itself problematic due to differences in browser implementations. It's pretty impressive, actually.
Here's the most relevant (obfuscated, unfortunately) code, taken from Twitter's boot JavaScript file (found by inspecting the header of the logged-in Twitter homepage). I didn't want to directly copy and paste the link, in case it's personalized to my Twitter account.
Obviously, this "answer" doesn't solve anything, but hopefully could provide enough to (re-)spark a conversation about this topic.