WIP: Serialization handling for cacheability#44
WIP: Serialization handling for cacheability#44olivermack wants to merge 4 commits intoapi-platform:mainfrom
Conversation
…into a JSON-serializable POJO tree and back to an `Api` graph.
|
Can anyone help me to get the idea here? I'm not that much into flow and I'm just curious about the linter errors: obviously the linter requires to specify the readable properties in the class definition - but most of the classes here do not really have those property definitions; instead, the properties are defined on runtime via In the serializer of this PR I make use of the three dots for rest and spread... Basically for one reason: I only want to extract those parameters from the objects where the serializer needs to perform special actions - by this I was hoping to keep the stuff as flexible as possible when in comes to changes of the properties of the objects. Any hints? I mean, why is then using flow at the end when the values are set magically in the object's constructors anyway? Why not setting those typed type ApiOptions = {
title?: string,
// ...
};
export default class Api {
entrypoint: string;
options: ApiOptions;
constructor(entrypoint: string, options: ApiOptions = {}) {
this.entrypoint = entrypoint;
this.options = options;
}
} |
|
Can you also check why the tests are failing please? It looks related to this change. |
|
@dunglas thanks for checking. It's actually not the tests themselves that fail (as far as I can assess) it's the linter that struggles because I'm spreading member variables from the api-objects which are dynamically declared... this is actually what my last comment was about. |
|
Hey... any news? I still need to know how to proceed here. |
|
Sorry for the lack of response. We’ll try to review ASAP. Having Travis green is mandatory. |
Yah, sure, no question... This is what my initial question was about which I cannot solve on my own... |
This is for #43
This adds an
ApiSerializerwhich converts to a json-serializable POJO in both directions. Please let me know if this approach conflicts with any best practices or design considerations of this lib.Best