-
Notifications
You must be signed in to change notification settings - Fork 18
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
Comments
@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 |
Fine, agree
Any particular reason why prefer 2 instead of 1? Just want to understand the reasons. Theoretically 1 simpler to implement and understand. |
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 |
For sake of POC we'll add meta in adapter now manually. Let's decorate Metadata decoration protocol example: this.classes.push('info');
this.meta.set('symbols', ['info']); |
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 standardprimitive
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.The text was updated successfully, but these errors were encountered: