Spike: property access

[ajtucker]

path_first, path_all, hash key [:some_key] access and direct property access have differing semantics, e.g. direct property access seems to raise an exception if a property isn't available in the JSON vs. path_first which will just return nil.

We want to allow the use of type signatures in a separate Gem to effectively annotate the dynamically created types with expected properties, so may be able to introspect at run-time, or else create some abstract classes in order to determine whether direct property access using the respond_to_missing? and method_missing functions.

Direct property access seems to not be used much in RP, but we should look at other project(s) that use this library to see whether they just use path_first and path_all.

Extra points for using dry-monads.

[ajtucker]

I've added a test that exhibits this behaviour difference. For RP Applications, fetching a PBO application and looking for a marketingName property, item.path_first('marketingName') returns nil (as there's no value for this property), whereas item.marketingName raises a NoMethodError.

When creating the sapi application/instance, we pass a reference to the sapi application YAML and this is used to load the "endpoint specification" YAML files under the endpointSpecs directory. Currently, this will ignore the model.yaml file, as the type: model is not in the list of endpoint types.

We want to load this model.yaml file and parse out the global properties and the properties applicable to each class, so that when we get a JSON response back, we can determine whether a property is allowed on the class/object (as given by the @type). We should probably include the transitive subclasses too.

We could also parse out the optional, multi etc. fields to figure out whether to e.g. raise an exception when a required value isn't present, or return a Maybe (for zero-to-one optional properties) or a list/array (for zero-to-many) or some clever monad for lists that must have at least one element.

[joescottdave]

For Food Alerts Editor and data dot food editor, I've gone for everything being a required field, with null for single values, empty arrays for lists, and at least one example of a list that must contain at least one, that instantiates with a blank version of that thing.

Ian always used to talk a lot about some pattern where each class had its own "null" variant, but I'm not sure if it had a name or how to implement it.

[ajtucker]

For Food Alerts Editor and data dot food editor, I've gone for everything being a required field

How do you know what the fields are: you create a class listing the fields you know about for a given @type?

The idea in this ticket is to glean the list of fields from the model.yaml file at run-time so that instead of checking the returned JSON for a key (field/property) which may not be there if there's no value, we can check the pre-parsed list of properties for the given @type.

Ian always used to talk a lot about some pattern where each class had its own "null" variant, but I'm not sure if it had a name or how to implement it.

This could well be the monad pattern from functional programming. E.g.
https://www.npmjs.com/package/typescript-monads has Maybe where values are either none<T> or maybe<T> for some type T.

[ajtucker]

For Food Alerts Editor and data dot food editor, I've gone for everything being a required field

How do you know what the fields are: you create a class listing the fields you know about for a given @type?

The idea in this ticket is to glean the list of fields from the model.yaml file at run-time so that instead of checking the returned JSON for a key (field/property) which may not be there if there's no value, we can check the pre-parsed list of properties for the given @type.

Ian always used to talk a lot about some pattern where each class had its own "null" variant, but I'm not sure if it had a name or how to implement it.

This could well be the monad pattern from functional programming. E.g.
https://www.npmjs.com/package/typescript-monads has Maybe where values are either none<T> or maybe<T> for some type T.

[joescottdave]

I hand wrote the types from what I could infer from the data and corrected them when something new arose, so they're far from safe. I also use Plain JavaScript Objects and not classes, because Vue's reactivity system cannot track the changes to values returned by class methods.

JavaScript classes also break when you're using server-side rendering, because they need to be "rehydrated" client-side