@andre looking good! Can't grok the problem you are having, so can't suggest anything there. Need more explanation. @oliy nice to hear. It did all fall out nicely, I think. reg-sub was particularly satisfying to me personally. Would love to get some more time to take it ahead one more step too.

i'll have to use 0.7.0 at work and it's super hard after using 0.8.0 😁 since the side-effects stuff is suddendly missing everywhere

@elahti: The upgrade should be pretty painless, there shouldn’t be any breaking changes. Then you can sneak in some improvements 🙂

@elahti I agree with @shaun-mahood there's not a lot to do in the "upgrade" to 0.8.0 UNLESS you have written your own middleware (in which case you'll have to rewrite them as interceptors, which is still fairly easy). For many, there is exactly nothing to do (although you will get deprecation warnings until you rename two functions).

thanks! i know that i could just switch it in our project but i just want to communicate it with our (small) team first. laziness and all being a factor haven't just got into it yet 🙂

excuses, i know

@mikethompson reg-sub seemed to be one of the few bits that didn't change to me, what was new about that?

@oliy pre 0.8.0 you wrote this:

(register-sub
 :sorted-items             ;; the query id
 (fn [db [_]]
   (let [items      (reaction (get-in @db [:some :path :to :items]))]  ;; reaction #1
         sort-attr  (reaction (get-in @db [:sort-by]))]                ;; reaction #2
       (reaction (sort-by @sort-attr @items)))))     

(reg-sub
  :sorted-items             ;; the query id
  :<-  [:items]             ;; assuming a subscription for :items exists
  :<-  [:sort-attr]        ;; assuming this subscription exists also 
  (fn [[items sort-attr]  _]
     (sort-by sort-attr items)))

Ah, I've seen that but not tried it yet. I'm not sure about the syntax. I've been using the 2-fn sub so no reactions in my code at the moment

May have been using a 0.8 snapshot for that though!

mikethompson is the final argument to the reg-sub returning function the db itself? (fn [[items sort-attr] _] <- that _

@akaivola that’s the subscription params IIRC

I was just wondering since before 0.8 register-sub got the db as it’s first argument. now I assume in reg-sub db is the last argument

it is in fact still the first argument

just checked the docs

ah, but that all works differently when you have :<- in there

still would like to know what that second argument is 🙂

Hi

some improvements in 0.1.4 before html debugger release - https://github.com/flexsurfer/re-frisk

@akaivola sorry the docs on reg-sub are lacking ... best source of information is currently: https://github.com/Day8/re-frame/blob/master/examples/todomvc/src/todomvc/subs.cljs

line 71: ... and the 3rd one is for advanced cases, out of scope for this discussion.

No matter, I’ll get to it sometime later when elahti brings our project to 0.8.0 😄

Ahh, that's all about dynamic subscriptions

oh, dynamic subscriptions I know about

Look in the Wiki

Right

I’m familiar with them

@deas Welcome

In one react-native (re-natal) IoT pet project I abused dynamic subscriptions to send sensor data

It was really nasty but effective 😄

I read up on how to do navigation using panels here https://github.com/Day8/re-frame/wiki/A-Larger-App, but what is best practice for navigation between tabs? Use a subscription to activate/deactivate the appropriate tab?

State changes should happen via an event handler

Events happen Event Handlers process them, causing state changes

A change in tab is a state change

@mikethompson Sorry, that is what I meant handler sets active tab in db and tab activates/deactivates base on subscription to db.

Yep

That navigation might also trigger the need for a data request from the server. Again, that's the domain of the event handler. It is responsible for looking after the change in the state of the app, including the process of getting more data.

@mikethompson Seems to me that handlers often require quite a few helpers (acces external datasources etc). Do these normally go directly in handlers.cljs or?

Sure

These days the naming recomendation is events.cljs (not handlers.cljs, but yeah)

@mikethompson Template needs an update 🙂 would a patch be useful?

Sure, thanks

That advice changed in v0.8.0 but not all docs and templates have caught up yet

@mikethompson done

Thanks

What is the best approach to initializing the app-db based on the value of a Javascript promise? (in this case query to a PouchDB database)

@mac Do you need to wait until the promise returns before initialization?

@shaun-mahood Yes, I need to ensure that the value from the promise has been inserted into app-db before anyhing else happens.

@mac Two bits of reading for you: 1. https://github.com/Day8/re-frame/blob/master/docs/Loading-Initial-Data.md 2. https://github.com/Day8/re-frame-async-flow-fx/blob/develop/README.md

Overall plan: 1. Put a good initial value into app-db (dispatch [:init]) ... perhaps use dispatch-sync 2. Kick off the query (probably in the event handler for :init) 3. On successful promise resolution, dispatch an event to say so (the handler for that event will change app-db further with the results of the query) 4. If the promise (query) fails, then dispatch an event for that too, the appropriate handler will then put the app into the right failed state.

@mikethompson Thanks, that makes a lot of sense.

Can you elaborate on what the "good initial value" might be? Just some constant (such as nil or :no-value) that the app will interpret properly?

I'm not actually sure if it's necessary, but I've always been putting empty maps in my initial values for the things that would be populated later. So something like (def initial-state {:promise-result {}})

Oh, I did that for a few things but I've found that maps can be created automatically. Now I only do it for sets that I want to be able to conj into and disj from without worrying about creating it inline

i.e., assoc-in will create the intermediate levels automatically for you

I generally have been doing it for my root keys, or for things that I want to register subscriptions on.

Does the data key have to be there at the start if you want to use it for reg-sub?

Not sure about that one. Probably

I think at some point it wasn't working for me if the key didn't exist at the start, and I've never revisited it since.

But that was also when I started with Clojure so I could have been doing pretty much everything wrong. Now I figure I'm only likely to do some things wrong 🙂

Ha yea. I've found that you can usually ignore it for most data types

vectors, lists and maps particularly

sets you need to explicitly add to init-db

otherwise conj will create a list instead of adding the element to the empty set