Please open Telegram to view this post
VIEW IN TELEGRAM
owasp.org
Notice - OWASP API Security Top 10
The Ten Most Critical API Security Risks
💡 Angular Tip
Did you know that VSCode has a built-in Angular profile template which is packed with popular extensions and handy settings out of the box?
📢 VSCode profiles are a great way to setup your development environment easily. It is fully customizable so that you can also share it with your dev team!
https://code.visualstudio.com/docs/editor/profiles#_angular-profile-template
Did you know that VSCode has a built-in Angular profile template which is packed with popular extensions and handy settings out of the box?
📢 VSCode profiles are a great way to setup your development environment easily. It is fully customizable so that you can also share it with your dev team!
https://code.visualstudio.com/docs/editor/profiles#_angular-profile-template
Visualstudio
Profiles in Visual Studio Code
Expand your development workflow with task integration in Visual Studio Code.
Frontend Unit Tests.
🟡 The Gold Standard 🟡
Everyone racing for top coverage.
But reality looks much much different.
When NOT to Write Frontend Unit Tests:
• PoCs/MVPs: Here today, irrelevant tomorrow.
• UI part that is changed a lot: Don't waste your time.
• Experimental features: Can change any minute.
• Basic static components: Not worth it.
• Overwhelming mocking: Value > Effort.
• Deadlines: Especially in startups.
• Limited resources: Business value first/early phase.
• Redundant scenarios: 100% coverage is not the goal.
• Backend is more important: Frontend is changing much more often.
When TO Write Frontend Unit Tests:
• Critical features: Some things just can't fail.
• Complex logic: Once stable of course.
• Reusable components: The Foundation.
• Regression prevention: When it breaks often.
• Set in stone features: Worth the effort.
• Documentation: Tests can be great for that.
• Pre-refactoring: Before embarking on refactoring.
• Integration points: Vulnerable places.
Business Perspective:
• User Focus: E2E reflecting customer experience.
• Cost Efficiency: E2E tests can catch critical bugs.
• Time Savings: Reducing emphasis on unit tests can speed up development cycles.
• Real-world Relevance: E2E tests in near-production environments offer tangible insights.
• Simplified Reporting: E2E results are often more digestible for non-technical stakeholders.
• Coverage Overkill: Extensive unit tests can be redundant with a strong E2E suite.
• Maintenance Overhead: Frontend changes might require frequent unit test updates.
Businesses often lean towards ROI.
E2E tests often provide clearer value.
🟡 The Gold Standard 🟡
Everyone racing for top coverage.
But reality looks much much different.
When NOT to Write Frontend Unit Tests:
• PoCs/MVPs: Here today, irrelevant tomorrow.
• UI part that is changed a lot: Don't waste your time.
• Experimental features: Can change any minute.
• Basic static components: Not worth it.
• Overwhelming mocking: Value > Effort.
• Deadlines: Especially in startups.
• Limited resources: Business value first/early phase.
• Redundant scenarios: 100% coverage is not the goal.
• Backend is more important: Frontend is changing much more often.
When TO Write Frontend Unit Tests:
• Critical features: Some things just can't fail.
• Complex logic: Once stable of course.
• Reusable components: The Foundation.
• Regression prevention: When it breaks often.
• Set in stone features: Worth the effort.
• Documentation: Tests can be great for that.
• Pre-refactoring: Before embarking on refactoring.
• Integration points: Vulnerable places.
Business Perspective:
• User Focus: E2E reflecting customer experience.
• Cost Efficiency: E2E tests can catch critical bugs.
• Time Savings: Reducing emphasis on unit tests can speed up development cycles.
• Real-world Relevance: E2E tests in near-production environments offer tangible insights.
• Simplified Reporting: E2E results are often more digestible for non-technical stakeholders.
• Coverage Overkill: Extensive unit tests can be redundant with a strong E2E suite.
• Maintenance Overhead: Frontend changes might require frequent unit test updates.
Businesses often lean towards ROI.
E2E tests often provide clearer value.
👍1
Angular Munich pinned «Frontend Unit Tests. 🟡 The Gold Standard 🟡 Everyone racing for top coverage. But reality looks much much different. When NOT to Write Frontend Unit Tests: • PoCs/MVPs: Here today, irrelevant tomorrow. • UI part that is changed a lot: Don't waste your time.…»
- Go through the designs (Ask clarifying questions)
- Break down the UI into components, and monitor the SEO.
- Define what data components need / API contracts (request and response payload)
- Analyze the flow of data within the components
- Authentication and authorization (roles and privileges)
- Discuss the security and best practices
- Discuss the rendering and hosting strategies
- Discuss the performance
- Code maintenance and test cases (what all things you want to run in the CI)
- Scalability, Monitoring, logging, A/B, error reporting, and tracing strategies.
While these are some everyday things, the system design interviews are subjective and change according to the requirements.
Please open Telegram to view this post
VIEW IN TELEGRAM
Many #Angular devs overlook this.
Misuse can tank performance.
Better to avoid for these cases:
• Using complex, computationally heavy functions for trackBy.
• When data items are mostly static and don't often get replaced.
• Using in deeply nested *ngFor loops without proper optimization.
• With components where preserving internal state across data changes might lead to unexpected behavior.
Please open Telegram to view this post
VIEW IN TELEGRAM
Directives are powerful in #Angular.
But heavily underused!
Here is a complete list of Built-In Directives!
🔹 Common Directives 🔹
• NgClass - Toggle CSS classes.
• NgComponentOutlet - Instantiate components.
• NgFor & NgForOf - Iterate & render lists.
• NgIf - Conditional template rendering.
• NgOptimizedImage - Optimize image load.
• NgStyle - Set inline styles dynamically.
• NgTemplateOutlet - Insert from TemplateRef.
• NgSwitch, NgSwitchCase, NgSwitchDefault - Conditional content via switch.
• NgPlural & NgPluralCase - Display based on singular/plural logic.
🔹 Forms Directives 🔹
• AbstractFormGroupDirective - Base logic for form group directives.
• CheckboxControlValueAccessor - Interface between Angular forms and checkbox element.
• CheckboxRequiredValidator - Validator ensuring a checkbox is checked.
• DefaultValueAccessor - Default bridge between Angular forms and DOM.
• EmailValidator - Validator for email format.
• FormArrayName - Connects FormArray to DOM.
• FormControlDirective - Links a standalone FormControl to the DOM.
• FormControlName - Links a FormControl in an existing FormGroup to the DOM.
• FormGroupDirective - Links an existing FormGroup to the DOM.
• FormGroupName - Nested FormGroup binding logic.
• MaxLengthValidator - Validator for maximum string length.
• MaxValidator - Validator for maximum number value.
• MinLengthValidator - Validator for minimum string length.
• MinValidator - Validator for minimum number value.
• NgControlStatus - Reflects control status (valid/invalid) in the DOM.
• NgControlStatusGroup - Reflects FormGroup status in the DOM.
• NgForm - Directive that creates a top-level FormGroup instance.
• NgModel - Creates a FormControl from a domain model and binds it.
• NgModelGroup - Groups controls under one form domain model property.
• NgSelectOption - Binds select options to form controls.
• NumberValueAccessor - Binds numeric input value.
• PatternValidator - Validator for regex pattern.
• RadioControlValueAccessor - Binds radio button value.
• RangeValueAccessor - Binds range input value.
• RequiredValidator - Validator ensuring a value is present.
• SelectControlValueAccessor - Binds select dropdown value.
• SelectMultipleControlValueAccessor - Binds multi-select dropdown values.
🔹 Router Directives 🔹
• RouterLink - Navigational directive to support anchor navigation.
• RouterLinkActive - Adds classes to the element when the associated RouterLink becomes active.
• RouterLinkWithHref (Deprecated)- Binds href to the associated RouterLink.
• RouterOutlet - Placeholder directive where the router displays a view.
🔹 Upgrade/Static Directives: 🔹
• UpgradeComponent - Facilitates the use of AngularJS components in Angular templates.
But heavily underused!
Here is a complete list of Built-In Directives!
🔹 Common Directives 🔹
• NgClass - Toggle CSS classes.
• NgComponentOutlet - Instantiate components.
• NgFor & NgForOf - Iterate & render lists.
• NgIf - Conditional template rendering.
• NgOptimizedImage - Optimize image load.
• NgStyle - Set inline styles dynamically.
• NgTemplateOutlet - Insert from TemplateRef.
• NgSwitch, NgSwitchCase, NgSwitchDefault - Conditional content via switch.
• NgPlural & NgPluralCase - Display based on singular/plural logic.
🔹 Forms Directives 🔹
• AbstractFormGroupDirective - Base logic for form group directives.
• CheckboxControlValueAccessor - Interface between Angular forms and checkbox element.
• CheckboxRequiredValidator - Validator ensuring a checkbox is checked.
• DefaultValueAccessor - Default bridge between Angular forms and DOM.
• EmailValidator - Validator for email format.
• FormArrayName - Connects FormArray to DOM.
• FormControlDirective - Links a standalone FormControl to the DOM.
• FormControlName - Links a FormControl in an existing FormGroup to the DOM.
• FormGroupDirective - Links an existing FormGroup to the DOM.
• FormGroupName - Nested FormGroup binding logic.
• MaxLengthValidator - Validator for maximum string length.
• MaxValidator - Validator for maximum number value.
• MinLengthValidator - Validator for minimum string length.
• MinValidator - Validator for minimum number value.
• NgControlStatus - Reflects control status (valid/invalid) in the DOM.
• NgControlStatusGroup - Reflects FormGroup status in the DOM.
• NgForm - Directive that creates a top-level FormGroup instance.
• NgModel - Creates a FormControl from a domain model and binds it.
• NgModelGroup - Groups controls under one form domain model property.
• NgSelectOption - Binds select options to form controls.
• NumberValueAccessor - Binds numeric input value.
• PatternValidator - Validator for regex pattern.
• RadioControlValueAccessor - Binds radio button value.
• RangeValueAccessor - Binds range input value.
• RequiredValidator - Validator ensuring a value is present.
• SelectControlValueAccessor - Binds select dropdown value.
• SelectMultipleControlValueAccessor - Binds multi-select dropdown values.
🔹 Router Directives 🔹
• RouterLink - Navigational directive to support anchor navigation.
• RouterLinkActive - Adds classes to the element when the associated RouterLink becomes active.
• RouterLinkWithHref (Deprecated)- Binds href to the associated RouterLink.
• RouterOutlet - Placeholder directive where the router displays a view.
🔹 Upgrade/Static Directives: 🔹
• UpgradeComponent - Facilitates the use of AngularJS components in Angular templates.
#angular
Zone.js
• Monitors asynchronous operations.
• Triggers Angular’s change detection post microtask completion.
RootZone (outerZone)
• Foundational zone.
• Provides basic mechanisms to track asynchronous operations.
Forking and Hierarchical Structure
• Zones are hierarchical.
• New zones are created by forking existing zones.
• Child zones inherit behaviours of parent zones.
• Allows for specific behaviours or modifications in child zones.
NgZone (innerZone)
• Specialized zone used by Angular.
• Forked from the root zone.
• Augmented with Angular-specific behaviours.
• Angular tracks changes and runs change detection •within this zone.
Modularity
• Hierarchical structure provides modularity.
• Application-specific behaviours can be introduced in child zones without affecting broader mechanisms.
Please open Telegram to view this post
VIEW IN TELEGRAM
🅰️ Angular tip of the day
Run logic inside the injection context with runInInjectionContext💉
If you want to use the inject function in Angular, you can only use it within the injection context. There are a few ways to get around this, like using closure, but Angular also exposes the runInInjectionContext function, which can be used to run code within the injection context even if it's not inside the injection context.
To know when to use this function you first need to know what the injection context is.
The injection context is available in these situations:
1. Construction (via the constructor) of a class being instantiated by the DI system, such as an @Injectable or @Component.
2. In the initializer for fields of such classes.
3. In the factory function specified for useFactory of a Provider or an @Injectable.
4. In the factory function specified for an InjectionToken.
Within a stack frame that is run in an injection context.
If your logic is not declared in one of these four places, you can use runInInjectionContext if you need to run it in the injection context anyway.
#Angular
Run logic inside the injection context with runInInjectionContext💉
If you want to use the inject function in Angular, you can only use it within the injection context. There are a few ways to get around this, like using closure, but Angular also exposes the runInInjectionContext function, which can be used to run code within the injection context even if it's not inside the injection context.
To know when to use this function you first need to know what the injection context is.
The injection context is available in these situations:
1. Construction (via the constructor) of a class being instantiated by the DI system, such as an @Injectable or @Component.
2. In the initializer for fields of such classes.
3. In the factory function specified for useFactory of a Provider or an @Injectable.
4. In the factory function specified for an InjectionToken.
Within a stack frame that is run in an injection context.
If your logic is not declared in one of these four places, you can use runInInjectionContext if you need to run it in the injection context anyway.
#Angular
👍1
🥷🥷 #angular Template-driven forms Best practices 🥷🥷
🚀 Ensure unidirectional dataflow 🚀
Don't use ([ngModel)] but [ngModel]
🚀 Treat your form models as completely partial 🚀
(Angular creates your form partially over time)
🚀 Don't put your validators in your templates 🚀
Use model validations with @vestjs for instance
🚀I f you need to validate multiple controls or groups, put them in a parent group 🚀
If you need to validate 2 children, put the validation on their parent, that's where the validator belongs
🚀 Use declarative ViewModels 🚀
They keep the template clean
They are more reactive than imperative actions on valueChanges
🚀 Validate your schema's with schema validation 🚀
Template-driven forms are not typesafe by default, you can throw runtime errors in development.
🚀 Ensure unidirectional dataflow 🚀
Don't use ([ngModel)] but [ngModel]
🚀 Treat your form models as completely partial 🚀
(Angular creates your form partially over time)
🚀 Don't put your validators in your templates 🚀
Use model validations with @vestjs for instance
🚀I f you need to validate multiple controls or groups, put them in a parent group 🚀
If you need to validate 2 children, put the validation on their parent, that's where the validator belongs
🚀 Use declarative ViewModels 🚀
They keep the template clean
They are more reactive than imperative actions on valueChanges
🚀 Validate your schema's with schema validation 🚀
Template-driven forms are not typesafe by default, you can throw runtime errors in development.