This is much more like an RFC than an issue. First, let me say that this library is already very good. I think that you'll find my feedback useful.
When dealing with resources with other library or ad-hoc ajax call, we usually do something like:
var theResource = $.getFromServerSomehow({id: 3});
console.log("loaded resource with id: " + theResource.id);
We generally assume that what is returned from the server is a Resource as the server defines it. With Hateoas and Hyperagent on the other side, the result is a "surrogate" object, which let you "rebuild" the intended resource.
For example if I have a collection with count, pageNumber and collection, I need to access the variable this way:
// var theResource = lazy loaded from server
console.log("count", theResource.props.count);
console.log("pageNumber", theResource.props.pageNumber);
console.log("collection", theResource.embedded.collection[0].props.id);
This may be simplified IMO to:
// var theResource = lazy loaded from server
console.log("count", theResource.count);
console.log("pageNumber", theResource.pageNumber);
console.log("collection", theResource.collection[0].id);
I know that this may be complex to implement, but IMO will increase productivity and (guessing mode: on) popularity.
Here' my suggestion:
- invert the logic of
prop. Instead of having prop for the end-user, the Resource classes should have a _prop which track the internal status which must be considered private by the end-user.
- embedded resources can be used both as properties (with a simple accessor as in point 1) or by the
relation evaluation. The former method is more convenient (see the example above), but will break if the server decide to not inline the resource. The latter method is more stable in term of server changes, but require the end-user to use promises.
- Link will be link anyway. :)
I'm looking forward for your feedback! And, if you ever decide to go this way, I promise I'll help you with the implementation or testing ;)
This is much more like an RFC than an issue. First, let me say that this library is already very good. I think that you'll find my feedback useful.
When dealing with resources with other library or ad-hoc ajax call, we usually do something like:
We generally assume that what is returned from the server is a Resource as the server defines it. With Hateoas and Hyperagent on the other side, the result is a "surrogate" object, which let you "rebuild" the intended resource.
For example if I have a collection with
count,pageNumberandcollection, I need to access the variable this way:This may be simplified IMO to:
I know that this may be complex to implement, but IMO will increase productivity and (guessing mode: on) popularity.
Here' my suggestion:
prop. Instead of havingpropfor the end-user, the Resource classes should have a_propwhich track the internal status which must be considered private by the end-user.relationevaluation. The former method is more convenient (see the example above), but will break if the server decide to not inline the resource. The latter method is more stable in term of server changes, but require the end-user to use promises.I'm looking forward for your feedback! And, if you ever decide to go this way, I promise I'll help you with the implementation or testing ;)