feat(core): Added support for resolving expression functions that return Observables #3744
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.
What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Feature
What is the current behavior? (You can also link to an open issue here)
Expressions that are bound the functions that return Observables are not subscribed to, this is a difficult problem to solve as we don't have access to the return type information without executing the bound function which may have side effects.
#1818 and #2013 , there are workarounds but feel less than ideal in certain situations.
What is the new behavior (if this is a feature change)?
Expression keys that end with a '$' are treated as returning an Observable, this allows us to assume their intention and validate this with the additional index signatures.
$ suffix is typically used to represent Observables within the Angular ecosystem so seems natural to make this assumption within the context of a model.
Please check if the PR fulfills these requirements
npm run build
produced a successful build. (Unit testing can be done by runningnpm test
;)npm run lint
to do this.npm run build
will fail if there are files not linted.)Please provide a screenshot of this feature before and after your code changes, if applicable.
N/A
Other information:
Appreciate this could be a potentially controversial change but I think it'll be beneficial to at least consider the option going forwards, it unlocks alot more consice field extension and feels natural in my opinion and has been requested throughout the years fairly consistently from what I can see.
I've included an additional page within the Guides/Advanced section demonstrating how Observables can be used in relation ot expression properties.
Look forwards to hearing your thoughts!