Schpaa 2021-03-18T15:45:33.005900Z

What would trigger something like this:

router.cljc:204 Uncaught #error {:message "Unexpected compile spec type", :data {:given nil, :type nil}}
eval @ router.cljc:204
eval @ router.cljc:151
eval @ router.cljc:169
eval @ router.cljc:183
eval @ router.cljc:198
eval @ router.cljc:146
eval @ router.cljc:169
G__54585 @ router.cljc:187
channel.port1.onmessage @ nexttick.js:218

Schpaa 2021-03-18T15:47:04.006500Z

oh my

Schpaa 2021-03-18T15:47:19.006800Z

I used a (comment block) instead of #_ in a vector

Schpaa 2021-03-18T15:47:51.007Z

That was a first

az 2021-03-18T19:09:35.008900Z

Hi all, am I correct in understanding that interceptors are meant to be synchronous? I see examples of pulling from localStorage, but I’m wanting to use the localforage lib which is async. Should I instead be using an effect handler for any async work?

superstructor 2021-03-19T13:30:13.010Z

@p-himik is correct. Just to be clear if it is async state, like get a value from a server or get gps co-ordinates or just an async db, then it needs to be an effect with an on-success/on-failure etc event vectors to dispatch with the result.

az 2021-03-19T22:06:28.010200Z

@superstructor - Thank you, got it!

p-himik 2021-03-18T19:36:58.009Z

Yes, interceptors do their job right when the event is processed. You could make a particular interceptor async, but it's probably not worth it - it would heavily rely on re-frame internals. You could use an effect to set values, but you can't get them back. But why would you want to use localforage in the fist place? The underlying localStorate is not async, meaning that using localforage won't give you any performance benefits and it's exactly like using localStorage + promises + some particular serialization library (since localforage handles more than just strings). You can do all that (without the promises part since you don't need async) with just localStorage and have one dependency less and cleaner code without all the .then.

p-himik 2021-03-18T19:38:38.009200Z

Ah, there's this section that I missed: > includes a localStorage-backed fallback store for browsers with no IndexedDB or WebSQL support So it's not really a local storage thing. Yep, it has been asked before. It's unfeasible to use IndexedDB with re-frame exactly because it's async, and same follows for localforage.

az 2021-03-18T19:52:16.009400Z

Thank you @p-himik for the breakdown. So in general if I must use something async, I should only look at effect handlers? Maybe use something like async-flow-fx or just write handlers and string them together?

p-himik 2021-03-18T19:55:14.009600Z

If it's something effectful, yes. getValue, for example, is not effectful by itself. You could put it into the app-db right in that effect handler though. But in the case of localStorage, I would still rather use it directly, without any wrappers that just make you write more boilerplate.

az 2021-03-18T19:57:13.009800Z

Yes I agree, thank you for bringing this up.