You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
vartheResource=$.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 serverconsole.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 serverconsole.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 ;)
The text was updated successfully, but these errors were encountered:
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
,pageNumber
andcollection
, 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 havingprop
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.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.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 ;)
The text was updated successfully, but these errors were encountered: