Remove ViewChild from metadata

[c-harding]

ViewChild will always be null, and so there is no point in mocking it. viewChild.required throws an error in mocked components without this change.

Fixes GH-8634

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 57.14286% with 3 lines in your changes missing coverage. Please review.

Project coverage is 99.93%. Comparing base (0c3837a) to head (995a2ca). Report is 1881 commits behind head on master.

Files with missing lines	Patch %	Lines
...src/lib/mock-component/render/generate-template.ts	33.33%	1 Missing and 1 partial :warning:
libs/ng-mocks/src/lib/common/decorate.queries.ts	75.00%	0 Missing and 1 partial :warning:

Additional details and impacted files

@@             Coverage Diff             @@
##            master    #8771      +/-   ##
===========================================
- Coverage   100.00%   99.93%   -0.07%     
===========================================
  Files          227      227              
  Lines         4935     4938       +3     
  Branches      1147     1149       +2     
===========================================
  Hits          4935     4935              
- Misses           0        1       +1     
- Partials         0        2       +2     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[c-harding]

Hi @satanTime, what’s the effect for other versions? Only __prop_metadata__ is affected, which is not a documented property. Additionally, viewChild would always be falsy for mocked components anyway, because mocked components do not have any of their own elements as children.

[satanTime]

ng-mocks uses many undocumented and monkey patched things.

For a proper PR, you need to provide a proper test which demonstrates the issue and its fix.

Here, I see that mocks which provide own empty views now will return nulls instead of objects, so tests which relied on these empty views will fail despite no change in the code, only due to the update of ng-mocks.

That's what should be avoided, so what worked before should still work afterwards.

[dmitry-stepanenko]

@satanTime signal-based queries have isSignal: true property set. WDYT if we would modify the condition as follows

diff --git a/libs/ng-mocks/src/lib/common/decorate.queries.ts b/libs/ng-mocks/src/lib/common/decorate.queries.ts
index 860983934..f69eb1423 100644
--- a/libs/ng-mocks/src/lib/common/decorate.queries.ts
+++ b/libs/ng-mocks/src/lib/common/decorate.queries.ts
@@ -26,8 +26,11 @@ const generateFinalQueries = (queries: {
   const scanKeys: string[] = [];
 
   for (const key of Object.keys(queries)) {
-    const query: Query & { ngMetadataName?: string } = queries[key];
-    final.push([key, query]);
+    const query: Query & { ngMetadataName?: string; isSignal?: boolean } = queries[key];
+    const isSignalBasedQuery = query.isViewQuery && query.isSignal;
+    if (!isSignalBasedQuery) {
+      final.push([key, query]);
+    }
 
     if (!query.isViewQuery && !isInternalKey(key)) {
       scanKeys.push(key);

That way it should not be considered as a regression for any existing cases while still allowing us to move forward

[c-harding]

@dmitry-stepanenko that sounds promising! I’ve given you write access to this repo, so you’re welcome to edit the PR directly

[dmitry-stepanenko]

awesome, thanks @c-harding. I'll update the branch shortly

[c-harding]

@dmitry-stepanenko Thanks for fixing this! It looks like the coverage is still a little low (I can’t tell why, you have written a test that should cover this).