-
-
Notifications
You must be signed in to change notification settings - Fork 96
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
Feature: Update @computedFrom to support typing #727
Comments
@silbinarywolf Awesome issue. It would be nice if you could help update the typings here https://github.com/aurelia/binding/blob/master/src/aurelia-binding.d.ts#L877 |
I experimented locally with putting this in as so: /**
* Decorator: Indicates that the decorated property is computed from other properties.
* @param propertyNames The names of the properties the decorated property is computed from. Simple property names, not expressions.
*/
export declare function computedFrom(...propertyNames: string[]): any;
/**
* Decorator: Indicates that the decorated property is computed from other properties. Adds compile-time type safety to @computedFrom.
* @param propertyNames The names of the properties the decorated property is computed from. Simple property names, not expressions.
*/
export declare function computedFrom<T>(...propertyNames: Array<keyof T>); However, what I found was that |
There's a thread discussing the problem in detail here: |
Oh nice find. We can come back to this later. One thing we need is to ensure backward compatibility, so it would be export declare function computedFrom<T = any>(...propertyNames: Array<keyof T>); |
Well, the way I've posted above is backwards compatible as well, it just has two-definitions, one without the polymorphic parameter and one with it :) If your version has no backwards compatibility breaks, then I'd go with that :) |
Nice. I didn't notice that. Thought it was for diffing |
I also want to point out that |
The problem with private members can be solved by using an expression instead of class Example {
private secret: string;
@computedFrom<Example>(x => x.hidden)
public get wisperedSecret(): string { return `Psst! ${this.secret}`; }
} As long as the expression is typed inside the scope of the class itself, like above, you can access private members as expected. I'm already using something similar today, where I use a Proxy<> to walk the expression chain to turn it into a string, so it also works with |
@AnorZaken Looks great! 🚀 Do you mind sharing the solution using Proxy<>? |
I'm submitting a feature request
1.7.3
Please tell us about your environment:
Operating System:
Windows 10
Node Version:
v8.11.1
Yarn Version:
1.5.1
Language:
TypeScript 3.0
Current behavior:
We do not get any type safety when using @computedFrom. A few blogs give users a method for extending @computedFrom manually, but why not just make this an upstream feature we can use?
What is the expected behavior?
That @computedFrom can give us type safety out-of-the-box.
https://medium.com/tech-effectory/creating-a-typed-version-of-aurelias-computedfrom-decorator-with-typescript-27219651ecee
Example:
What is the motivation / use case for changing the behavior?
The text was updated successfully, but these errors were encountered: