I have a component like

(defn component [visible?]
  [re-com/modal-panel
   :visible? visible?
   :child [...]])

Q #1: should that be :visible? @visible?

I'm just rtying to remember myself

Q #2: are you saying there that [...] is something like [:div @(subscription [:blah]) "Hello"]

1. :visible? is wrapped with re-com.util/deref-or-value inside re-com/modal-panel, and has :type "boolean | atom" spec. 2. Exactly.

I find point 2 odd.

There's definitely a @ before it, right?

Sure!

Assuming yes, the act of creating the hiccup data structure should cause the subscription to be created and then dereferenced.

Are users of re-frame supposed to keep the state, events, subs and views separated from each other, or is that fine if they decide to group them for each of their 'component' ?

@vincent.cantin opinions differ :-)

Watever means that you can easily find what you want. Or, more to the point, whatever means the person after you can easily find the right handlers.

@mikethompson Yeah, the subscription is definitely created. I just can't see it in the re-frame/trace window.

Is it a layer 2 subscription?

Perhaps you have that tickbox on top right of subscriptions panel?

The tickbox which asks re-frame-trace to filter out unchanged layer 2 subscriptions

Layer 3. Actually, now I see it, but I have to refresh the page with the trace panel opened. So, I guess it's just misunderstanding on my side - the trace panel doesn't actually trace anything when it's not opened, right?

Correct

I just got used to the old behavior. 🙂 Thanks!

Are there any plans to also show raw subscriptions?

You mean: show subscriptions created via reg-sub-raw?

Aha.

We haven'tgiven it much thought

You'll need to create an issue

How are you finding re-frame-trace other than that?

Apart from reg-sub-raw capture, is there any thing else that you'd like to see?

It's great! I really like how it evolves.

I've got to go off for dinner. But drop any notes in here.

Hello. Does anyone have problems like Uncaught Error: ["unrecognized request format: " nil]? I'm trying to send AJAX request like this:

(re-frame/reg-event-fx
 :test1
 (fn [{db :db} & _]
   {:http-xhrio {:method :post
                 :uri "/api"
                 :timeout 8000
                 :request-format (transit-request-format {:type :json})
                 :response-format (transit-response-format {:type :json})
                 :on-success [:test1-success]
                 :on-failure [:test1-failure]
                 }}))

[ajax.transit :refer [transit-request-format
                                       transit-response-format]]

Where is the right place to listen to keyboard events on the document in a figwheeled re-frame app ?

Should I ask this kind of question here or on Stackoverflow?

@vincent.cantin 1) You might try to add event listener in core, as document is global object in JS (parent of html element) and it should be always available. And your handler fn should do re-frame.core/dispatch 2) If no one helps here or help is ineffective, ask on SO 🙂

@vincent.cantin by core I mean init function

I am wondering if in fact that would not be better for the community to post questions on SO directly. - It helps build a searchable knowledge base. - It brings visibility on the language and library.

when working on app development, you should then be able to change the behaviour of an event handler by changing the re-frame event handler respectively

@vincent.cantin not sure about the right place, it's rhetorical question 🙂 also, I'm not sure if there're well-defined "correct places" or approaches for every need (though it'd be cool if so)

i.e. personally I have an impression that you still need to experiment yourself

I would say that SO is definitely a better place for well-defined questions.

UPD: I've solved my issue from above by changing :request-format to :format. Need to RTFM more 🙂

hey, sorry if this is a question asked all the time, but searches didn't really turn up anything. i'm writing an app with a lot of independent widgets: i.e., they have their own parts of the app-db and don't really interact with others, and there are many of them. is there a best practice for organizing code for situations like this? so far i've been keeping all the subs, events, views, etc. for each widget in a single file per component, which seems nice, but i'm wondering if there might be some downsides i'm not aware of yet

been doing that for a while, no downsides yet. though I always use fully qualified keywords and alias the ns from the outside

(ns something.example.slider)
(reg-event-fx ::next...)

(ns something.core
  (:require [something.example.slider :as slider])
(rf/dispatch [::slider/next]...)

@joelsanchez remember that you can use synthetic namespaces. The namespace doesn't have to exist for it to be used in a keyword: (rf/dispatch [:i-just-made-this-up/next])

i know, but i want to ensure that the ns is required

i do something which might be controversial from what I've read 🙂 instead of declaring subscriptions everywhere that just get a path from the db, I did an universal subscription and use that instead

(defn- normalize-where [where]
  (if (keyword? where)
    [where]
    where))
(rf/reg-sub
 ::db
 (fn [db [_ where]]
   (get-in db (normalize-where where))))