I’m using re-com/single-dropdown with the filter box - is it possible to automatically select the last remaining item in the filtered list? The user could then press Return to select.

Not automatically. Manually, you might be able to setup a keyboard event listener and...hmmm, nah I don't think that would work either because you would have to be privy to the changing state of filtered-choices which is internal

I’ll have to dive into the re-com code then. Thanks.

No probs

A bit of a basic question, maybe someone can help me understand. Suppose I have two comps:

(defn inner [x]
  (let [y @(rf/subscribe [:y])]
    [:div (pr-str (= x y)]))

(defn outer []
  (let [x @(rf/subscribe [:x])]
    [inner x]))

In particular I'm interested in the possibility where the subscription in inner fires before outer, creating a temporary state of (!= x y)

I'm guessing this is impossible, but I'm curious what guarantee there is that you never see this in-between state.

I thought event wise, it would update say x first then y

👀

I don’t understand how you would swap them together i guess

https://github.com/Day8/re-frame/blob/master/docs/EventHandlingInfographic.md

(reg-event-db :inc
              (fn [db _]
                (-> db
                    (update :x inc)
                    (update :y inc))))

as a simple example ^^

righhhht sorry

So that returns the entire app state but with those two values updated

I understand your question now haha sorry

I don’t know the answer to your question but i would guess,

3-4-5-6 Summary
The key point to understand about our 3-4-5-6 example is:

a change to app state ...
triggers query functions to rerun ...
which triggers view functions to rerun
which causes modified browser DOM

I’m interested to know the answer too now 😅

I think there's some guarantee that outer will rerender before inner, but I wonder if it's documented/made explicit somewhere

I’ll have a quick google :thinking_face:

if outer rerenders first, you'll never see a mix of old props, passed in from outer, and new subscription results

So just to be clear, this isnt to do with order of events

but order of re-rendering right?

correct. With my example, app-db will be updated atomically so there won't be a situation where (!= x y)

Ok ill have a google and if i find anything ill ping ya :thumbsup:

FYI, noobs, the re-frame version of this JS/mxWeb app https://kennytilton.github.io/whoishiring/ is here: https://github.com/kennytilton/rehiring

Hi. I'm building an application that must be able to switch between workspaces (ws) - basically, switch among a few paths inside app-db as default data sources for ~80% of all subscriptions and event handlers. An example of app-db.

{:workspaces {:w1 {...}
              :w2 {...}}
 :current-ws :w1
 :some "global data"
 :some-other "global data"}

That’s an interesting problem. I’m not sure I understand what you mean by a :dispatch effect being executed with a different ws. You mean like when switching workspaces, you get a effect running in the new ws that should have been run under the old one? Or is it like you’re staying in Workspace A, but for some reason you need to run an effect in Workspace B without changing the current workspace?

@manutter51 I think the former? Let me give an example. Suppose you have an fx event handler for event :start that returns {:http-xhrio {:on-success [:stop], ...}}. :start is dispatched by a button "Start" and :stop shows the ws it has been dispatched with somewhere in the UI. There's also another button that switches current ws. With this series of events - :w1 is selected - "Start" is pressed - :http-xhrio cofx fires a request - :w2 is selected - :stop is fired by :http-xhrio cofx I want :w1 to be displayed in the UI, despite the fact that by the time it's displayed, current ws has been changed to :w2.

Hmm, we had a similar situation that’s specific to :http-xhrio — we just passed the variable in as the last item of the vector, i.e. {:http-xhrio {:on-success [:stop :w1], ... }}

Yeah, that's the most obvious solution, and the hardest to implement when ws is needed by almost all subscriptions and event handlers.

The third way that comes to my mind would be to rely extensively on macros and to use some special function to create an event vector just so that the macros know what's an event and what's not. But this solution is probably worse than the metadata one because it's harder to implement, strays from "event is just data" approach, harder to debug etc.

I’m not sure I understand why it’s hard to include the current ws in the arg vector?

Maybe it’s just that the :http-xhrio is an easy case, since you’ve got the whole db ready-at-hand when the event handler is running?

It's not hard by itself. But imagine you have hunders of event handlers and hunders of subscriptions. In/for each and every one you will have to: 1. Add an optional (since views generally should not care about current ws) ws argument 2. Check that the ws argument is set 3. If not, set it to the current ws stored in app-db 4. For each effect, make sure to pass ws everywhere. Every :dispatch, :dispatch-n, :on-success, :on-complete, :on-god-knows-what-else. And what if the effects map is composed dynamically? Including all event vectors in there.

It's way more code than required, and it makes it waaay easier to mess things up.

Ok, I see what you’re saying now

Another thing to consider - what if I'm using some libraries that have events that use something like :http-xhrio? Only with the metadata solution will I be able to support such ws switching.

I don’t know if even metadata would work if you had a lib that was calling :http-xhrio for you — you’d need a way to attach the ws to the arg vector for :on-success, and there’d be no way to tell the lib to do that for you.

Dammit, you're right. Previously I was inadvertently thinking about the metadata in the context of completely synchronous effects.

Thinking out loud here: what you’re looking for is a way to do a transactional set of effects, such that :start and :stop can belong to the same transaction, which would somehow also preserve the workspace for the entire transaction

Yeah, pretty much.

I keep thinking of something like a stack, where :start would push the current ws and :stop would pop it off again. But that would be possibly difficult to do in an async setting

You mean a stack per transaction? But how would it help, if even the concept of transactions is not that clear here. If it's a global stack, then how would it help with transactions?

Yeah, I’m kind of throwing out ideas right now to see if I can come up with anything useful

I was thinking a global stack, or maybe some kind of map, like “I’m storing the state for transaction #134” and then the rest of the transaction could look it up

That’s probably a more complicated solution than the problem we’re trying to solve tho 😕

I think that instead of metadata it's also possible to use the context. But it doesn't really change anything, just another implementation. It's still not possible to use this with some thirdparty libraries, but it should be easy enough to create a thin wrapper for them.

Yeah

One other thought I had was maybe a with-ws function

so like {:on-success (with-ws [:stop])}

It's interesting how re-frame makes many things really neat and makes other things rather complicated to implement while staying within the re-frame approach. How would such a function work?

What I would probably do is have a map as the 2nd value in the vector, like {:on-success [:stop {}]}

so if you need to pass extra arguments to :stop, you’d add them to the map. Then with-ws could insert the current ws in as a key like :current-ws inside that map

I like maps because it’s real easy to set up optional arguments that way. Then you could have a matching get-ws function that looks for that key, and just returns the current ws if the key isn’t set

It would work, and I definitely agree on maps, but it's not that different from manually passing ws everywhere.

true, hmm

Have you ever looked at pure-frame?

no, I haven’t

Its approach was to make everything pure - so, no global app-db, you have to pass everything around.

Heh, interesting

chocolatier does something like that for a game engine

Oh, I remember what the other part of the with-ws idea was — you write a custom dispatch function to wrap re-frame.core/dispatch and apply the with-ws to the arg vector

If you’ve got a well-defined convention of having a map as the last value in the vector you’d simplify things a bit

As far as I recall, the author eventually decided that it was too much of a hassle to use such a framework. Aah, that's more like it. But it won't handle :dispatch and :dispatch-n, so you'll still have to reimplement a good chunk of re-frame. 🙂

Yeah, I was thinking the same sort of thing about :on-success. But still, you could do similar: have :my/dispatch and :my/dispatch-n effects

Indeed.

It wouldn’t be too hard to write the effect handlers, and it might be worth the investment if you had to scale it across hundreds of events/subs

That's true. Ok, I really have to go to sleep now - almost 2AM here. Thank you very much for the conversation! It'll definitely help. Hopefully, I'll come up with something in the morning. Have a good day!

Good luck! 🙂