Fork me on GitHub

Happy for you to make any mods you see necessary


@mikethompson: Not sure where to put comments so i'll put them here: 1. If I understand the subscription snippet correctly - you will call issue-items-query! multiple times if you subscribe one resource multiple times, which is what i tried to avoid with counters. However this logic can be incorporated inside issue-items-query!. 2. You say that initiating data fetching is not an event, but it probably should transition app-db into loading state which is an observable state change.


All good points, I'll add further notes


About undo/redo: i'm not sure how is it applicable to entire app-db. If application has some parallel activity going on (for example you fill a form and receive notifications at the same time) undoing entire application to reset the form will do you no good. To me undo should be done in context of some editing session or specific workflow taking into account actions which are not undoable. For example when i work with text editor - i'd like undo to work in context of the current tab. Shortly i'd like to say that reactive data update on client doesn't interfere with undoing your job, undoing just must work on edited data but not on real data.


This may be very specific to my current application.


is there a suggested way to get remote-data into app-db:

 (fn [db]
   (reaction (:refs @db))))

 (fn [db [_ refs]]
   (assoc db :refs refs)))

(defn make-remote-call [endpoint]
  (go (let [response
            (<! (http/get endpoint
                          {:with-credentials? false}))]
       ; (.log js/console (:body response))
        (dispatch [:set-refs! (:body response)]))))

(defroute "/home" []
  (make-remote-call "")
  (dispatch [:set-active-panel :home-panel]))


@shanth: I think @mikethompson is suggesting this is a good pattern to use He says its still a WIP and the approach he outlines is more general than your example, he doesn't go into detail about using core.async for instance. That level of detail will be dictated by your specific needs.


Hello, how the Elm’s concept of adress in transposed in re-frame code?


Look up dispatch


It is normally used like this (dispatch [event-id params]). Eg: on-click handlers tend to involve a dispatch


That first element in the vector event-id is the equivalent of an Elem address (I think)


It selects which event handler will be run. So in that sense it is like an address. I think. But don't quote me,


No wait. Hmm. I'm not sure I've got the above correct. I just had a quick look again at Elm (been a while).


In the case where a component is intentiated several times how to manage the state of each instance?


yes i know this from


in the let I can create a unique id for the instance and use it as argument in dispatch and subscribe


is it the recommended way to do it?


can you describe your task? Do you create some new items inside these components and then persist them with dispatch?


i’m thinking...


if i want several counters that can be started paused or delete how can i structure my state and code?


the state looks like that {:counters {id1 counter1-state id2 counter2-state}}


This state looks ok to me


where id key is created in the let binding of the component


so my handler has to take the id as argument to operate on the good counter


For new timers you mean? I imagine there's some way to add a new timer where id is generated


yes it is the case


i’ve forgot to mention that


I guess then there must be some handler that actually creates a counter and put it into app-db. If you don't need id in component immediately then you can generate id inside and pass it as argument to dispatch. Otherwise i'd just generate id inside a handler.


makes sense


you're welcome


i have the weirdest problem with reagent/re-frame: I have two form-2 components, where one has a subscription and calls the other one with the dereferenced value of that subscription. When I log the value before passing it into the second component I see the correct value. But when I log the value as it appears in the second component, I get the previous version of the value


line 45 is where the second component gets called, line 5 is where i log the passed-in value


i'm probably doing something wrong, but i can't figure out what


@jbaiter you should have the same args list in the inner fn as in the outer fn in linking-tool, so your inner fn should start as (fn [tags tokens empty_tag] ...)


that's explained at the end of the form-2 section in the re-frame (or reagent?) wiki


I pinned the link because it's a recurrent issue simple_smile