Repository navigation
Feature request: ability to provide all query observable (not only its properties) #770
Description
In the current version of Angularfire2 we can provide a query with observable parameters. Database is requested every time one of these parameters have a new value. I think to provide all query object as observable would be a better approach.
In closed issue #603 I mentioned one of typical use cases: loading calendar events for given period (between two dates). Currently I have to code it as follows:
export class EventsCalendarComponent {
private start$: Subject<string> = new Subject<string>();
private end$: Subject<string> = new Subject<string>();
constructor(private db: AngularFireDatabase) {
db.list('/events', {
query: {
orderByChild: 'date',
startAt: this.start$,
endAt: this.end$
}
}).subscribe(events => {
// update calendar component with events
});
}
filterByPeriod(start: Moment, end: Moment) {
this.start$.next(start.getTime());
this.end$.next(end.getTime());
}
}
Calling the method filterByPeriod causes two immediately consecutive requests are fired and the first of them is irrelevant and useless. For such case the ability to have all the query object observable would solve the problem and we code something this:
export class EventsCalendarComponent {
private query$: Subject<Object> = new Subject<Object>();
constructor(private db: AngularFireDatabase) {
db.list('/events', {
query: this.query$;
}).subscribe(events => {
// update fullcalendar component with events
});
}
filterByPeriod(start: Moment, end: Moment) {
this.query$.next({
orderByChild: 'date',
startAt: start.getTime(),
endAt: end.getTime()
});
}
}
Activity
cartant commentedon Jan 13, 2017
There could be a pretty simple workaround for this. If an
auditTime(0)operator were to be composed after thecombineLatest, only the last of the combined observables within a single turn through the event loop would be emitted.With that in place, calls to subjects like this:
would result in a single query being emitted.
The query results in a network request, so I cannot see how performance would be an issue. And I cannot envisage a situation in which multiple queries within the same event loop turn would be the desired behaviour.
Anyone interested in a PR?
davideast commentedon Jan 13, 2017
@cartant @tomasklima I would definitely be interested in a PR! This isn't the first time someone has requested this feature. As long as we keep backwards compatibility this would be a great feature.
feat(database): adds auditTime for queries
feat(database): adds auditTime for queries
drew-moore commentedon Feb 20, 2017
This issue was closed by #776, no?