-
Notifications
You must be signed in to change notification settings - Fork 97
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
SweetAlert2 Angular 19 support #271
Conversation
Warning There were issues while running some tools. Please review the errors and either fix the tool’s configuration or disable the tool if it’s a critical failure. 🔧 eslint
/usr/local/bin/yarn: 3: dirname: not found Error: Cannot find module '/yarn.js' Node.js v22.9.0 WalkthroughThis pull request introduces a comprehensive upgrade of the Changes
Possibly related PRs
Suggested Labels
Poem
✨ Finishing Touches
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
CodeRabbit Configuration File (
|
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.
Actionable comments posted: 0
🧹 Nitpick comments (7)
projects/ngx-sweetalert2-demo/src/main.ts (1)
13-15
: Remove trailing comma in.catch()
call
While trailing commas are often acceptable for multiline objects or arrays, here it may look confusing. Consider removing for cleaner readability.- bootstrapApplication(AppComponent, appConfig).catch((err) => - console.error(err), + bootstrapApplication(AppComponent, appConfig).catch((err) => + console.error(err) )projects/ngx-sweetalert2-demo/src/app/app.routes.ts (1)
3-8
: Incremental feature addition
Using lazy-loaded components for/nested
helps keep the initial bundle size smaller. Consider adding a default route or a fallback route for an even smoother user experience.projects/ngx-sweetalert2/src/lib/swal-portal.component.ts (1)
11-12
: Remove redundant standalone property.In Angular 19, the
standalone: false
property is unnecessary as it's the default behavior for components. Consider removing this property to align with current best practices.@Component({ selector: 'swal-portal', template: '<ng-container *ngTemplateOutlet="template"></ng-container>', - changeDetection: ChangeDetectionStrategy.OnPush, - standalone: false + changeDetection: ChangeDetectionStrategy.OnPush })projects/ngx-sweetalert2-demo/src/app/app.config.ts (1)
13-13
: Consider fine-tuning zone.js performance settings.While enabling
eventCoalescing
is good for performance, you might also want to consider additional zone.js optimizations available in Angular 19.- provideZoneChangeDetection({ eventCoalescing: true }), + provideZoneChangeDetection({ + eventCoalescing: true, + runCoalescing: true, + shouldCoalesceRunChangeDetection: true + }),eslint.config.js (1)
16-23
: LGTM! Well-structured ESLint rules with room for improvement.The rules configuration is comprehensive and follows best practices. Consider strengthening the
@typescript-eslint/no-explicit-any
rule to 'error' instead of 'warn' to enforce better type safety.- "@typescript-eslint/no-explicit-any": "warn", + "@typescript-eslint/no-explicit-any": "error",projects/ngx-sweetalert2-demo/src/app/app.component.ts (2)
19-19
: Replace 'any' type with proper type definition.Using
any
type reduces type safety. Consider usingnumber
for the interval handle.- private dynamicTextChunksIntervalHandle?: any; + private dynamicTextChunksIntervalHandle?: number;
Line range hint
29-37
: Improve interval cleanup with OnDestroy implementation.Consider implementing
OnDestroy
to ensure proper cleanup of the interval.-export class AppComponent { +export class AppComponent implements OnDestroy { // ... existing code ... + + public ngOnDestroy(): void { + this.stopDynamicTextRotation(); + }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
yarn.lock
is excluded by!**/yarn.lock
,!**/*.lock
📒 Files selected for processing (24)
angular.json
(5 hunks)eslint.config.js
(1 hunks)package.json
(1 hunks)projects/ngx-sweetalert2-demo/src/app/app-routing.module.ts
(0 hunks)projects/ngx-sweetalert2-demo/src/app/app.component.spec.ts
(1 hunks)projects/ngx-sweetalert2-demo/src/app/app.component.ts
(2 hunks)projects/ngx-sweetalert2-demo/src/app/app.config.ts
(1 hunks)projects/ngx-sweetalert2-demo/src/app/app.module.ts
(0 hunks)projects/ngx-sweetalert2-demo/src/app/app.routes.ts
(1 hunks)projects/ngx-sweetalert2-demo/src/app/nested/nested-routing.module.ts
(0 hunks)projects/ngx-sweetalert2-demo/src/app/nested/nested.component.ts
(1 hunks)projects/ngx-sweetalert2-demo/src/app/nested/nested.module.ts
(0 hunks)projects/ngx-sweetalert2-demo/src/main.ts
(1 hunks)projects/ngx-sweetalert2-demo/src/polyfills.ts
(1 hunks)projects/ngx-sweetalert2-demo/src/test.ts
(1 hunks)projects/ngx-sweetalert2/package.json
(1 hunks)projects/ngx-sweetalert2/src/lib/swal-portal.component.ts
(1 hunks)projects/ngx-sweetalert2/src/lib/swal-portal.directive.ts
(1 hunks)projects/ngx-sweetalert2/src/lib/swal.component.ts
(5 hunks)projects/ngx-sweetalert2/src/lib/swal.directive.ts
(1 hunks)projects/ngx-sweetalert2/src/lib/sweet-alert2.module.ts
(1 hunks)projects/ngx-sweetalert2/src/public-api.ts
(1 hunks)projects/ngx-sweetalert2/src/test.ts
(1 hunks)tsconfig.json
(1 hunks)
💤 Files with no reviewable changes (4)
- projects/ngx-sweetalert2-demo/src/app/nested/nested-routing.module.ts
- projects/ngx-sweetalert2-demo/src/app/app-routing.module.ts
- projects/ngx-sweetalert2-demo/src/app/nested/nested.module.ts
- projects/ngx-sweetalert2-demo/src/app/app.module.ts
✅ Files skipped from review due to trivial changes (3)
- projects/ngx-sweetalert2/src/test.ts
- projects/ngx-sweetalert2/src/lib/swal.directive.ts
- projects/ngx-sweetalert2-demo/src/polyfills.ts
🧰 Additional context used
🪛 Biome (1.9.4)
projects/ngx-sweetalert2/src/lib/sweet-alert2.module.ts
[error] 31-61: Avoid classes that contain only static members.
Prefer using simple functions instead of classes with only static members.
(lint/complexity/noStaticOnlyClass)
🔇 Additional comments (21)
projects/ngx-sweetalert2-demo/src/main.ts (1)
2-4
: Adopted standalone bootstrapping approach successfully
This import sequence aligns with Angular's recommended standalone setup, replacing the olderAppModule
bootstrap flow. Nice implementation!projects/ngx-sweetalert2-demo/src/app/app.routes.ts (1)
1-2
: Good route definitions
Nice use of typed routes, ensuring strong typing and clarity in route configuration.projects/ngx-sweetalert2-demo/src/app/nested/nested.component.ts (2)
2-2
: SweetAlert2 import
ImportingSweetAlert2Module
directly into the component is consistent with the standalone approach and keeps dependencies localized.
5-7
: Renamed selector toapp-
prefix
Adopting a clear prefix for the component follows Angular style guidelines. This enhances maintainability and readability across your codebase.projects/ngx-sweetalert2/src/public-api.ts (1)
7-7
: Verify breaking changes in module configuration.The removal of
Sweetalert2ModuleConfig
export could be a breaking change for consumers who depend on this configuration interface. Please ensure this change is documented in the changelog and migration guide.Let's verify the impact:
projects/ngx-sweetalert2-demo/src/test.ts (1)
1-2
: LGTM! Zone.js import changes align with Angular 19.The separation of zone.js imports into core and testing modules follows the recommended pattern for Angular 19.
projects/ngx-sweetalert2-demo/src/app/app.config.ts (1)
14-21
: LGTM! Well-structured application configuration.The configuration follows Angular 19 best practices with proper setup of routing and module providers. Good use of:
- Component input binding
- Params inheritance strategy
- Root-level SweetAlert2Module configuration
projects/ngx-sweetalert2-demo/src/app/app.component.spec.ts (1)
11-12
: LGTM! Test configuration updated for standalone components.The changes correctly update the test configuration to support standalone components by:
- Moving AppComponent to the imports array
- Adding SweetAlert2Module.forRoot() to the imports
projects/ngx-sweetalert2-demo/src/app/app.component.ts (1)
6-6
: LGTM! Component metadata properly updated for standalone mode.The component configuration is correctly updated with imports and follows Angular naming conventions.
Also applies to: 8-9
projects/ngx-sweetalert2/src/lib/swal-portal.directive.ts (1)
43-44
: LGTM! Directive properly configured for module-based usage.The explicit
standalone: false
declaration aligns with Angular's migration strategy and clearly indicates the directive's integration method.projects/ngx-sweetalert2/src/lib/swal.component.ts (4)
33-34
: LGTM! Explicit standalone configuration.The addition of
standalone: false
aligns with Angular's best practices for explicit component configuration.
124-125
: LGTM! Improved type assertion syntax.The change to use
(keyof SweetAlertOptions)[]
instead ofArray<keyof SweetAlertOptions>
follows modern TypeScript conventions while maintaining the same type safety.
161-165
: LGTM! Enhanced readability with explicit control flow.The switch from ternary operator to if-else block improves code readability without impacting functionality.
308-310
: LGTM! Improved lifecycle hook readability.The conversion from logical AND operations to explicit if blocks in both ngAfterViewInit and ngOnDestroy enhances code clarity while maintaining the same behavior.
Also applies to: 339-341
projects/ngx-sweetalert2/package.json (1)
12-14
: LGTM! Appropriate peer dependency updates.
- Added Angular 19 support while maintaining backward compatibility
- Updated sweetalert2 to a more recent minimum version (11.15.10)
tsconfig.json (1)
7-7
: Verify the impact of TypeScript configuration changes.The addition of
esModuleInterop
improves module compatibility, but please verify that removingdownlevelIteration
doesn't affect iteration behavior in your supported browser targets.Run the following to check the project's browser targets:
✅ Verification successful
Removal of
downlevelIteration
is safe ✅The codebase doesn't use any iteration patterns that would be affected by this change, and the project targets modern browsers (ES2022).
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check browserslist configuration if [ -f ".browserslistrc" ]; then cat .browserslistrc elif [ -f "package.json" ]; then jq '.browserslist' package.json fi # Check for iteration usage in the codebase echo "Checking for iteration patterns that might be affected:" rg -l 'for.*of|\.entries\(\)|\.keys\(\)|\.values\(\)|Symbol\.iterator'Length of output: 369
Script:
#!/bin/bash # Check the actual iteration usage in the service file echo "=== Iteration patterns in service file ===" rg 'for.*of|\.entries\(\)|\.keys\(\)|\.values\(\)|Symbol\.iterator' projects/ngx-sweetalert2/src/lib/swal-portal-targets.service.ts -C 2 # Check for browser targets in various config files echo -e "\n=== Browser targets in tsconfig ===" cat tsconfig.json # Check for polyfills echo -e "\n=== Checking for polyfills ===" fd polyfillLength of output: 1589
package.json (1)
26-33
: LGTM! Comprehensive dependency updates for Angular 19.The updates are consistent and include all necessary dependencies for Angular 19 support. Notable changes:
- Angular core packages updated to 19.1.3
- Build tools updated to 19.1.4
- New ESLint configuration added
- TypeScript updated to 5.7.3
Run the following to verify dependency compatibility:
Also applies to: 37-37, 40-43, 46-48, 56-56, 59-61
✅ Verification successful
✓ Dependencies are correctly configured and compatible
All Angular packages are consistently versioned at ~19.1.3 and TypeScript ~5.7.3 is compatible with Angular 19. No peer dependency conflicts were detected.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for peer dependency conflicts npm ls 2>&1 | grep -i "peer" # Verify TypeScript compatibility with Angular jq -r '.devDependencies["typescript"]' package.json jq -r '.devDependencies["@angular/core"]' package.jsonLength of output: 146
Script:
#!/bin/bash # Get Angular core version from dependencies jq -r '.dependencies["@angular/core"]' package.json # List all Angular package versions for consistency check jq -r '.dependencies | with_entries(select(.key | startswith("@angular/"))) | to_entries[] | "\(.key): \(.value)"' package.jsonLength of output: 422
angular.json (3)
39-43
: LGTM: Lint configuration properly set up for Angular 19.The lint configuration is correctly set up using
@angular-eslint/builder:lint
for both projects, covering TypeScript and HTML files.Also applies to: 148-152
110-121
: LGTM: Serve and extract-i18n targets properly updated.The configuration has been correctly updated to use
buildTarget
instead of the deprecatedbrowserTarget
across all relevant sections.
Line range hint
55-77
: Verify the build configuration works with Angular 19.The build configuration has been correctly updated to use the new application builder and structure required by Angular 19. Key changes include:
- Using
@angular-devkit/build-angular:application
- Updated output path structure
- Array-based polyfills configuration
- Added browser entry point
Let's verify the build configuration:
✅ Verification successful
Build configuration is correctly set up for Angular 19 ✅
The configuration in
angular.json
is properly structured for Angular 19's application builder, with all required fields present and correctly configured. The package.json shows compatible versions of Angular (19.1.3) and build tools. The previous build failure was only due to missing dependencies installation, not configuration issues.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the build configuration works with Angular 19 # Check Angular version npm list @angular/core # Attempt a production build to verify configuration npm run build -- --configuration=productionLength of output: 269
Script:
#!/bin/bash # Check package.json and angular configuration cat package.json echo "---" cat angular.jsonLength of output: 7527
projects/ngx-sweetalert2/src/lib/sweet-alert2.module.ts (1)
Line range hint
31-61
: LGTM: Module structure follows Angular best practices.Regarding the static analysis hint about avoiding classes with only static members: this is a false positive. The
SweetAlert2Module
follows Angular's recommended pattern for feature modules withforRoot()
andforChild()
static methods. This is the standard approach for configurable Angular modules and should not be changed to simple functions.🧰 Tools
🪛 Biome (1.9.4)
[error] 31-61: Avoid classes that contain only static members.
Prefer using simple functions instead of classes with only static members.
(lint/complexity/noStaticOnlyClass)
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.
Actionable comments posted: 2
🧹 Nitpick comments (3)
package.json (1)
49-55
: Consider updating test-related packages.Some testing packages might need updates for better compatibility with Angular 19:
- karma-coverage-istanbul-reporter (3.0.3) is quite old
- Consider switching to the newer karma-coverage reporter instead
Apply this diff to update the test dependencies:
"jasmine-core": "^5.0.0", "jasmine-spec-reporter": "^7.0.0", "karma": "^6.4.1", "karma-chrome-launcher": "~3.1.1", - "karma-coverage-istanbul-reporter": "~3.0.3", + "karma-coverage": "^2.2.1", "karma-jasmine": "^5.1.0", "karma-jasmine-html-reporter": "^2.0.0",projects/ngx-sweetalert2/src/lib/sweet-alert2.module.ts (1)
1-14
: Consider migrating to standalone API.Since this PR aims to support Angular 19 and the demo has been migrated to standalone components, consider migrating this module to use the new standalone API. This would involve:
- Converting components to standalone
- Using dependency injection instead of NgModule
- Utilizing
provideNgxSweetalert2()
function instead of module configurationWould you like me to help generate the standalone API implementation?
projects/ngx-sweetalert2/src/lib/swal.component.ts (1)
40-43
: Remove redundantstandalone: false
property.Since Angular 19 uses
standalone: false
as the default for components, this explicit declaration is unnecessary and can be removed.@Component({ selector: "swal", template: "", changeDetection: ChangeDetectionStrategy.OnPush, - standalone: false, })
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
yarn.lock
is excluded by!**/yarn.lock
,!**/*.lock
📒 Files selected for processing (26)
.prettierignore
(1 hunks).prettierrc
(1 hunks)package.json
(1 hunks)projects/ngx-sweetalert2-demo/src/app/app.component.html
(2 hunks)projects/ngx-sweetalert2-demo/src/app/app.component.spec.ts
(1 hunks)projects/ngx-sweetalert2-demo/src/app/app.component.ts
(1 hunks)projects/ngx-sweetalert2-demo/src/app/app.config.ts
(1 hunks)projects/ngx-sweetalert2-demo/src/app/app.routes.ts
(1 hunks)projects/ngx-sweetalert2-demo/src/app/nested/nested.component.ts
(1 hunks)projects/ngx-sweetalert2-demo/src/environments/environment.prod.ts
(1 hunks)projects/ngx-sweetalert2-demo/src/environments/environment.ts
(1 hunks)projects/ngx-sweetalert2-demo/src/index.html
(1 hunks)projects/ngx-sweetalert2-demo/src/main.ts
(1 hunks)projects/ngx-sweetalert2-demo/src/polyfills.ts
(1 hunks)projects/ngx-sweetalert2-demo/src/test.ts
(1 hunks)projects/ngx-sweetalert2/src/lib/di.ts
(1 hunks)projects/ngx-sweetalert2/src/lib/swal-portal-targets.service.ts
(3 hunks)projects/ngx-sweetalert2/src/lib/swal-portal.component.ts
(1 hunks)projects/ngx-sweetalert2/src/lib/swal-portal.directive.ts
(4 hunks)projects/ngx-sweetalert2/src/lib/swal.component.spec.ts
(3 hunks)projects/ngx-sweetalert2/src/lib/swal.component.ts
(11 hunks)projects/ngx-sweetalert2/src/lib/swal.directive.ts
(5 hunks)projects/ngx-sweetalert2/src/lib/sweet-alert2.module.ts
(1 hunks)projects/ngx-sweetalert2/src/lib/sweetalert2-loader.service.ts
(2 hunks)projects/ngx-sweetalert2/src/public-api.ts
(1 hunks)projects/ngx-sweetalert2/src/test.ts
(1 hunks)
✅ Files skipped from review due to trivial changes (10)
- .prettierignore
- projects/ngx-sweetalert2-demo/src/environments/environment.prod.ts
- projects/ngx-sweetalert2/src/lib/swal.component.spec.ts
- projects/ngx-sweetalert2-demo/src/environments/environment.ts
- .prettierrc
- projects/ngx-sweetalert2/src/lib/sweetalert2-loader.service.ts
- projects/ngx-sweetalert2/src/lib/di.ts
- projects/ngx-sweetalert2/src/lib/swal-portal-targets.service.ts
- projects/ngx-sweetalert2-demo/src/app/app.component.html
- projects/ngx-sweetalert2-demo/src/index.html
🚧 Files skipped from review as they are similar to previous changes (13)
- projects/ngx-sweetalert2-demo/src/app/app.routes.ts
- projects/ngx-sweetalert2-demo/src/polyfills.ts
- projects/ngx-sweetalert2/src/lib/swal-portal.component.ts
- projects/ngx-sweetalert2-demo/src/app/app.config.ts
- projects/ngx-sweetalert2/src/test.ts
- projects/ngx-sweetalert2-demo/src/app/nested/nested.component.ts
- projects/ngx-sweetalert2-demo/src/app/app.component.spec.ts
- projects/ngx-sweetalert2/src/lib/swal.directive.ts
- projects/ngx-sweetalert2-demo/src/main.ts
- projects/ngx-sweetalert2-demo/src/test.ts
- projects/ngx-sweetalert2/src/lib/swal-portal.directive.ts
- projects/ngx-sweetalert2-demo/src/app/app.component.ts
- projects/ngx-sweetalert2/src/public-api.ts
🧰 Additional context used
🪛 Biome (1.9.4)
projects/ngx-sweetalert2/src/lib/sweet-alert2.module.ts
[error] 25-54: Avoid classes that contain only static members.
Prefer using simple functions instead of classes with only static members.
(lint/complexity/noStaticOnlyClass)
🔇 Additional comments (9)
package.json (4)
26-33
: LGTM! Core Angular dependencies are properly updated.All core Angular packages are consistently updated to version ~19.1.3, which aligns with the PR objective of adding Angular 19 support.
40-43
: LGTM! Angular dev dependencies are properly updated.The Angular CLI, build tools, and compiler packages are updated to appropriate versions that match the core Angular packages.
47-48
: LGTM! ESLint and TypeScript updates look good.The addition of ESLint packages and TypeScript 5.7.3 are appropriate for Angular 19.
Also applies to: 61-62
37-37
: Consider updating rxjs to a newer version.While zone.js is correctly updated to ~0.15.0 for Angular 19 compatibility, rxjs 7.5.7 might be outdated. Angular 19 typically works better with rxjs 7.8.x.
Let's verify the recommended rxjs version for Angular 19:
Also applies to: 34-36
projects/ngx-sweetalert2/src/lib/sweet-alert2.module.ts (1)
16-18
: LGTM! Good use of dynamic import.The
provideDefaultSwal
function uses dynamic import, which is great for lazy loading and reducing the initial bundle size.projects/ngx-sweetalert2/src/lib/swal.component.ts (4)
133-134
: LGTM! Improved type assertion syntax.The change to use
(keyof SweetAlertOptions)[]
instead ofArray<keyof SweetAlertOptions>
aligns with TypeScript best practices for array type declarations.
171-175
: LGTM! Improved control flow readability.The changes to use explicit
if
statements instead of ternaries and logical operators improve code readability and maintainability while preserving the same logic.Also applies to: 314-318, 343-348
395-403
: LGTM! Improved code formatting.The formatting changes in the switch statement and consistent use of trailing commas improve code readability and maintain a consistent style throughout the file.
Line range hint
4-457
: Consider adding tests for control flow changes.While the control flow changes improve readability, it would be beneficial to ensure they are covered by unit tests, particularly:
- The
swalVisible
setter's if-else branches- The
ngAfterViewInit
initialization conditions- The
ngOnDestroy
cleanup conditions
@NgModule({ | ||
declarations: [SwalDirective, SwalComponent, SwalPortalDirective, SwalPortalComponent], | ||
imports: [CommonModule], | ||
exports: [SwalComponent, SwalPortalDirective, SwalDirective], | ||
}) | ||
export class SweetAlert2Module { | ||
public static forRoot(options: Sweetalert2ModuleConfig = {}): ModuleWithProviders<SweetAlert2Module> { | ||
return { | ||
ngModule: SweetAlert2Module, | ||
providers: [ | ||
SweetAlert2LoaderService, | ||
{ provide: swalProviderToken, useValue: options.provideSwal || provideDefaultSwal }, | ||
{ provide: fireOnInitToken, useValue: options.fireOnInit || false }, | ||
{ provide: dismissOnDestroyToken, useValue: options.dismissOnDestroy || true }, | ||
], | ||
}; | ||
} | ||
|
||
public static forChild(options: Sweetalert2ModuleConfig = {}): ModuleWithProviders<SweetAlert2Module> { | ||
return { | ||
ngModule: SweetAlert2Module, | ||
providers: [ | ||
...(options.provideSwal | ||
? [SweetAlert2LoaderService, { provide: swalProviderToken, useValue: options.provideSwal }] | ||
: []), | ||
...(options.fireOnInit !== undefined | ||
? [{ provide: fireOnInitToken, useValue: options.fireOnInit }] | ||
: []), | ||
...(options.dismissOnDestroy !== undefined | ||
? [{ provide: dismissOnDestroyToken, useValue: options.dismissOnDestroy }] | ||
: []), | ||
], | ||
}; | ||
} | ||
} |
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.
🛠️ Refactor suggestion
Consider modernizing the module architecture.
The current implementation uses a class with only static members, which could be simplified using modern Angular patterns:
- Replace the static class with standalone functions
- Use proper typing for the configuration
- Leverage Angular's new injection system
Here's a suggested modern approach:
import { makeEnvironmentProviders, EnvironmentProviders } from '@angular/core';
export function provideNgxSweetalert2(options: Sweetalert2ModuleConfig = {}): EnvironmentProviders {
return makeEnvironmentProviders([
SweetAlert2LoaderService,
{ provide: swalProviderToken, useValue: options.provideSwal || provideDefaultSwal },
{ provide: fireOnInitToken, useValue: options.fireOnInit || false },
{ provide: dismissOnDestroyToken, useValue: options.dismissOnDestroy || true },
]);
}
export function provideNgxSweetalert2Child(options: Sweetalert2ModuleConfig = {}): EnvironmentProviders {
return makeEnvironmentProviders([
...(options.provideSwal
? [SweetAlert2LoaderService, { provide: swalProviderToken, useValue: options.provideSwal }]
: []),
{ provide: fireOnInitToken, useValue: options.fireOnInit ?? false },
{ provide: dismissOnDestroyToken, useValue: options.dismissOnDestroy ?? true },
]);
}
This approach:
- Eliminates the need for NgModule
- Provides better type safety
- Aligns with Angular's modern dependency injection system
- Maintains consistent default values
🧰 Tools
🪛 Biome (1.9.4)
[error] 25-54: Avoid classes that contain only static members.
Prefer using simple functions instead of classes with only static members.
(lint/complexity/noStaticOnlyClass)
public static forRoot(options: Sweetalert2ModuleConfig = {}): ModuleWithProviders<SweetAlert2Module> { | ||
return { | ||
ngModule: SweetAlert2Module, | ||
providers: [ | ||
SweetAlert2LoaderService, | ||
{ provide: swalProviderToken, useValue: options.provideSwal || provideDefaultSwal }, | ||
{ provide: fireOnInitToken, useValue: options.fireOnInit || false }, | ||
{ provide: dismissOnDestroyToken, useValue: options.dismissOnDestroy || true }, | ||
], | ||
}; | ||
} |
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.
Fix inconsistent default behavior between forRoot and forChild.
The dismissOnDestroy
default value is true
in forRoot
but effectively undefined
in forChild
. This inconsistency could lead to unexpected behavior when using forChild
.
Apply this diff to align the behavior:
public static forChild(options: Sweetalert2ModuleConfig = {}): ModuleWithProviders<SweetAlert2Module> {
return {
ngModule: SweetAlert2Module,
providers: [
...(options.provideSwal
? [SweetAlert2LoaderService, { provide: swalProviderToken, useValue: options.provideSwal }]
: []),
...(options.fireOnInit !== undefined
? [{ provide: fireOnInitToken, useValue: options.fireOnInit }]
: [{ provide: fireOnInitToken, useValue: false }]),
...(options.dismissOnDestroy !== undefined
? [{ provide: dismissOnDestroyToken, useValue: options.dismissOnDestroy }]
- : []),
+ : [{ provide: dismissOnDestroyToken, useValue: true }]),
],
};
}
Committable suggestion skipped: line range outside the PR's diff.
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.
AMAZING WORK ✨ ✨ ✨
Thank you @FACode <3
🎉 This PR is included in version 13.0.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Congratulations @FACode for the stepping up and @limonte for not having given up too soon! I'm really happy to see my lib live a little longer. One question: is it me or are we still using deprecated APIs for injecting components in Swal Portals ? Did you manage to get the demo running fully? That's how I tested the lib back then, as you can see, I did not write tests at the time (silly me). For me that's the feature that really sets the lib apart and brings things you couldn't normally do! As for me, I'm sorry I haven't be able to find the motivation to maintain it lately, there are many reasons but the main driver is simply that I don't use Swal anymore, since now most UI frameworks (and even browsers) bring their own robust and integrated solutions for modals, while it was something much harder to implement properly back in the days, and Swal served so many people with robust UX and A11y! |
Hey @toverux ✋ Yes, you are right. There are still a few things to improve. The API is deprecated, but I decided to use it like this to support the latest version of Angular asap. Hopefully, I can do the rest of the improvements soon 🔥 |
Small steps and gradual update FTW 🚀 |
In this PR I updated the project to be compatible with Angular 19.
This update was a tricky one so I decided to approach it in a few steps:
Update the project to Angular 17. Even if the ngx-sweetalert2 supported the Angular 17 +, the packages were not updated correctly + the demo project was really behind.
Standalone migration. Here I migrated the demo app to a standalone approach, removed the modules, updated the routes, and imported the ngx-sweetalert2 package in the new way.
Update to Angular 18
Update to Angular 19 - Get rid of the standalone flags + other changes
Check for the other packages to be compatible with our dependencies.
Fixed the tests and updated the linter. I added the new eslint package for linting.
closes #266
closes #268
Summary by CodeRabbit
Dependency Updates
Project Configuration
Library Enhancements
Testing and Development