Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Telling the difference between a loading data, [], and, missing data #28

Open
shen-tian opened this issue Oct 31, 2018 · 3 comments
Open

Comments

@shen-tian
Copy link
Contributor

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]))))

@deg
Copy link
Owner

deg commented Feb 3, 2019

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?

@shen-tian
Copy link
Contributor Author

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.

@deg
Copy link
Owner

deg commented Jul 17, 2019

My apologies. It will be at least another few weeks before I will be able to look at this project.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants