Open shen-tian opened 6 years ago
Sorry for my long delay; I missed this message. I'm not actively working with Firebase right now, so I don't have much to add to your analysis. Have you gotten further in thinking about this?
It's been a while, but worth an update. This particular behaviour has caused quite a few bugs in our system in the last few month. We are dealing with it by explicitly checking for subscriptions deref-ing to []
. This doesn't solve the "actually []
case, of course, but works in our system.
My apologies. It will be at least another few weeks before I will be able to look at this project.
This is to do with the behaviour of the
on-value
sub:Right now, if the realtime db looked like this:
@(subscribe [:fireabase/on-value {:path [:foo :bar]}])
first take the value[]
when the subscription is first created, and then, once fetched from server, give"x"
.@(subscribe [:fireabase/on-value {:path [:foo :baz]}])
first take the value[]
when the subscription is first created, and remains that way as the empty array is fetched.@(subscribe [:fireabase/on-value {:path [:foo :qux]}])
first take the value[]
when the subscription is first created, and remains that way as it's detected as missing.The first case, where we know the data to be present, and not
[]
, works fine for things like "loading" screens (i.e. Nine state of design stuff).The second case doesn't work, as nothing changes between "loading" and "loaded and empty". We can avoid this in db schema design (i.e. use maps not vectors?).
The third case is more tricky, because you can't tell between "loading" and "missing".
Any ideas on how to proceed? I suspect that changing the default value on this line from
[]
to something else (::pending
?) could be a solution, but would be a breaking changehttps://github.com/deg/re-frame-firebase/blob/216595bab8e392caee1233a6480495d610b7a215/src/com/degel/re_frame_firebase/database.cljs#L63-L66