On Friday, May 23, 2014 4:17:45 AM UTC-7, Chas Emerick wrote:
> Bit of a stale thread here, but I thought I'd say a couple of things
>     since I was mentioned. :-)
> 
>     
> 
>     contentEditable is absolutely a cluster, through and through. (All
>     the best that the "web standards" processes has to offer, but that's
>     an OT rant for another day.)
> 
>     
> 
>     As you gleaned from my React ML posts (as as David speculated
>     nearby), working with contentEditable via React *adds* to the
>     challenges. While React's virtual DOM is a simplifying abstraction
>     elsewhere, it simply cannot represent all of the state associated
>     with an editable region, because that state isn't represented in the
>     DOM in the first place. So, caret position, selection ranges, scroll
>     position, etc. are all inevitable casualties of React's particular
>     immediate-mode rendering strategy. You can manage these things "out
>     of band", but at a certain point (very much dependent upon your
>     objectives and requirements) React becomes an obstacle rather than
>     an aid.
> 
>     
> 
>     That said, if you are looking to use contentEditable for fairly
>     lightweight stuff — e.g. you just want the user to be able to
>     provide some styled content — you can hook into an onChange or
>     onBlur event to update your model and using React/Om should pan out
>     just fine after the requisite contentEditable difficulty.
> 
>     
> 
>     Good luck,
> 
>     
> 
>     - Chas
> 
>     
> 
>     
> On 04/22/2014 06:58 AM, Paul Butcher
>       wrote:
> 
>     
>     
>       
>       
> After working
>         my way through the various samples and tutorials out there, I’m
>         about to start on my first Om app (yay!).
>       
> 
> 
>       
>       
> Possibly
>         foolishly, I’m planning to make heavy use of contentEditable. In
>         essence, what I need to do is replicate something similar to
>         Word’s “track changes” functionality. Ideally, I’d like to get
>         this to play nicely with Om’s undo - the complication being that
>         as well as changes made by the app, I’d also need to undo
>         changes made by the user (ideally wrapping changes made by both
>         into a single logical undo).
>       
> 
> 
>       
>       
> I’ve done
>         quite a bit of searching, and getting React to play nicely with
>         contentEditable seems to be a largely unexplored area? Chas
>         Emerick’s message on the React mailing list seems to capture the
>         current state of the art:
>       
> 
> 
>       
>       
> https://groups.google.com/d/msg/reactjs/ff5YlPKiqmc/ngDTsk_i2mYJ
>       
> 
> 
>       
>       
> Although this
>         looks promising:
>       
> 
> 
>       
>       
> http://stackoverflow.com/a/22678516/268371
>       
> 
> 
>       
>       
> Is there
>         anything else that I should be aware of? Any words of wisdom or
>         advice before I dive into this (including “don’t use Om for this
>         - it’s the wrong tool for the job” :-)?
>       
> 
>         
> 
>           
>  
>         
>       
>       
> 
>       
> 
>         
> 
>           
> --
> 
>             paul.butcher->msgCount++
> 
>             
> 
>             Silverstone, Brands Hatch, Donington Park...
> 
>             Who says I have a one track mind?
> 
>             
> 
>             http://www.paulbutcher.com/
> 
>             LinkedIn: http://www.linkedin.com/in/paulbutcher
> 
>             Skype: paulrabutcher
>           
> 
> 
>               
>           
> Author of Seven Concurrency
>                 Models in Seven Weeks: When Threads Unravel
>           
> http://pragprog.com/book/pb7con
>         
>       
>       -- 
> 
>       Note that posts from new members are moderated - please be patient
>       with your first post.
> 
>       --- 
> 
>       You received this message because you are subscribed to the Google
>       Groups "ClojureScript" group.
> 
>       To unsubscribe from this group and stop receiving emails from it,
>       send an email to clojurescrip...@googlegroups.com.
> 
>       To post to this group, send email to clojur...@googlegroups.com.
> 
>       Visit this group at http://groups.google.com/group/clojurescript.

I'd like to echo this and say that my experiments with contentEditable spans 
proven fruitful because I am managing the more difficult tasks (e.g. tracking 
cursor position) "out of band" as Chas recommends. My opinion is that it isn't 
necessarily a cluster; it just requires a bit of effort. Again, this all 
depends on what you are trying to achieve.

In my case I *do not* hook into onChange but I *do* hook into onBlur, onFocus, 
onClick, and onKey* events. onFocus/onClick is primarily for setting up caret 
tracking. onKey* events handle caret tracking and logic around specific keys. 
onBlur does the actual updating of the application state.

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.

Reply via email to