-
Notifications
You must be signed in to change notification settings - Fork 11
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
External loading anand #2575
base: feat-provide-external-loading-triggers
Are you sure you want to change the base?
External loading anand #2575
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,8 +1,12 @@ | ||
import { Observable } from 'rxjs'; | ||
import { TableColumnConfig, TableFilter, TableSortDirection } from '../table-api'; | ||
|
||
export interface TableDataSource<TResult, TCol extends TableColumnConfig = TableColumnConfig> { | ||
getData(request: TableDataRequest<TCol>): Observable<TableDataResponse<TResult>>; | ||
export interface TableDataSource<TResult, TCol extends TableColumnConfig = TableColumnConfig, TDataTriggers = unknown> { | ||
secondaryDataTriggers$?: Observable<TDataTriggers>; // TBD | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. IMO, this is fine how it is used here. Adding it to watched observables in the data source is sound logic. However, does it give us the intended effect. Do we show a loader while the new data is being resolved? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes. |
||
getData( | ||
request: TableDataRequest<TCol>, | ||
secondaryDataTriggers?: TDataTriggers, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. we should be able to avoid this by making new request happen on a trigger change within the table. Is that something we can do? Getting the triggers as part of data source and then the consumer having to implement some logic dependent on them seems wierd. We should not have to emit filters via these triggers again. These triggers can play the simple role of being signals while the getData method's There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
This is exactly what we are doing. For requests triggered externally, we do need some |
||
): Observable<TableDataResponse<TResult>>; | ||
getScope?(): string | undefined; | ||
} | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we are using
combineLatest
, in terms of emitting the loading state value, it will have affect the same way as 2 subscriptions, one to the existing change observable and one tosecondaryDataTriggers$
.Correct me if I am wrong.