-
Notifications
You must be signed in to change notification settings - Fork 92
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
feat: support ngOnChanges with correct simpleChange object within rerender #366
feat: support ngOnChanges with correct simpleChange object within rerender #366
Conversation
see #370 |
72e5e9a
to
f0077e8
Compare
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.
Thanks, I like the change!
I just left a few remarks.
I was also thinking if this could be a breaking change 🤔 what do you think?
I thought about that as well and I am not sure: From my React-based experiences this now works as expected. We also don't need to change any existing test assertions. So regarding semantic versioning my gut feeling is a fix. I went with feature, as now testing of But if e.g. someone spies and asserts numbers of calls of a functions, which gets called in constructor, his tests would now fail, as constructor isn't called again in So it's probably most consumer friendly to defensively declare a breaking change? 🤔 |
@shaman-apprentice I kind of want this to be a feature as well. The next breaking would remove the other two methods + upgrade to DOM v9. |
Do you want to deprecate the methods in a new PR @shaman-apprentice ? |
Here it is: #371 In case it is less work for you, feel free to directly copy paste any change you like. Otherwise I will glady continue to update. Thanks for all your work and fast replies :) |
@shaman-apprentice if you could rebase this branch against main then we're good to go :) |
Co-authored-by: Tim Deschryver <[email protected]>
5f42708
to
66ba0c7
Compare
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.
Looks good, just one question (sorry 😅)
const newComponentProps = properties?.componentProperties ?? {}; | ||
const changes = updateProps(fixture, renderedPropKeys, newComponentProps); | ||
if (hasOnChangesHook(fixture.componentInstance)) { | ||
fixture.componentInstance.ngOnChanges(changes); |
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.
While looking at this PR I think we should also include componentInputs to ngOnChanges.
We don't do this with the current behavior, but I think that that should be added (in a later PR).
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.
Good point. If this PR would be released without it, and I would use componentInputs in rerender, I probably would create a bug for it. If you agree I would already add it in this PR.
} | ||
renderedPropKeys = Object.keys(newComponentProps); | ||
|
||
fixture.componentRef.injector.get(ChangeDetectorRef).detectChanges(); |
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.
Could you also provide a parameter for this?
With render
we can disable detectChanges, I suppose some tests would also require this with rerender
.
Thoughts?
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.
Have I understood the concept correctly with 4c5a255?
I have mixed feelings about it. I want help to provide a nice helpful library. On the other side I am not sure it is a good idea to disable change detection of a component. I just assume the component under test has a design flaw when this is helpful. Or I am just lacking imagination of good use cases.^^
I will gladly take a look into it. Not sure I will mange this weekend but I will come to it. |
Np, take your time @shaman-apprentice I'm grateful for these contributions 🤗 |
fixture.componentRef.injector.get(ChangeDetectorRef).detectChanges(); | ||
if ( | ||
properties?.detectChangesOnRender === true || | ||
(properties?.detectChangesOnRender === undefined && detectChangesOnRender === 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.
Do you think we need this check to use the existing config?
I didn't think of it, and I assumed it would only use the property passed to this function.
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.
My first intuition is to respect the initial flag from render unless explicit overwritten in rerender. But my personal goal is to never use any of those two flags - so I have no real opinion here ;) Should I only check for properties?.detectChangesOnRender === 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.
Yea that's my personal goal as well 😅
I would only check for the properties if you don't mind.
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.
done with d218907
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.
Thanks for your work on this @shaman-apprentice ! ❤️
feat: support ngOnChanges with correct simpleChange object within rerender
close #365
any feedback or changes are highly appreciated :)