-
Notifications
You must be signed in to change notification settings - Fork 32
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
[libs, ME]: persist records selection #669
Conversation
Angi-Kinas
commented
Nov 2, 2023
- Adds selection service (select records, deselect records, clear selection)
- Uses selection service in record-table
Affected libs:
|
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.
Thanks, this works really well. I made a few comments on the code, I think especially the event names deserve a little bit of clarification. Well done :)
@@ -121,10 +135,15 @@ describe('RecordsListComponent', () => { | |||
describe('when click on a record', () => { | |||
beforeEach(() => { | |||
table.recordSelect.emit({ uniqueIdentifier: 123 }) | |||
table.recordsSelection.emit([{ uniqueIdentifier: 123 }]) |
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.
This deserves a separate test I think there should be a distinction between "clicking on a record" and "selecting a record"
@Output() recordSelect = new EventEmitter<CatalogRecord>() | ||
@Output() recordsSelection = new EventEmitter<CatalogRecord[]>() | ||
@Output() recordsDeselection = new EventEmitter<CatalogRecord[]>() |
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.
I feel like the names of these events will bring confusion. How about:
recordClick
recordsSelect
recordsDeselect
?
handleRecordsSelection(records: CatalogRecord[]) { | ||
this.selectionService | ||
.selectRecords(records) | ||
.pipe(takeUntil(this.onDestroy$)) |
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.
Interesting, that looks like a valid approach to avoid having long-running observables stopping after a component is destroyed. Here though we shouldn't need it as the selectRecords
and deselectRecords
of the service are built on top of HTTP calls, which means they are short-lived observables and will complete after their first emission.
@@ -23,6 +24,7 @@ export class RecordTableComponent { | |||
@Input() records: CatalogRecord[] | |||
@Input() totalHits: number | |||
@Output() recordSelect = new EventEmitter<CatalogRecord>() | |||
@Output() recordsSelection = new EventEmitter<CatalogRecord[]>() |
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.
Is this output really needed? I didn't see any use of it
@@ -23,6 +24,7 @@ export class RecordTableComponent { | |||
@Input() records: CatalogRecord[] | |||
@Input() totalHits: number | |||
@Output() recordSelect = new EventEmitter<CatalogRecord>() |
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.
See my other comment about event names, this might deserve a clarification as well :)
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.
Looking good, thanks!