Scheduler: refactor view model output and sorted Index#30732
Scheduler: refactor view model output and sorted Index#30732Ambrozy merged 8 commits intoDevExpress:25_2from Ambrozy:25_2_view_model_output
Conversation
| import { setupSchedulerTestEnvironment } from './__mock__/m_mock_scheduler'; | ||
|
|
||
| describe('Appointments', () => { | ||
| it('All-day appointment should not be resizable if current view is "day"', async () => { |
There was a problem hiding this comment.
Can you clarify? appointment should not be resizable but in assertion block appointment.classList.contains('dx-resizable') should be resizeble.
Same in test name - Appointment should **not** re-rendered on window resize when width and height have percent value (T1139566) but in the assertion block we are not checking whether it was re-rendered or not. Why was the test renamed this way
There was a problem hiding this comment.
The condition is correct !appointment.classList.contains('dx-resizable'). if appointment resizable it has dx-resizable class. Otherwise no class.
According to Appointment should **not** re-rendered on window resize when width and height have percent value (T1139566). Because new change detection mechanism is better track changes, this cases not trigger rerender anymore. In the ticket user complained to often rerender. S it's become better.
|
|
||
| const compare = (a: Obj, b: Obj): boolean => a.id === b.id && a.name === b.name; | ||
|
|
||
| const getOperations = <T>(items: ReturnType<typeof getArraysDiff<T>>): string => items |
There was a problem hiding this comment.
This is a great finding — it looks like these methods are not only useful for testing, but could also define the API between submodules.
Currently, isNeedToAdd and isNeedToRemove seem somewhat scattered and are used only in tests.
An API that directly states whether an item should be added, left unchanged, or removed would be much more convenient than passing separate flags like needToAdd: true, etc.
As a suggestion for future refactoring, it might be worth applying this approach both in tests and in the submodules’ API to make it consistent and easier to work with.
| const n = a.length; | ||
| const m = b.length; | ||
|
|
||
| const dp: number[][] = Array.from({ length: n + 1 }, () => new Array<number>(m + 1).fill(0)); |
There was a problem hiding this comment.
An n*m array can be quite memory-intensive (and thus impact performance). We could potentially reduce memory usage here.
There was a problem hiding this comment.
The performance tests result:
- 1000 of recurrence appointments in timeline view without virtual scrolling. Before: 5.57s, After: 1.5s
- 100 appointments for 100 resources with virtual scrolling. Before: 1.73s, After: 1.326s
3 participants
No description provided.