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
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.
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
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?
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.
We fix the problem changing a bit the code, we now pass a map {:assignee-ids (317 716 191)} and all is good now
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.
I'm checking again, I'll keep you posted, thank you again anyway
could you be destructuring that list somewhere in your handler?
unfortunately that's not the case
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?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?
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.
we are on react-native app built via krell and we're using re-frame 1.2.0
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)])))Does that is not ISeqable error have any stack trace?
I tried, with a slight change by removing the timeout, and I get the error Error: 3 is not ISeqable
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
But what's the stacktrace of that error?
I'm sorry but I'm not sure how could I show you what you are looking for
this is all I have at the moment
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.
Ok, let me ask to my colleague that has more experience and hopefully I'll come back with something more useful 😅
in the meantime, updating to version 1.4.3 fixed the problem too
Huh, interesting.
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.
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
Figuring out how to get full stack traces would definitely be my number one priority. :)
I'm a bit ashamed to tell it, but I don' know how to do that. Hopefully I'll figure it out 😄
You could try adding the debug interceptor globally and see if it gives you anything