>From leaking to leaky? There must be another way. But can you explain 
>@whodidthis (awesome nick) why async dispatch loses data when you type fast? 
>Very curious!

Sent from my iPhone

> On Apr 4, 2015, at 11:38 AM, whodidthis <ton...@gmail.com> wrote:
> 
>> On Saturday, April 4, 2015 at 4:19:06 PM UTC+3, Colin Yates wrote:
>> Hi Marc, sure - but give me a few days. It isn't anything more complex
>> than (hacked from memory, and obvious numpty upgrades
>> notwithstanding...):
>> 
>> (register-sub :add-patient/filter
>>  (fn [db] (reaction (-> db deref state/AddPatient :filter)))
>> 
>> (register-handler :add-patient/edit-field
>>  [c/middleware (path state/AddPatient :filter]
>>  (fn [db [k v]] (assoc db k v)))
>> 
>> (defn []
>>  (let [state (subscribe [:add-patient/filter])
>>         field-a (reaction (-> state deref :field-a))]
>>    [:input {:type "text" :value @field-a :on-change (fn [] (dispatch
>> [:add-patient/edit-field :field-a %]) nil)}]))
>> 
>>> On 4 April 2015 at 14:09, Marc Fawzi <marc.fa...@gmail.com> wrote:
>>> <<
>>> If I use :value then I can lose quite a few key presses if I type really
>>> quickly.
>>> 
>>> Hi Colin,
>>> 
>>> I'm very interested i seeing the code for that. The reason is I have been
>>> working on behavior encapsulating "smart" input component with animations
>>> and I've yet to optimize performance but at the same time I don't have your
>>> issue with fast typing. Maybe the performance issue is something to do with
>>> reframe's register/subscribe and higher levels of abstraction vs simply
>>> using cursors?
>>> 
>>> Marc
>>> 
>>> 
>>>> On Sat, Apr 4, 2015 at 1:21 AM, Colin Yates <colin.ya...@gmail.com> wrote:
>>>> 
>>>> That might work - nice, I will try. I was pondering whether binding to a
>>>> local atom and periodically synchronising with global state might work, but
>>>> your approach is much nicer.
>>>> 
>>>>> On Friday, 3 April 2015 23:35:35 UTC+1, AndyR  wrote:
>>>>> 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 <colin...@gmail.com> 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 <andre...@gmail.com> 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 clojurescrip...@googlegroups.com.
>>>>> 
>>>>> 
>>>>> 
>>>>>> To post to this group, send email to clojur...@googlegroups.com.
>>>>> 
>>>>>> 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
>>>>> clojurescrip...@googlegroups.com.
>>>>> 
>>>>> To post to this group, send email to clojur...@googlegroups.com.
>>>>> 
>>>>> 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 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.
>>> 
>>> 
>>> --
>>> 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.
> 
> 
> 
>> On Saturday, April 4, 2015 at 4:19:06 PM UTC+3, Colin Yates wrote:
>> Hi Marc, sure - but give me a few days. It isn't anything more complex
>> than (hacked from memory, and obvious numpty upgrades
>> notwithstanding...):
>> 
>> (register-sub :add-patient/filter
>>  (fn [db] (reaction (-> db deref state/AddPatient :filter)))
>> 
>> (register-handler :add-patient/edit-field
>>  [c/middleware (path state/AddPatient :filter]
>>  (fn [db [k v]] (assoc db k v)))
>> 
>> (defn []
>>  (let [state (subscribe [:add-patient/filter])
>>         field-a (reaction (-> state deref :field-a))]
>>    [:input {:type "text" :value @field-a :on-change (fn [] (dispatch
>> [:add-patient/edit-field :field-a %]) nil)}]))
>> 
>>> On 4 April 2015 at 14:09, Marc Fawzi <marc.fa...@gmail.com> wrote:
>>> <<
>>> If I use :value then I can lose quite a few key presses if I type really
>>> quickly.
>>> 
>>> Hi Colin,
>>> 
>>> I'm very interested i seeing the code for that. The reason is I have been
>>> working on behavior encapsulating "smart" input component with animations
>>> and I've yet to optimize performance but at the same time I don't have your
>>> issue with fast typing. Maybe the performance issue is something to do with
>>> reframe's register/subscribe and higher levels of abstraction vs simply
>>> using cursors?
>>> 
>>> Marc
>>> 
>>> 
>>>> On Sat, Apr 4, 2015 at 1:21 AM, Colin Yates <colin.ya...@gmail.com> wrote:
>>>> 
>>>> That might work - nice, I will try. I was pondering whether binding to a
>>>> local atom and periodically synchronising with global state might work, but
>>>> your approach is much nicer.
>>>> 
>>>>> On Friday, 3 April 2015 23:35:35 UTC+1, AndyR  wrote:
>>>>> 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 <colin...@gmail.com> 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 <andre...@gmail.com> 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 clojurescrip...@googlegroups.com.
>>>>> 
>>>>> 
>>>>> 
>>>>>> To post to this group, send email to clojur...@googlegroups.com.
>>>>> 
>>>>>> 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
>>>>> clojurescrip...@googlegroups.com.
>>>>> 
>>>>> To post to this group, send email to clojur...@googlegroups.com.
>>>>> 
>>>>> 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 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.
>>> 
>>> 
>>> --
>>> 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.
> 
> Yes you will lose everything if you change input value through dispatch as it 
> is asynchronous. Something synchronous like a local atom will work though. As 
> does re-frames app-db.
> 
> Basically you need something like 'dispatch-sync' 
> (https://github.com/Day8/re-frame/blob/master/src/re_frame/router.cljs#L54) 
> except dispatching resets entire app-db so that wont work for reasons 
> mentioned in the other thread. You need to swap app-db on your own.
> 
> (register-sub
>  ::my-secret
>  (fn [db _]
>    (reaction (::my-secret @db))))
> 
> (defn synced-change
>  [value]
>  (swap! re-frame.db/app-db assoc ::my-secret value))
> 
> (defn tags-show
>  []
>  (let [value (subscribe [::my-secret])]
>    (fn []
>      [:input {:value @value :on-change (fn [e] (synced-change (-> e .-target 
> .-value)))}])))
> 
> Maybe in the future re-frame will have a scoped dispatch-sync or whatever.
> 
> -- 
> 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.

-- 
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