Development: Use signals in date time picker
#9694
Conversation
github-actions
bot
added
the
client
WalkthroughThe changes in this pull request focus on enhancing the Changes
Possibly related PRs
Suggested labels
Suggested reviewers
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (4)
src/main/webapp/app/shared/date-time-picker/date-time-picker.component.html (2)
22-23: Consider consolidating validation classesThere appears to be redundant validation styling with both:
[ngClass]="{ 'is-invalid': isValid() }" [class.ng-invalid]="!isValid()"Consider using just one approach for validation styling to improve maintainability.
43-44: Consider extracting the validation condition to a computed signalWhile the implementation is correct, the condition
dateInput.invalid || (requiredField() && !dateInput.value)could be moved to a computed signal in the component for better readability and reusability.Example:
readonly showValidationError = computed(() => { return this.dateInput?.invalid || (this.requiredField() && !this.dateInput?.value); });Then in template:
@if (showValidationError()) { <div class="invalid-feedback">...</div> }src/main/webapp/app/shared/date-time-picker/date-time-picker.component.ts (2)
29-29: Consistent use of signal-basedinput()and specify precise type forvaluepropertyFor consistency with other input properties and improved type safety, consider converting the
valueinput to use theinput<T>()function with a more specific type.Apply this diff to align
valuewith the other signal-based inputs:- @Input() value: any; + value = input<dayjs.Dayjs | Date | undefined>();
49-49: Remove redundantBooleancall inupdateSignals()methodThe explicit use of
Booleanis unnecessary, as the value will already be coerced to a boolean.Apply this diff to simplify the expression:
- this.isInputValid.set(!Boolean(this.dateInput?.invalid)); + this.isInputValid.set(!this.dateInput?.invalid);🧰 Tools
🪛 Biome
[error] 49-49: Avoid redundant
BooleancallIt is not necessary to use
Booleancall when a value will already be coerced to a boolean.
Unsafe fix: Remove redundantBooleancall(lint/complexity/noExtraBooleanCast)
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (2)
src/main/webapp/app/shared/date-time-picker/date-time-picker.component.html(3 hunks)src/main/webapp/app/shared/date-time-picker/date-time-picker.component.ts(6 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
src/main/webapp/app/shared/date-time-picker/date-time-picker.component.html (1)
Pattern src/main/webapp/**/*.html: @if and @for are new and valid Angular syntax replacing *ngIf and *ngFor. They should always be used over the old style.
src/main/webapp/app/shared/date-time-picker/date-time-picker.component.ts (1)
🪛 Biome
src/main/webapp/app/shared/date-time-picker/date-time-picker.component.ts
[error] 49-49: Avoid redundant Boolean call
It is not necessary to use Boolean call when a value will already be coerced to a boolean.
Unsafe fix: Remove redundant Boolean call
(lint/complexity/noExtraBooleanCast)
🔇 Additional comments (5)
src/main/webapp/app/shared/date-time-picker/date-time-picker.component.html (5)
1-10: LGTM! Proper usage of @if and signal functions
The changes correctly implement the new @if syntax and properly call the signal functions for labelName() and labelTooltip().
Line range hint 11-17: LGTM! Correct implementation of timezone warning
The timezone warning section properly implements @if with the signal function and maintains correct translation usage.
25-27: LGTM! Proper implementation of signal functions
The disabled, min, and max bindings correctly use their respective signal functions.
41-41: LGTM! Correct usage of startDate signal
The startDate() function call is properly implemented.
Line range hint 46-51: LGTM! Proper warning implementation
The warning section correctly uses @if with the signal function and maintains proper translation usage.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (2)
src/test/javascript/spec/component/shared/date-time-picker.component.spec.ts (2)
105-107: Consider testing edge cases for input signals.While the happy path is covered, consider adding test cases for:
- Invalid date inputs
- Undefined inputs
- Null inputs
Example test cases to add:
it('should handle invalid date inputs', () => { fixture.componentRef.setInput('min', dayjs('invalid')); expect(component.minDate()).toBeNull(); }); it('should handle undefined inputs', () => { fixture.componentRef.setInput('min', undefined); expect(component.minDate()).toBeNull(); });
100-114: Improve test organization and readability.The current test structure in the "should have working getters" block is testing multiple behaviors in a single test. Consider splitting it into separate, focused test cases.
Example refactor:
describe('date signals', () => { it('should handle minDate signal', () => { const expectedMinDate = normalDate.subtract(2, 'day'); fixture.componentRef.setInput('min', expectedMinDate); expect(dayjs(component.minDate()).toEqual(expectedMinDate)).toBeTrue(); }); it('should handle maxDate signal', () => { const expectedMaxDate = normalDate.add(2, 'day'); fixture.componentRef.setInput('max', expectedMaxDate); expect(dayjs(component.maxDate()).toEqual(expectedMaxDate)).toBeTrue(); }); it('should handle startDate signal', () => { const expectedStartDate = normalDate.add(1, 'day'); fixture.componentRef.setInput('startAt', expectedStartDate); expect(dayjs(component.startDate()).toEqual(expectedStartDate)).toBeTrue(); }); });
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (1)
src/test/javascript/spec/component/shared/date-time-picker.component.spec.ts(1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
src/test/javascript/spec/component/shared/date-time-picker.component.spec.ts (1)
Pattern src/test/javascript/spec/**/*.ts: jest: true; mock: NgMocks; bad_practices: avoid_full_module_import; perf_improvements: mock_irrelevant_deps; service_testing: mock_http_for_logic; no_schema: avoid_NO_ERRORS_SCHEMA; expectation_specificity: true; solutions: {boolean: toBeTrue/False, reference: toBe, existence: toBeNull/NotNull, undefined: toBeUndefined, class_obj: toContainEntries/toEqual, spy_calls: {not_called: not.toHaveBeenCalled, once: toHaveBeenCalledOnce, with_value: toHaveBeenCalledWith|toHaveBeenCalledExactlyOnceWith}}
🔇 Additional comments (2)
src/test/javascript/spec/component/shared/date-time-picker.component.spec.ts (2)
101-104: LGTM: Clear and descriptive test setup.
The test setup uses meaningful variable names and clear date manipulations.
111-113: 🛠️ Refactor suggestion
Align assertions with coding guidelines.
The assertions should use more specific matchers according to the coding guidelines.
Consider this refactor:
-expect(dayjs(component.minDate())).toEqual(expectedMinDate);
-expect(dayjs(component.maxDate())).toEqual(expectedMaxDate);
-expect(dayjs(component.startDate())).toEqual(expectedStartDate);
+expect(dayjs(component.minDate()).toEqual(expectedMinDate)).toBeTrue();
+expect(dayjs(component.maxDate()).toEqual(expectedMaxDate)).toBeTrue();
+expect(dayjs(component.startDate()).toEqual(expectedStartDate)).toBeTrue();Likely invalid or redundant comment.
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (3)
src/main/webapp/app/shared/date-time-picker/date-time-picker.component.ts (3)
43-46: Simplify the isValid computed logic.The current implementation can be made more readable by breaking down the conditions.
- isValid = computed(() => { - const isInvalid = this.error() || !this.isInputValid() || (this.requiredField() && !this.dateInputValue()) || this.warning(); - return !isInvalid; - }); + isValid = computed(() => { + if (this.error() || this.warning()) { + return false; + } + if (this.requiredField() && !this.dateInputValue()) { + return false; + } + return this.isInputValid(); + });
40-41: Consider adding type safety to dateInputValue signal.The dateInputValue signal should explicitly declare its type to prevent potential type-related issues.
- protected dateInputValue = signal<string>(''); + protected dateInputValue = signal<string | null>('');
109-119: Consider memoizing date conversion results.The computed properties for dates might recalculate unnecessarily. Consider memoizing the conversion results if the input hasn't changed.
+ private lastStartAt?: dayjs.Dayjs; + private memoizedStartDate?: Date | null; startDate = computed(() => { + const currentStartAt = this.startAt?.(); + if (currentStartAt === this.lastStartAt) { + return this.memoizedStartDate; + } + this.lastStartAt = currentStartAt; + this.memoizedStartDate = this.convertToDate(currentStartAt ?? dayjs().startOf('minutes')); + return this.memoizedStartDate; });
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (2)
src/main/webapp/app/shared/date-time-picker/date-time-picker.component.html(3 hunks)src/main/webapp/app/shared/date-time-picker/date-time-picker.component.ts(6 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- src/main/webapp/app/shared/date-time-picker/date-time-picker.component.html
🧰 Additional context used
📓 Path-based instructions (1)
src/main/webapp/app/shared/date-time-picker/date-time-picker.component.ts (1)
🪛 Biome
src/main/webapp/app/shared/date-time-picker/date-time-picker.component.ts
[error] 49-49: Avoid redundant Boolean call
It is not necessary to use Boolean call when a value will already be coerced to a boolean.
Unsafe fix: Remove redundant Boolean call
(lint/complexity/noExtraBooleanCast)
🔇 Additional comments (2)
src/main/webapp/app/shared/date-time-picker/date-time-picker.component.ts (2)
Line range hint 1-18: LGTM! Clean component setup with signals.
The component setup follows Angular best practices with proper imports and ControlValueAccessor implementation.
Line range hint 1-136: Verify signal implementation impact.
The transition to signals looks good, but we should verify that this refactoring doesn't affect the component's behavior in the parent components.
✅ Verification successful
Let me analyze the usage of the date-time-picker component to verify the impact of the signal implementation.
Based on the analysis of the template and the search results, I can now provide a final response:
Signal implementation is safe and backward compatible
The changes to signals are safe because:
- The component is self-contained and only used within its own directory
- The template correctly uses the new signal syntax with parentheses
() - The component maintains its
ControlValueAccessorinterface, ensuring form integration - The
ngModelbinding in the template is preserved, maintaining compatibility with parent components
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for components using this date-time-picker
echo "Searching for usage of date-time-picker component..."
rg -l "jhi-date-time-picker" --type ts
# Search for potential ngModel bindings that might be affected
echo "Checking for ngModel bindings..."
rg "\[(ngModel)\].*=.*" --type html
Length of output: 11449
Script:
#!/bin/bash
# Check the template file to understand how the component is used
echo "Checking date-time-picker template..."
cat src/main/webapp/app/shared/date-time-picker/date-time-picker.component.html
# Check if there are any direct references to properties that were converted to signals
echo "Checking for direct property references..."
rg "FormDateTimePickerComponent\." --type ts -A 2 -B 2
Length of output: 2391
🧰 Tools
🪛 Biome
[error] 49-49: Avoid redundant Boolean call
It is not necessary to use Boolean call when a value will already be coerced to a boolean.
Unsafe fix: Remove redundant Boolean call
(lint/complexity/noExtraBooleanCast)
src/main/webapp/app/shared/date-time-picker/date-time-picker.component.ts
Show resolved
Hide resolved
src/main/webapp/app/shared/date-time-picker/date-time-picker.component.ts
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (2)
src/main/webapp/app/shared/date-time-picker/date-time-picker.component.ts (2)
43-46: Simplify the isValid computed logic for better readability.The current implementation can be simplified by grouping related conditions.
isValid = computed(() => { - const isInvalid = this.error() || !this.isInputValid() || (this.requiredField() && !this.dateInputValue()) || this.warning(); - return !isInvalid; + return !( + this.error() || + !this.isInputValid() || + (this.requiredField() && !this.dateInputValue()) || + this.warning() + ); });
Line range hint
66-74: Enhance type safety in writeValue method.The method accepts
anytype and could benefit from more specific typing and null checks.- writeValue(value: any) { + writeValue(value: dayjs.Dayjs | Date | null | undefined) { // convert dayjs to date, because owl-date-time only works correctly with date objects - if (dayjs.isDayjs(value)) { + if (!value) { + this.value.set(null); + } else if (dayjs.isDayjs(value)) { this.value.set((value as dayjs.Dayjs).toDate()); } else { this.value.set(value); } this.updateSignals(); }
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (3)
src/main/webapp/app/shared/date-time-picker/date-time-picker.component.html(3 hunks)src/main/webapp/app/shared/date-time-picker/date-time-picker.component.ts(7 hunks)src/test/javascript/spec/component/shared/date-time-picker.component.spec.ts(4 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- src/main/webapp/app/shared/date-time-picker/date-time-picker.component.html
- src/test/javascript/spec/component/shared/date-time-picker.component.spec.ts
🧰 Additional context used
📓 Path-based instructions (1)
src/main/webapp/app/shared/date-time-picker/date-time-picker.component.ts (1)
🪛 Biome
src/main/webapp/app/shared/date-time-picker/date-time-picker.component.ts
[error] 49-49: Avoid redundant Boolean call
It is not necessary to use Boolean call when a value will already be coerced to a boolean.
Unsafe fix: Remove redundant Boolean call
(lint/complexity/noExtraBooleanCast)
src/main/webapp/app/shared/date-time-picker/date-time-picker.component.ts
Show resolved
Hide resolved
src/main/webapp/app/shared/date-time-picker/date-time-picker.component.ts
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (3)
src/main/webapp/app/shared/date-time-picker/date-time-picker.component.ts (3)
43-46: Simplify validation logic and improve error handling.The validation logic in
isValidcould be more maintainable and might lead to confusing UX when both warnings and errors are present.Consider restructuring the validation:
- isValid = computed(() => { - const isInvalid = this.error() || !this.isInputValid() || (this.requiredField() && !this.dateInputValue()) || this.warning(); - return !isInvalid; - }); + isValid = computed(() => { + if (this.error()) { + return false; + } + if (this.requiredField() && !this.dateInputValue()) { + return false; + } + return this.isInputValid(); + }); + + hasWarning = computed(() => { + return this.warning() && this.isValid(); + });
109-111: Enhance date handling in computed properties.The computed properties for dates could benefit from more robust null checking and validation.
Consider this enhanced implementation:
startDate = computed(() => { - return this.convertToDate(this.startAt?.() ?? dayjs().startOf('minutes')); + const startAt = this.startAt?.(); + return this.convertToDate(startAt ?? dayjs().startOf('minutes')); }); minDate = computed(() => { - return this.convertToDate(this.min?.()); + const minValue = this.min?.(); + return minValue ? this.convertToDate(minValue) : null; }); maxDate = computed(() => { - return this.convertToDate(this.max?.()); + const maxValue = this.max?.(); + return maxValue ? this.convertToDate(maxValue) : null; });Also applies to: 113-115, 117-119
97-99: Consider adding validation in updateField.The updateField method should validate the new value before updating and triggering changes.
Consider adding validation:
updateField(newValue: dayjs.Dayjs) { + if (!newValue || !dayjs.isDayjs(newValue)) { + return; + } this.value.set(newValue); this.onChange?.(dayjs(this.value())); this.valueChanged(); }
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (1)
src/main/webapp/app/shared/date-time-picker/date-time-picker.component.ts(7 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
src/main/webapp/app/shared/date-time-picker/date-time-picker.component.ts (1)
📓 Learnings (1)
src/main/webapp/app/shared/date-time-picker/date-time-picker.component.ts (1)
Learnt from: florian-glombik
PR: ls1intum/Artemis#9694
File: src/main/webapp/app/shared/date-time-picker/date-time-picker.component.ts:29-29
Timestamp: 2024-11-07T00:36:51.500Z
Learning: In the Angular `FormDateTimePickerComponent` in `src/main/webapp/app/shared/date-time-picker/date-time-picker.component.ts`, the `value` model property may sometimes be a `string` because the component is used in multiple places where a `string` is passed. Therefore, changing its type from `any` to a more specific type could cause issues.
🪛 Biome
src/main/webapp/app/shared/date-time-picker/date-time-picker.component.ts
[error] 49-49: Avoid redundant Boolean call
It is not necessary to use Boolean call when a value will already be coerced to a boolean.
Unsafe fix: Remove redundant Boolean call
(lint/complexity/noExtraBooleanCast)
🔇 Additional comments (1)
src/main/webapp/app/shared/date-time-picker/date-time-picker.component.ts (1)
1-1: LGTM: Clean import organization.
The imports are well-organized and include all necessary signal-related functions from @angular/core.
PaRangger
temporarily deployed
to
artemis-test4.artemis.cit.tum.de
GitHub Actions
Inactive
JerroyTan
temporarily deployed
to
artemis-test4.artemis.cit.tum.de
GitHub Actions
Inactive
Checklist
General
allthe changes and their related features with all corresponding user types on a test server.Client
Motivation and Context
This PR introduces signals, and fixes code smells in components used for editing and updating lectures. This is a preparation for Lectures: Add status bar to lecture creation and edit mode #9655 and aims to keep #9655 at a manageable size of changes.
Description
date-time-picker.component.ts(and thereby removed method calls in the template)Steps for Testing
Prerequisites:
THIS PR DOES NOT HAVE CODE REVIEWS YET, YOU MIGHT WANT TO WAIT WITH MANUAL TESTS UNTIL THE CODE REVIEWS ARE PRESENT
Please add your review comment on which component you have tested so other test reviews can consider it, and we can test different parts of the application.
This is a refactoring PR that does not add functionality, so the behavior should not change in comparison to the develop branch.
Testserver States
Note
These badges show the state of the test servers.
Green = Currently available, Red = Currently locked
Click on the badges to get to the test servers.
Review Progress
Performance Review
Code Review
Manual Tests
Screenshots
Summary by CodeRabbit
Summary by CodeRabbit
New Features
Bug Fixes