re-frame 2021-11-12 | Slack Archive

Benjamin14:11:28

Hi I have a re-com typeahead element that works with nyxt browser but with qutebrowser inserting doesn't insert. I know it can work because the example page works views.cljs:

(ns myleinreframe.views
  (:require
   [re-frame.core :as re-frame]
   [re-com.core :as re-com :refer [at]]
   [myleinreframe.subs :as subs]
   [reagent.core :as r]))

(let [luls (repeatedly 16 #(name (gensym "foo")))]
  (defn completion [s]
    (into
     []
     (comp
      (filter
       #(re-find (re-pattern s) %)))
     luls)))


(defn my-typeahead []
  (let
      [typeahead-on-change-value (r/atom nil)
       typeahead-model (r/atom {})
       suggestions-for-search completion
       data-source-immediate suggestions-for-search]
    [:div
     [re-com/typeahead :src (at)
      :model                typeahead-model
      :data-source          data-source-immediate
      :suggestion-to-string #(:name %)
      :render-suggestion    (fn [s] [:span [:i {:style {:width "40px"}} s]])
      :width                "300px"
      :placeholder          "airtest script"
      :on-change            #(reset! typeahead-on-change-value %)
      :immediate-model-update? true
      :rigid?               false
      :disabled?           false]]))


(defn main-panel []
  [re-com/v-box
   :src      (at)
   :height   "100%"
   :children [[ ;; title
               ;; -throbber
               my-typeahead
               ]]])

p-himik14:11:03

The setup (your particular project + your particular browser) are way too specific for an easy reproduction, so all I can offer is some advice: • Check if :on-change is actually triggered • I think typeahead wraps :input - try to see what happens to that input directly, not through typeahead (easiest to do via your browser's DevTools, if it has them. If not, you'll have to change re-com's code) • Get the re-com example page working locally and then gradually transform it to what you want to end up with, while testing the pasting functionality on every change. See what breaks it

Benjamin14:11:49

alright thanks

p-himik14:11:27

@dannyfreeman Moving here as this is the most topical place.

👍 1

p-himik14:11:30

I'm still not sure where your hardships come from. You can just use (dispatch [:event-id {:arg1 1, :arg2 2}]) and if you need to add some arguments, just (update event-v 1 assoc :arg3 3). Same with subscriptions.

lispers-anonymous14:11:28

We could easily do that, but existing events and subscriptions (of which we have thousands) would have to be retrofitted to follow that convention.

lispers-anonymous14:11:44

And that may be something we end up doing. I was hoping we would be able to drop the library in place, swapping out subscribe, dispatch, reg-event-*, and reg-sub with the implementations in the new library.

p-himik14:11:44

I see. Well, any re-frame change would not make it easier on you - you would still have to deal with the existing code. But it can be gradual even with your own wrappers. E.g. dispatch can be a 1-arg fn, and it will have the original behavior. And it can have an additional 2-arg arity - one for the event ID and the other for the map. Then the function that updates the arguments would also have two arities - 2-arg for vector + value and 3-arg for map + key + value. But hard to say how feasible it all is without knowing your actual code - you're the best judge here.

lispers-anonymous14:11:36

I sincerely wish I could share the code with you. I agree we would have to deal with existing code, but I suspect re-frame devs will make sure that the change is as non-breaking as they possibly could; they have been great about maintaining compatibility thus far. Since we will probably end up having to slowly use the library with new and refactors events/sub as it makes sense, we could also just lay out a new strategy for events and subscriptions that operate on a map instead of a vector. Under the hood it could all be placed in a vector since that is what re-frame expects.

lispers-anonymous14:11:14

Another strategy I thought of that actually works really well for subscriptions is injecting the extra information with the third dynamic vector argument. We don't use dynv at all for our actual even and subscription implementations. I have a lot of reservations about building on top of deprecated functionality though

p-himik15:11:29

The change will definitely be non-breaking - my point was about updating your existing code so it sticks to the same approach. Yeah, I wouldn't use dynamic vectors for anything nowadays.

lispers-anonymous15:11:40

I understand. My team and I came to the same conclusion about dynamic vectors too. I'll take what you've said into consideration. Thanks again for the conversation. Perhaps when my hands are unbound related to open sourcing this work I'll seek you out for some feedback on it.

👍 1

2021-11-12

Channels