This is to do with the behaviour of the on-value sub:
Right now, if the realtime db looked like this:
{
"foo": {
"bar": "x",
"baz": []
}
}
@(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 change
|
(make-reaction |
|
(fn [] (get-in @app-db [::cache id] [])) |
|
:on-dispose #(do (.off ref "value" callback) |
|
(>evt [::on-value-handler id nil])))) |
This is to do with the behaviour of the
on-valuesub:Right now, if the realtime db looked like this:
{ "foo": { "bar": "x", "baz": [] } }@(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 changere-frame-firebase/src/com/degel/re_frame_firebase/database.cljs
Lines 63 to 66 in 216595b