re-frame

Gabriele Lippi 2025-06-27T10:04:49.729389Z

Hello, I'm sorry if it was already asked or if it's a basic thing that I just ignore, but I was wondering if an event like this :re-frame-event [:submit/sync-assignees (317 716 191)], where a list is passed as argument to the event handler could cause any bug at re-frame level. Thanks

p-himik 2025-06-27T10:25:09.498719Z

A list by itself should not be an issue. A lazy collection might be - depends on what's going on when it generates new items. But it's also possible to stumble upon issues when using plain vectors or even values. Although it's not something you'll see if you stick to CLJS data. In particular, if you try to send around React events or DOM nodes you're gonna have a bad time debugging all the issues coming from that.

Gabriele Lippi 2025-06-27T10:31:50.886779Z

I see thanks. About issues with even values, could you expand a bit more? Because we observed that the bug was happening with odd values and we found that weird

p-himik 2025-06-27T10:59:31.277609Z

Hmm, my knowledge might be a bit outdated actually. It used to be the case that React events were pooled - the same object was reused multiple times. But apparently the practice was stopped in v17. What exactly are the values that are problematic in your case? What's the actual bug?

Gabriele Lippi 2025-06-27T11:04:42.818129Z

the bug is that when we call this event [:submit/sync-assignees (317 716 191)] with three values it fails and we see an error like 191 is not ISeqable but if we call the same event like this [:submit/sync-assignees (317 191) all is good. We firstly discovered the bug when the user pressed a button that was selecting all the values, so we thought it was a select all issue, but then he found out that the issue was there only when the list had odd values.

Gabriele Lippi 2025-06-27T11:05:26.290349Z

We fix the problem changing a bit the code, we now pass a map {:assignee-ids (317 716 191)} and all is good now

p-himik 2025-06-27T11:14:00.596599Z

So it seems that the issue is not with it being a list but with the third item not being a collection. It has something to do with the original implementation of the :submit/async-assignees event handler.

Gabriele Lippi 2025-06-27T11:29:56.118629Z

I'm checking again, I'll keep you posted, thank you again anyway

valerauko 2025-06-27T13:51:53.966939Z

could you be destructuring that list somewhere in your handler?

Gabriele Lippi 2025-06-27T13:57:03.999289Z

unfortunately that's not the case

Gabriele Lippi 2025-06-27T13:58:02.123649Z

my colleague just sent me this snippet

(re-frame.core/reg-event-db :my-event (fn [db [_ x]]))

(comment
  (re-frame.core/dispatch
   [:my-event (list 1 2 3)]))
and it seems that it's the minimum snippet to reproduce the error, do you have the same thing?

p-himik 2025-06-27T14:03:08.399169Z

It works perfectly on my end. What version of re-frame do you use? Where does it come from? Is there perhaps a namespace that shadows re-frame.core with some custom patches?

p-himik 2025-06-27T14:04:15.061689Z

Wait, you use reg-event-db and the event handler returns nothing. So your whole app-db ends up being set to nil. Then maybe something else errors out because of it and tries to report the offending event vector via a mechanism that's broken in some way.

Gabriele Lippi 2025-06-27T14:04:28.399269Z

we are on react-native app built via krell and we're using re-frame 1.2.0

p-himik 2025-06-27T14:05:06.919679Z

Can you try with reg-event-fx? This is how I tested it with re-frame 1.4.3:

(re-frame.core/reg-event-fx ::xxx
  (fn [_ [_ x]]
    (js/console.log 'x x)))

(js/setTimeout (fn []
                 (re-frame.core/dispatch [::xxx (list 1 2 3)])))

p-himik 2025-06-27T14:05:43.272709Z

Does that is not ISeqable error have any stack trace?

Gabriele Lippi 2025-06-27T14:09:52.933509Z

I tried, with a slight change by removing the timeout, and I get the error Error: 3 is not ISeqable

Gabriele Lippi 2025-06-27T14:11:15.625689Z

btw, I lost track of the updates to re-frame, I'm going to update the library to see if it can affect in some way

p-himik 2025-06-27T14:12:44.721319Z

But what's the stacktrace of that error?

Gabriele Lippi 2025-06-27T14:13:41.402719Z

I'm sorry but I'm not sure how could I show you what you are looking for

Gabriele Lippi 2025-06-27T14:13:47.584099Z

this is all I have at the moment

Gabriele Lippi 2025-06-27T14:13:51.020009Z

p-himik 2025-06-27T14:14:28.495939Z

I have no idea what it is. :) When it comes to exceptions, their stack traces are more valuable than even their messages. There must be a mechanism that lets you find it.

Gabriele Lippi 2025-06-27T14:16:12.726969Z

Ok, let me ask to my colleague that has more experience and hopefully I'll come back with something more useful 😅

Gabriele Lippi 2025-06-27T15:20:47.558899Z

in the meantime, updating to version 1.4.3 fixed the problem too

p-himik 2025-06-27T15:21:48.448239Z

Huh, interesting.

p-himik 2025-06-27T15:31:01.268909Z

There must be something else still going on in your app. I don't see anything relevant in the changelog. And I just tried on 1.2.0 - it worked perfectly.

Gabriele Lippi 2025-06-27T15:33:12.190469Z

Honestly it's hard to tell, the app has almost 10 years of code and recently we did a massive refactor moving to krell from figwheel and it's very complicated to untangle things. If I discover more on this I'll definitely update this thread. Thank you a lot for the suggestions and the support anyway

p-himik 2025-06-27T15:33:56.174719Z

Figuring out how to get full stack traces would definitely be my number one priority. :)

🙌 1
Gabriele Lippi 2025-06-27T15:38:35.719469Z

I'm a bit ashamed to tell it, but I don' know how to do that. Hopefully I'll figure it out 😄

valerauko 2025-06-29T21:20:54.176569Z

You could try adding the debug interceptor globally and see if it gives you anything