You have to deref text.

pfff Now another error message

re-frame: no subscription handler registered for: :re-frame.subs/read-text. Returning a nil subscription.

but that one does exist

(re-frame/reg-sub
 :read-text
 (fn [db]
 (:text db)))

Read your code and errors very carefully. At all times.

@U0EGWJE3E I think the problem is related to the way you named your sub and the way you are calling it. If you are using a namespaced keyword in the subscribe call (re-frame/subscribe [::subs/read-text]) then the name of your subscription should also be with namespace and because you are already in the subs namespace the only thing missing is another pair of : like this (re-frame/reg-sub ::read-text ....

also the name is expecting that the namespace :re-frame.subs exists and this is another error

Thanks, that part works

As far as I understand subscriptions trigger re-renderings. So, since the function isn't a view function this might be problematic. I'd say, if you need the value if the sub, why not just deref it in the view before passing it to the function?

Or to be more general: What problem are you actually trying to solve this way?

We have a handy subscription to determine if a certain feature is enabled, based on a value stored in the re-frame app-db. E.g., [:feature-enabled? :coffee-maker] And I'd like to find out if a certain feature is enabled... but in a bit of code that's far removed from the view layer and re-frame in general. It's a service that gets initialized with plain-old cljs and does some communication with a web worker.

That sounds like it should be done in an effect handler because it's a side effect. If it's very far removed then use the side effect to pass it on.

The service's lifecycle is managed as a stuartsierra.component and we just need the feature-enabled? value upon initialize of that component. Do you think it would be safer to go ahead with the subscription usage, or to 'manually' deref the re-frame app-db atom and check the value directly (rewriting some of the work that the subscription is doing)?

You shouldn't use subscriptions anywhere but in reactive contexts. Or rather, you can call subscribe anywhere, but you should deref the resulting reaction at least once in a reactive context (view functions, other reactions).

The relevant issue: https://github.com/day8/re-frame/issues/740

@U0HJJF9A4 Do you trigger the features at run time, without reloading the page?

Also, don't use re-frame.db/app-db directly - it's not a public API.

Yes, depending on the value of the :feature-enabled? subscription, as it is checked shortly after pageload, the particular service would be initialized.

Let me rephrase - do you change the features after the services have already been initialized?

Or is it only the initial state that matters?

Only initial state (though it is not hard coded either (retrieved from LaunchDarkly))

Then personally, I wouldn't even consider the features state to be a part of the application's state. Hence, I wouldn't put it in app-db.

We have a lot of view components (living in a re-frame land) that show/hide based on the :feature-enabled? subscription value. That's why we store the results from LaunchDarkly in the app-db.

So it is also in a reactive context, so this is probably fine? (though it may depend on which page the user is on, whether there are currently any reactive contexts)

Yeah, but you don't need app-db for that. There's nothing to react to here, it's static data. Compare

(def feature-enabled? (atom true))

(def feature-view []
  (when @feature-enabled?
    [...]))

(in my code above, the assumption is that the rendering is delayed till feature-enabled? is set to the right value)

Thanks for the response, btw. So the thing is, a feature's enabled value can change over time (websockets w/ LaunchDarkly). However, in the case of the service I was referring to above, that one only checks once (during init). There are some others that show/hide view components that we want to use the most recent feature flag value for (hence the existence of the re-frame subscription).

Alright. And where do you do your components initialization? Is it in an effect handler or some other place?

It's a Stuart Sierra component, and the feature flag value is checked in the start component/Lifecycle method

BTW, we have om.next and re-frame living next to each other in this app...

But where do you call component/start?

component/start is run when our core ns in loaded

If you call it in an effect that's triggered by an event, you will be able to pass it the relevant information from app-db from the event handler and down to the effect arguments.

That would be better, but unfortunately it would require significant refactoring. I think I'm leaning towards keeping the subscription misuse. Hmm... going off of what you mentioned above (meta tags), could be interesting to have a view component that just renders meta tags with all the feature flags, and then retrieve them from the DOM when needed outside of a reactive context. Would that be crazy?

Absolutely.

you could store the initial state of the feature flag someplace else, then initialize both the app-db and the component from that shared place

re-frame should really add a tap or some other kind of fn that allows one to look at a sub w/o caching it though

0.10.6 is quite old but I don't remember any issues with upgrading.

Thanks. That helps.