Describe the feature or problem you'd like to solve
Ever since Angular Standalone was introduced, I found the boilerplate for overriding components to be a bit tedious.
For example:
const createComponent = createComponentFactory({
component: SomeComponent,
imports: [],
overrideComponents: [
[
SomeComponent,
{
remove: {
imports: [ChildComponent]
},
add: {
imports: [MockChildComponent]
},
},
],
],
});
For many projects I use NG-Mocks to easily create components to override my components, but often I need more than just a mock and want to do some custom logic in there. But it would be nice if we could do the following solution.
Proposed solution
imports: [
MockComponent(ChildComponent, MockChildComponent),
],
In this case when the second parameter is provided, it will do the overriding itself and it prevents me from writing a lot of boilerplate to do it.
For the array of components, perhaps a similar setup could be done by providing an array, but I don't think many people are using that yet, but here's an example:
imports: [
MockComponents(Othercomponent, [ChildComponent, MockChildComponent], AnotherComponent),
],
Additional context
By using this setup, it becomes a lot easier to figure out what role your mocked component is going to play and make the tests use less boilerplate and code to set up.
Describe the feature or problem you'd like to solve
Ever since Angular Standalone was introduced, I found the boilerplate for overriding components to be a bit tedious.
For example:
For many projects I use NG-Mocks to easily create components to override my components, but often I need more than just a mock and want to do some custom logic in there. But it would be nice if we could do the following solution.
Proposed solution
In this case when the second parameter is provided, it will do the overriding itself and it prevents me from writing a lot of boilerplate to do it.
For the array of components, perhaps a similar setup could be done by providing an array, but I don't think many people are using that yet, but here's an example:
Additional context
By using this setup, it becomes a lot easier to figure out what role your mocked component is going to play and make the tests use less boilerplate and code to set up.