Fork me on GitHub
#re-frame
<
2016-03-01
>
mikethompson03:03:34

Happy for you to make any mods you see necessary

nidu04:03:35

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

mikethompson04:03:38

All good points, I'll add further notes

nidu05:03:19

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.

nidu05:03:33

This may be very specific to my current application.

shanth08:03:53

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

(register-sub
 :refs
 (fn [db]
   (reaction (:refs @db))))

(register-handler
 :set-refs!
 (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]))

simax9909:03:02

@shanth: I think @mikethompson is suggesting this is a good pattern to use https://clojurians.slack.com/archives/re-frame/p1456803788000535. 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.

pbaille09:03:04

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

mikethompson10:03:19

Look up dispatch

mikethompson10:03:03

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

mikethompson10:03:47

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

mikethompson10:03:46

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

mikethompson10:03:28

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

pbaille11:03:27

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

pbaille12:03:05

yes i know this from

pbaille12:03:08

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

pbaille12:03:39

is it the recommended way to do it?

nidu12:03:16

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

pbaille12:03:02

i’m thinking...

pbaille12:03:22

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

pbaille12:03:16

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

nidu12:03:34

This state looks ok to me

pbaille12:03:49

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

pbaille12:03:16

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

nidu12:03:43

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

pbaille12:03:56

yes it is the case

pbaille12:03:12

i’ve forgot to mention that

nidu12:03:47

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.

pbaille12:03:45

makes sense

nidu12:03:58

you're welcome

jbaiter17:03:38

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

jbaiter17:03:32

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

jbaiter17:03:49

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

nberger18:03:49

@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] ...)

nberger18:03:27

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

nberger18:03:41

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