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

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

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

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

Are you requiring (and aliasing) the zm.events namespace in the code that's trying to dispatch the :zm.events/fetch-story event?

it's required as [zm.events :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.

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:

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 [:zm.events/fetch-story]) 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.

okay. code is now public at eg. https://github.com/shepheb/zmachine-clojure/blob/master/src/cljc/zm/ops1OP.cljc 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  ----                      

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

You may be thinking of this faq: https://github.com/Day8/re-frame/wiki/FAQ#1-why-cant-i-access-subscriptions-from-event-handlers

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: https://github.com/Day8/re-frame/blob/master/docs/FAQs/UseASubscriptionInAnEventHandler.md

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

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

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

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

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

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.

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.

hello

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