@p-himik you've been involved in a fairly long-running series of questions (I've not followed all the ins and outs). Have they all been answered? I'm happy to have a go at answering anything you feel is unresolved if you want to re-pose the question.

@mikethompson Let me think... 1. re-com implements most components as (fn [& {:keys [...]}] ...). How is it better than (fn [{:keys [...]}] ...)? 2. I did have a few questions about subs, but I think they essentially boil down to one. Is there anything wrong with (r/reaction (or @(subscribe [:a]) @(subscribe [:b])))? If there's nothing wrong, I suppose there should be something with

(let [a (subscribe [:a])
      b (subscribe [:b])]
  (r/reaction (or @a @b)))

Answer to 1. Hmm. Its all a while ago, and I don't remember all the reasoning for the decision. It would take a while to swap it back into memory. Perhaps this ... go to the docs/demo: https://re-com.day8.com.au/ and look for "Introduction" / "Uses Named Parameters " There some explanation on the right hand side.

Answer to 2. There's nothing "wrong" with your suggested:

(let [a (subscribe [:a])
      b (subscribe [:b])]
  (r/reaction (or @a @b)))

Regarding parameters - so it appears that the only advantage over a plain (non-varargs) map is that if you don't specify any parameters at all, you don't have to put an empty map there. But there're disadvantages - like the absence of neat automatic formatting and the need to use apply concat when you need to pass these arguments somewhere down the line without unpacking. Regarding subs - if :a always resolves to true, how will :b be disposed of if it's never dereferenced?

Okay, back to Answering 1 I seem to remember we went for this approach because we wanted to minimise the amount of syntax (braces of various kinds). We prioritized the cleanness of code, the ease with which the code can be laid out and read. I think that was it. I appreciate that others may prioritise other aspects of the design, but that was important to me. I, for example, love Python's significant whitespace, because it minimise the "noise" of brackets. Shrug.

The view part of our code is by FAR the most voluminous. So we wanted maximum cleanness on that side.

I think that was the thinking.

Agree about Python. Although habitually pressing a button to autoformat current file in my copy of re-com leads to a disaster this way. 🙂

I haven't been doing much ClojureScript coding recently, but we use Cursive and we don't have any formatting disasters (that I've been told about). All seems to work. This might just be a tools thing.

I use Cursive as well. It just doesn't understand that [view-fn :arg1 val1] needs to be treated as a function. Its author promised to think about it though.

Hmm. Not sure. Like I said, noone ever seems to have a problem in our team.

Back to answering 2, Yes, you are right. The :b will not be "disposed of" if :a is True. Some related discussion here: https://github.com/Day8/re-frame/issues/218#issuecomment-252470445 You are effectively highlighting "Corner Case #2" Using: 1. reg-sub often takes away the problem (this you probably already know, but worth repeating, just in case) 2. embedding subscriptions in Form-1 is the other part to taking away the problem (which is what the linked-to issue is exploring)

Thanks for confirming. My current concern with subs is that I have two subs, and the second depends on the value of the first one most of the time. The issue is that the second sub is really complicated (a completely rewritten sub from subgraph), so I can't just compose their functions. So, I was using

(r/reaction (let [v @(subscribe [:a])]
              (when (check v)
                @(subscribe [:b v])))

Sure. I wrote reg-sub precisely because there were some subtleties within using raw reactions.

I'm open to a docs PR which adds more info/warnings to the current descriptions of reg-sub-raw

Will keep in mind. 🙂 Thank you!

no problem

I am new to re-frame and not quite sure how to build a user authentication/authorization system with it. From what I gathered I should create an auth interceptor and place my auth logic inside :before section then inject the interceptor into every events reg-event-db and reg-event-fx that I want to protect. Am I on the right track?

That sounds good as far as it goes, but I’m a little leery about doing auth stuff on the client side, since a hacker will just spy on your client and then call directly to your server. If you’re doing auth checks on the client just to avoid wasted trips to the server, that’s fine, but the server needs to implement the real protection.

@manutter51 for sure, it's just to visibly hide the parts that aren't accessible for the logged in user - not for security

Yeah, that’s cool then. I’m not sure I’d use an interceptor for showing/hiding stuff. I’d just have the server return a set of roles for the current user once they’ve logged in, and then have some code like

(defn restricted-widget [] 
  (let [roles-set (rf/subscribe [:current-user-roles])]
    (if (:can-view @roles-set)
      [:div.admins-only ...)))

That’s head-code, please disregard any bugs/typos 😉

The reason I’d prefer that approach is so when I come back in a few weeks and have no clue what I was thinking when I wrote it, I can just read the code and see that “oh, I’m only displaying this div if the current user has :can-view in their current user roles.”

Actually, I don’t think you’d need to put interceptors on your events (?), assuming you’re hiding anything that might dispatch “illegal” events anyway. But that’s me assuming, so disregard as appropriate for your particular use case.

@manutter51 Thank you, that makes a lot of sense actually. I will give it a try.