It is true that you must update an input element synchronously, but the alternative would be incredibly complicated, and I doubt it could reach feature parity. You'd have to handle every keypress, of course. Then you'd have to keep track of the cursor, which could change on touch events and mouse clicks. If you have a multiline input, the up/down arrow would have to be handled manually, which would be challenging with a variable width font. Then you'd want to interface with the clipboard api if you want pasting to work. You'll lose a lot of nice built-in features, like spell check. I'm not sure whether it is possible to use adaptive keyboard technology or text-to-speech on mobile without using native input elements. Accessibility would be out the window.
All of this kind of depends on what your goals are. If it is rich text, I think the technology of choice is to use contenteditable divs, though I've never done that myself (it's what gmail uses, for what it is worth). But as far as I know you'll have to update the divs synchronously there too. On Sat, Nov 10, 2018 at 12:30 PM Lyn Headley <lahea...@gmail.com> wrote: > Has anyone ever wondered whether the native browser supplied textarea > elements are more trouble than they're worth? I'm thinking from the > perspective of a react based application that wants to use something like > core.async for event handling. If you are currently typing into a text > area, then the key down events are not really handled by your application > but by the browser. You cannot simply dispatch each event to a more > centrally located and more asynchronous event handling process in your > application, because you have to either prevent default or not from within > the synchronous event handler itself. And so the decision whether or not to > handle a key press event using the full logic of your application must be > made within the event handler, and cannot be delegated to an asynchronous > and intelligent process. To me this is a major drawback of using browser > native controls like textarea and others. I wonder if it is worth the > effort to re implement them entirely in clojurescript and/or react. > > Has anyone else had thoughts along these lines and do my thoughts make > sense? > > Lyn > > -- > 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 https://groups.google.com/group/clojurescript. > -- 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 https://groups.google.com/group/clojurescript.
