Skip to content
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

prop decorators defined in a different compilation unit? #27

Closed
hugebdu opened this issue Feb 6, 2022 · 6 comments
Closed

prop decorators defined in a different compilation unit? #27

hugebdu opened this issue Feb 6, 2022 · 6 comments
Assignees
Labels
bug Something isn't working fixed Fix has been merged for this issue
Milestone

Comments

@hugebdu
Copy link

hugebdu commented Feb 6, 2022

Trying to use class prop decorator - works perfect when resides in the same source file with the property being decorated, but if the decorator is imported from another source file, I get Property#decorators empty

@hugebdu
Copy link
Author

hugebdu commented Feb 6, 2022

also capturing decorator args would be really great (primitives & enums)

class Entity {
  @Orm.Id(Orm.IdKind.AutoGenerated)
  id: string;
}

@Hookyns
Copy link
Owner

Hookyns commented Feb 6, 2022

also capturing decorator args would be really great (primitives & enums)

class Entity {
  @Orm.Id(Orm.IdKind.AutoGenerated)
  id: string;
}

This is related with #7

There is no problem to support property decorators and allow them to get type of class via generic type. So it is possible to start from other side from that decorator, with all the runtime arguments of that decorator and get type of class. That's the point in #7.

Your point is good too. If it is constant value, capture it.
So add Decorator.arguments: any[]?

@Hookyns Hookyns added the bug Something isn't working label Feb 6, 2022
@hugebdu
Copy link
Author

hugebdu commented Feb 7, 2022

Decorator.arguments: any[]?

Sounds good 👍

Thanks

@Hookyns Hookyns self-assigned this Feb 10, 2022
@Hookyns Hookyns added in-progress fixed Fix has been merged for this issue labels Feb 10, 2022
@Hookyns
Copy link
Owner

Hookyns commented Feb 10, 2022

Fixed. Will be publish with other bug fixes in next version.

Contains fix of the decorators from different module and getArguments(): Array<any> on decorators.
Arguments must be Literal (string, number, boolean or enum. It can be value from const variable, even imported).
It is possible to allow Object litrals too, but it's a little tricky... I've kept it simple for this time...

import {
	getType,
	reflect
}                     from "tst-reflect";
import { SomeEnum }   from "./SomeEnum";
import { SomeString } from "./SomeType";

const MyString = "SomeType";

function klass<TType>(str: string, num: number, enu: SomeEnum)
{
	console.log("klass", str, num, enu, getType<TType>());
	return function <T>(Constructor: { new(...args: any[]): T }) {
	};
}

function property(str: string, num: number, enu: SomeEnum, any: any)
{
	console.log("property", str, num, enu, any);
	return function (_, __) {};
}

@klass(MyString, 5, SomeEnum.One)
class A
{
	@property("Foo property", 5, SomeEnum.One, { foo: "f", bar: 5, baz: SomeEnum.Two })
	foo: string;

	@property(SomeString, 5, SomeEnum.Two, true)
	get bar(): number
	{
		return 0;
	}
}

Hookyns added a commit that referenced this issue Feb 11, 2022
- new! literal arguments of decorators captured -> Decorator.getArguments(): Array<any>
- decorator can be CallExpression`@decorator()` or (new) just Identifier `@decorator`
- TypeBuilders
- getType(val: any) on runtime value - preparation
- fix of some circular dependencies in runtime package
- Null metadata Store
@Hookyns Hookyns added this to the v1.0.0-alpha milestone Feb 13, 2022
Hookyns added a commit that referenced this issue Feb 13, 2022
### Added
- `getType(val: any)` it is possible to get type of runtime value,

<dl>
<dd>

```typescript
const someValue: unknown = new Animal();
getType(someValue); // > Type<Animal>
```
This works mainly with classes.
Before #29 is implemented, `@reflect()` decorator, `@reflect` JSDoc tag or `getType<OfThatType>()` is required or there will be no Type metadata.

Native types such as Object `{ foo: "", bar: 5 }`, Array `[ {}, true, 5 ]` and primitive types are supported too; those types are recognized and their properties are parsed at runtime.

*Getters and setter of Objects are recognized.*
\
*Classes without metadata will be parsed as Objects.*

</dd>
</dl>

- `Decorator.getArguments(): Array<any>` - constant literal arguments of decorators are captured,
- `Type.isPrimitive()`,
- partial test coverage (~75%) - issue #28,
- `TypeBuilder`,
- decorator can be CallExpression`@decorator()` or (new) just Identifier `@decorator`
- implementation of #7 - custom Property and Method decorators supporting `getType<T>()` of generic parameters, like already supported class decorators.

### Changed
- JSDoc tags @reflectGeneric and @reflectDecorator removed in favor of single @reflect,
- `Property.decorators` changed to `Property.getDecorators()` - to keep it same as `Type.getDecorators()` and `Method.getDecorators()`,
- `Type.flattenInheritedMembers()` support base union and intersection types,
- fixed issue #27,
- fix of some circular dependencies in runtime package,
- few other small bug fixes.
@Hookyns
Copy link
Owner

Hookyns commented Feb 13, 2022

Available from:

tst-reflect@0.7.0-alpha.0
tst-reflect-transformer@0.9.0-beta.2

Version details in CHANGELOG

@hugebdu
Copy link
Author

hugebdu commented Feb 13, 2022

awesome!
thanks @Hookyns

@Hookyns Hookyns closed this as completed Mar 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working fixed Fix has been merged for this issue
Projects
None yet
Development

No branches or pull requests

2 participants