refactor(core): usage strategy should detect ambiguous query usage #30215
+308
−100
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
devversion
added
action: review
filipesilva
approved these changes
May 7, 2019
kara
added
action: presubmit
|
@devversion Think this should be |
kara
added
the
action: cleanup
devversion
force-pushed
the
static-query-ambiguous-usage
branch
from
c4c9448 to
790f933
Compare
devversion
added
action: merge
|
@kara I'm not sure if it's really considered a fix, but I agree that it's not a refactor either. Renamed to |
alxhub
added
the
action: cleanup
devversion
force-pushed
the
static-query-ambiguous-usage
branch
from
790f933 to
d2dc2f8
Compare
devversion
removed
the
action: cleanup
devversion
force-pushed
the
static-query-ambiguous-usage
branch
from
d2dc2f8 to
eabc4ad
Compare
…ous query usage
Currently we always just set the timing to `false` if we aren't
able to analyze a given call expression or new expression. e.g.
```ts
ngOnInit() {
thirdPartyCallSync(() => this.query.doSomething())
}
```
In that case the `thirdPartyCallSync` function comes from the `node_modules`
and is only defined through types while there is no code for the
actual function logic that can be analyzed. This makes it impossible
to tell whether the given call expression actually causes the specified
arrow function to be executed synchronously or not. In order to be able
to make this better, we now peek into the passed arrow function and
check for a synchronous query usage. If so, we set the query timing to
static and mark it as ambiguous. This ensures that the usage strategy is
less "magical" and more correct with third-party code.
Additionally since functions like `setTimeout` are not analyzable but known
to be asynchronous, there is a hard-coded list of known functions which
shouldn't be marked as ambiguous.
Resolves FW-1214. As planned within https://hackmd.io/hPiLWpPlQ4uynC1luIBdfQ
devversion
force-pushed
the
static-query-ambiguous-usage
branch
from
eabc4ad to
5065c25
Compare
alxhub
pushed a commit
that referenced
this pull request
May 9, 2019
…ous query usage (#30215) Currently we always just set the timing to `false` if we aren't able to analyze a given call expression or new expression. e.g. ```ts ngOnInit() { thirdPartyCallSync(() => this.query.doSomething()) } ``` In that case the `thirdPartyCallSync` function comes from the `node_modules` and is only defined through types while there is no code for the actual function logic that can be analyzed. This makes it impossible to tell whether the given call expression actually causes the specified arrow function to be executed synchronously or not. In order to be able to make this better, we now peek into the passed arrow function and check for a synchronous query usage. If so, we set the query timing to static and mark it as ambiguous. This ensures that the usage strategy is less "magical" and more correct with third-party code. Additionally since functions like `setTimeout` are not analyzable but known to be asynchronous, there is a hard-coded list of known functions which shouldn't be marked as ambiguous. Resolves FW-1214. As planned within https://hackmd.io/hPiLWpPlQ4uynC1luIBdfQ PR Close #30215
BioPhoton
pushed a commit
to BioPhoton/angular
that referenced
this pull request
May 21, 2019
…ous query usage (angular#30215) Currently we always just set the timing to `false` if we aren't able to analyze a given call expression or new expression. e.g. ```ts ngOnInit() { thirdPartyCallSync(() => this.query.doSomething()) } ``` In that case the `thirdPartyCallSync` function comes from the `node_modules` and is only defined through types while there is no code for the actual function logic that can be analyzed. This makes it impossible to tell whether the given call expression actually causes the specified arrow function to be executed synchronously or not. In order to be able to make this better, we now peek into the passed arrow function and check for a synchronous query usage. If so, we set the query timing to static and mark it as ambiguous. This ensures that the usage strategy is less "magical" and more correct with third-party code. Additionally since functions like `setTimeout` are not analyzable but known to be asynchronous, there is a hard-coded list of known functions which shouldn't be marked as ambiguous. Resolves FW-1214. As planned within https://hackmd.io/hPiLWpPlQ4uynC1luIBdfQ PR Close angular#30215
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently we always just set the timing to
falseif we aren'table to analyze a given call expression or new expression. e.g.
In that case the
thirdPartyCallSyncfunction comes from thenode_modulesand is only defined through types while there is no code for the
actual function logic that can be analyzed. This makes it impossible
to tell whether the given call expression actually causes the specified
arrow function to be executed synchronously or not. In order to be able
to make this better, we now peek into the passed arrow function and
check for a synchronous query usage. If so, we set the query timing to
static and mark it as ambiguous. This ensures that the usage strategy is
less "magical" and more correct with third-party code.
Additionally since functions like
setTimeoutare not analyzable but knownto be asynchronous, there is a hard-coded list of known functions which
shouldn't be marked as ambiguous.
Resolves FW-1214. As planned within https://hackmd.io/hPiLWpPlQ4uynC1luIBdfQ