https://github.com/dash-os/firebase-listener
🔥 Setup & Manage Your Firebase Listeners 🔥
https://github.com/dash-os/firebase-listener
firebase firebase-database
Last synced: about 2 months ago
JSON representation
🔥 Setup & Manage Your Firebase Listeners 🔥
- Host: GitHub
- URL: https://github.com/dash-os/firebase-listener
- Owner: Dash-OS
- Created: 2017-06-01T18:19:23.000Z (about 9 years ago)
- Default Branch: master
- Last Pushed: 2017-06-01T20:13:59.000Z (about 9 years ago)
- Last Synced: 2025-05-24T23:41:07.417Z (about 1 year ago)
- Topics: firebase, firebase-database
- Language: JavaScript
- Size: 15.6 KB
- Stars: 2
- Watchers: 3
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# firebase-listener
A Utility to assist in the setup and management of your Firebase Refs. Assists with
managing various paths of your database and their events. Assists with common patterns
to provide a refreshing developer experience.
We utility [seamless-immutable](https://github.com/rtfeldman/seamless-immutable) to manage
and detect changes to your refs events so that we can notify you.
Updates are provided using a [PromiseQueue](https://github.com/Dash-OS/promise-queue-observable)
which allows for simple integration with many 3rd party libraries.
> This was designed to make using Firebase with [redux-saga](https://github.com/redux-saga/redux-saga)
> a better experience during our development.
> **Important:** This is NOT stable at this time.
### What About Writing to Firebase?
We use Firebase as a top-down approach - similar to [redux](http://redux.js.org/)
in many ways. Our app never directly modifies the firebase. Instead, we dispatch
actions to [AWS Lambda](https://aws.amazon.com/lambda/) which then "reduces" the event
and updates our database(s) accordingly.
You can still use the ref to update directly if needed. Since switching to the model
described above, things have become much more streamlined and easier to handle.
### Saga Example
Below is a simple example of a saga from [redux-saga](https://github.com/redux-saga/redux-saga)
using this package to listen to a path.
In this case we are registering the firebase events
[child_added](https://firebase.google.com/docs/database/admin/retrieve-data#child-added),
[child_removed](https://firebase.google.com/docs/database/admin/retrieve-data#child-removed),
[child_changed](https://firebase.google.com/docs/database/admin/retrieve-data#child-changed)
-- however, we use the rehydrate configuration to also register a
[once](https://firebase.google.com/docs/database/admin/retrieve-data#section-reading-once)
that will update our listener with the entire contents first. This prevents
the listener from receiving child_added events for every child in the path.
```js
import { createFirebaseListener } from 'firebase-listener'
function* handleFirebaseReady(ref) {
let listener
try {
listener = createFirebaseListener(ref, {
// automatically registers value listener, gets the data, rehydrates with
// the entire contents, then removes it. this helps so your UI doesn't receive
// tons of child_added events needlessly.
rehydrate: true,
// turn on detailed logs
log: 'detailed',
}).events('child_added', 'child_removed', 'child_changed').listen()
while(true) {
// next gets the promise that will resolve with the next event that occurs.
const event = yield call([ this.state.listener, this.state.listener.next ])
yield fork([this, handleFirebaseEvent], event)
}
} catch (e) {
// handle error
} finally {
// cancel the listener? once cancelled, the listener will no longer allow
// any calls to next()
listener.cancel()
}
}
```
### Batched Paths
If you setup many listeners on a single path throughout your app, this module will only
end up registering a single listener. At this time it does not allow different parts of
the app to setup different events for a given listener.
> Setting up a listener on a path that was registered elsewhere includes the listener that
> was already created.
### Logging Events
One of the things that has always been an issue is logging the various events
that occur with the firebase. We wanted a way to really introspect our listeners
and events.
Logging is enabled by adding the `log` parameter when setting up your listener. It
accepts the values of `true`, `false` or `'detailed'`.
When `'detailed'` is specified, extra information will be added to each log. At this
time if the log includes a `snapshot` value (events) then it will include the number of
children. It will also include the events currently registered on the given listener.
##### General Events are Orange
##### Change Events are Green
##### Other Events / Logs are Black
