Fork me on GitHub

what's the benefit of having named subscriptions?


rather than just selecting from the app-db what you need in the component


Code reuse and testing of the more complicated ones

👍 4

@lilactown I’d think 2 things come to mind: 1) less coupling to db structure 2) can calculate (effectively cached) derived state in subscription 3) the signal graph can do a pretty efficient job of avoiding recalculating things that aren’t involved with the changes part of the overall app db state.


(Off by one error detected)


hm. could you possibly get at least 1 + 2 by simply separating the code that operates on the app-db into a function?


3 could be done by having a smart selector function that subscribed only to changes to the keys


I'm trying to think of how a React Hooks-y re-frame-ish framework might look


interceptors/effects/coeffects/etc. make sense, trying to decide how subscribing and dispatching will look


For 1+2 a fn could do it. You’d need to cache though. And also clean up that cache when no longer needed.


I mean to get the caching effect.


And the smart sector from 3 is like a reagent reaction in my opinion. Which is what re-frame uses.


I haven’t really thought much about hooks being useful in the reagent space at this point. Perhaps for some form-3 cases or if wanting to about reagent stuff for some reason (to be more pure react perhaps)


@lilactown in theory named subscriptions are more declarative. You are not tying the view to a particular structure in app-db


Or to put that another way, the data structure you choose in app-db can change without the view needing to change, providing there's a subscription mediating the access.


That makes sense! Thank you


i think of it like: the “where” of a subscription is an implementation detail that can change, but the subscription value* itself represents something that (hopefully) won’t change. akin to a db schema, which should never introduce breaking changes, vs pulling the data from a sql query or an api call or some localstorage– the where shouldn’t matter beyond a certain point.

Braden Shepherdson18:11:37

I'm getting re-frame: no :event handler registered for: even though my events.cljs has

  (fn-traced [_]                                                                  
    (-> (js/fetch "")                   
        (.then #(Uint8Array. (.arrayBuffer %)))                                   
        (.then zmachine/read-file)                                                
        (.then #(rf/dispatch [::story-loaded %])))                                


Are you requiring (and aliasing) the namespace in the code that's trying to dispatch the event?

Braden Shepherdson18:11:23

it's required as [ :as events] and then dispatched with (rf/dispatch [::events/fetch-story]). based on the error message, the namespacing is correct.


Yeah, looks right to me. Maybe just stale code/handlers? Sometimes stuff like that clears up with a clean-and-rebuild. If you're using Chrome you can also try the Empty Cache and Hard Reload trick


You shouldn't need to do the Empty Cache... thing but I swear it cleans things up sometimes. Sometimes I even think I've been close to almost proving it.

Braden Shepherdson18:11:38

I always run with the "Disable cache" setting in DevTools->Network turned on. I've been burned too many times in less live-reload-y contexts.


Yeah same here. That's why I say you shouldn't need the Empty Cache trick.


on the other hand, if nothing else works, maybe worth a try? :man-shrugging:

Braden Shepherdson18:11:38

same result after killing the figwheel server and reloading. it's strange.


maybe the function is being passed more than one parameter? Try changing the params to [& _]


Sanity check that (rf/dispatch []) doesn't work as well... Easy to accidentally occlude/overwrite events itself.


If nothing else works, I’d try renaming the event, just to see if that shakes anything loose.

Braden Shepherdson19:11:03

okay. code is now public at eg. and I'm getting this error:

----  Could not Analyze  src/cljc/zm/ops1OP.cljc   line:1  column:1  ----            

  Don't know how to create ISeq from: clojure.lang.Keyword                           

  1  (ns zm.ops1OP
     ^--- Don't know how to create ISeq from: clojure.lang.Keyword                   
  2    "1OP operations"
  3    #?(:cljs (:require-macros [zm.util :refer [v4-5]]))                           
  4    (:require [zm.memory :refer :all]

----  Analysis Error : Please see src/cljc/zm/ops1OP.cljc  ----                      

Braden Shepherdson19:11:17

I think I was loading the last compilable code earlier, and that's why the puzzling failures about fetch-story.


is it bad form to deref a subscription inside an event handler? seems to work ok, but faintly remember some older docs recommending not to do it


If you don’t want to use the third party library mentioned in the docs, a cleaner way would be to call a function from your handler with db as an argument..

(let [your-value (just-a-f db)] 
The just-a-f function will contain the logic that retrieves the value you’re looking for :)


The docs you talk about are an FAQ entry


oh wait, that’s the old FAQ, just a sec


Here, you’ll like this one better, there’s a link to a work-around:

👍 4

@braden.shepherdson That all looks right too, do you still have old compiled code hanging around somewhere?

Braden Shepherdson19:11:02

probably. I'm not sure what to make of this error, though.

Braden Shepherdson19:11:19

these files load sucessfully in JVM Clojure for tests.


Yeah, if you’ve got conflicts with older compiles, the error message may be misleading at best

Braden Shepherdson19:11:49

lein clean made no difference here.


See if it compiles when you comment out the :require-macros line (the whole reader conditional I mean)


It’ll probably still die due to missing macros, but just to check if we can get it to die from missing macros instead of from “can’t create ISeq from keyword” thing

Braden Shepherdson20:11:19

ah, apparently :refer :all is not allowed in CLJS (and so in CLJC)

Braden Shepherdson20:11:47

error message could be roughly four orders of magnitude better, but oh well.


Wow, ok, I guess the error message does make sense in hindsight. Good job tracking that one down, though, that one was subtle.

Braden Shepherdson20:11:03

that feels like it's worth filing a bug against CLJS to fix the error message; it's brutal and I won't be the last to stumble into it.


@deg I have a question about re-frame-firebase and the firestore related events : how would you update a single object inside an array ? What's the idiomatic way to do this ? Thanks 😉


Sorry, I don't really know. I've only used vanilla Firebase. The Firestore part of the library was contributed by someone else.


If you don’t want to use the third party library mentioned in the docs, a cleaner way would be to call a function from your handler with db as an argument..

(let [your-value (just-a-f db)] 
The just-a-f function will contain the logic that retrieves the value you’re looking for :)