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

Maintain metadata without changing element type #76

Closed
char0n opened this issue Sep 1, 2020 · 4 comments
Closed

Maintain metadata without changing element type #76

char0n opened this issue Sep 1, 2020 · 4 comments
Assignees
Labels
ApiDOM enhancement New feature or request
Milestone

Comments

@char0n
Copy link
Member

char0n commented Sep 1, 2020

As discussed on slack, we want to achieve having certain elements in ApiDOM with additional metadata (either during creation or during lifecycle), but not having them as higher minim types, but rather keep them as primitives. In order to achieve that we have two strategies:

1.) Extending primitive types without overriding element property

I fancy this solution the most. We just extend the primitive types (subclass it) and in constructors we add the needed metadata. Our predicates will detect those subclases as standard primitive types (I'll refrence to those as subclasses). When minim tree gets serialized into string and deserialized into minim instances again, these subclasses will not be used, because minim will map it's own primitive types. To say it in another way - subclasses are exclusively mechanism used by adapter during initial tree creation.

2.) Using JavaScript constructors to act like factory functions

JavaScript allows us to switch the instance that is being created by the constructor - by returning another value. Effectively the subclass acts like a factory function for creating another element.

Concern:
There is a question if we want to have these decorated primitive elements to have additional behavior (methods, properties) in future. If there is just one case where answer will be yes, then both of these strategies cannot deliver, and the only way to achieve additional behavior is to properly extend minim primitive types and giving them their own element name.

@char0n char0n added enhancement New feature or request ApiDOM labels Sep 1, 2020
@char0n char0n added this to the M7 milestone Sep 1, 2020
@char0n char0n self-assigned this Sep 1, 2020
@frantuma
Copy link
Member

frantuma commented Sep 1, 2020

@char0n about your concerns, I would say the answer is no, and whenever we will need instead additional behaviour then we can properly extend.

Your point 2 would be the best solution for me, at least for POC, to skip overhead of adding specific elements for no other reason

@char0n
Copy link
Member Author

char0n commented Sep 2, 2020

@char0n about your concerns, I would say the answer is no, and whenever we will need instead additional behaviour then we can properly extend.

Fine, agree

Your point 2 would be the best solution for me, at least for POC, to skip overhead of adding specific elements for no other reason

Any particular reason why prefer 2 instead of 1? Just want to understand the reasons. Theoretically 1 simpler to implement and understand.

@frantuma
Copy link
Member

frantuma commented Sep 2, 2020

The idea was that mandating a specific element implementation to add metadata seems a not necessary overhead, as I'd also like such addition to be achievable "easily" for any element/property with the less possible impact on other code; ideally it would be e.g just a line somewhere with no other changes. If we go for 1. I believe this means at least implementing another class/file, and then adjust at least adapter visitors to use this instead of the previous StringElement

@char0n
Copy link
Member Author

char0n commented Sep 2, 2020

For sake of POC we'll add meta in adapter now manually. Let's decorate info and version.

Metadata decoration protocol example:

this.classes.push('info');
this.meta.set('symbols', ['info']);

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ApiDOM enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants