Other than resorting to more manual steps: One easy "hack" is to just
change the ^{:key "..."} meta attribute of your [:input ]. This will
unmount and re-mount it and re-populate the :default-value.

On Fri, Apr 3, 2015 at 5:59 PM, Colin Yates <[email protected]> wrote:

> The reason I want it controlled is because I need to change the state the
> input is bound to via another mechanism. If an entity is recognised then I
> show a "do you want to load the existing user" for example. If they chose
> to then the atom is updated but not the Input field (with default-value).
>
> Sent from my iPhone
>
> > On 3 Apr 2015, at 22:56, AndyR <[email protected]> wrote:
> >
> >> On Friday, April 3, 2015 at 5:25:24 PM UTC-4, Colin Yates wrote:
> >> Hi,
> >>
> >> If I use :default-value then the input field keeps up no matter how
> fast I type. If I use :value then I can lose quite a few key presses if I
> type really quickly.
> >>
> >> I expect I probably need to break my components into smaller discrete
> components, which only depend on the absolute minimum, but I wondered first
> whether anyone else has experienced this and has a workaround?
> >>
> >> At the moment my components are quite large, for example I have one
> component which has 10 fields on it - splitting that into 10 separate
> components with more focused subscriptions will help I assume?
> >>
> >> This is on a late 2008 macbook pro so isn't the quickest, but still...
> >>
> >> Thanks!
> >
> > IMO, it should be avoided to have a controlled input. As you already
> mentioned the problems. But even if I need to keep it --e.g.-- to numbers:
> A much more user friendly UI is to present the user with an error message
> (next to the input) stating exactly what's wrong with his/her input.
> > The other typical example like "all capital" can easily be applied
> afterwards when sending the content to the server.
> >
> > I haven't tried this but it probably works: You can also just listen to
> "onkeypress" and just prevent the default (ie the browser populates
> .-value) and populate it yourself (filtered). This means that instead of
> losing input you'll just have a lagging UI. Better, but not optimal. This
> brakes down for copy and paste (and possibly other input?), so you'll still
> need to listen to on-change.
> >
> > Sometimes, I even lose keypresses with my fast PC since my computer is
> busy with other stuff. So the controlled input which relies on timing is a
> big no-no IMO.
> >
> > --
> > 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 [email protected].
> > To post to this group, send email to [email protected].
> > Visit this group at http://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 a topic in the
> Google Groups "ClojureScript" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojurescript/mqxEiTw6XU4/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/clojurescript.

Reply via email to