Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simplify resource interface if possible #39

Open
giosh94mhz opened this issue Jan 26, 2015 · 0 comments
Open

Simplify resource interface if possible #39

giosh94mhz opened this issue Jan 26, 2015 · 0 comments

Comments

@giosh94mhz
Copy link

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:

  1. 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.
  2. 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.
  3. 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 ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

1 participant