criteria facade - part I

kukeiko commented 1 year ago

What: Plain Old JavaScript Objects as the Criteria

When declaring an endpoint you have to supply the "Shape" of Criteria that this endpoint supports. If a Query is issued; if its Criteria match that Shape, the endpoint is invoked with those (strongly typed) Criteria. However, the Criteria the user receives are class instances. It would be more convenient (and better to reduce public API surface) if they could make use of Plain Old JavaScript Objects instead. It would also help in reducing complexity of the Criteria classes, as they would no longer need to carry the strongly typed information with them (which is of 0% relevancy for internal code).

Similarly, the user also provides plain old JavaScript objects when specifying their criteria of a query, with all the same benefits.

Notes

This is a good opportunity to give the whole Criteria implementation a polishing pass.

related: #106

Task List

[x] remove old Criteria code (including cleaning up Endpoints)
[x] remove inline instantiations of newly introduced Criteria/CriteriaShape factories
[x] use new Criteria code for endpoints (that should also fix music-box app bug where you have to select smth. in each dropdown to get results)
[x] consider removing the ShapeType + ShapeTypeInstance types in entity-criteria-shape - if not removed, clean them up
[x] remove related playgrounds
[x] move all interface type guards from every interface file to the respective tools
[x] I added some "isX()" type guards to the schema interfaces - use that everywhere instead of checking .schemaType property

kukeiko commented 1 year ago

related: #106

kukeiko commented 4 weeks ago

continued in #222, splitting up to close #208

kukeiko / entity-space