Removing .attributes and .data

[mhluska]

It gets tedious having to type user.attributes.username, user.relationships.todos.data. Could this library restructure the data to the more user-friendly format user.username and user.todos respectively?

[CodingItWrong]

This would definitely be nicer; I frequently forget to add .attributes in.

I've deferred this decision so far because it takes some thought to add in the translation from JSON:API data format to a more usable format and back. Here's the main API design question I have about this change: (let me know if you have thoughts!)

Right now with the update action you can just pass in a full updated record:

const widget = this.$store.getters['widgets/byId']({ id: 42 });
widget.attributes.title = 'Updated Title';
this.$store.dispatch('widgets/update', widget);

If we change the returned records to be the new flatter format, it would be nontrivial for the update action to know which properties on the object are attributes, which are relationships, etc. I can think of a few ways to handle it:

1. Still require passing in a JSON:API structured object to update, even though the returned records aren't structured that way. In this way it's less of a "pass in the updated record" and more "pass in parameters for the update, structured in the JSON:API format".
2. Give the store intelligence about which properties are attributes, relationships, etc. This would be more work, and might not be possible if you are trying to do an update without previously loading data. It also means that if JSON:API adds support for updating something else in the future other than attributes and relationships (maybe meta? links?) then the library won't automatically support it—I'd need to explicitly add support. But that's probably not a big deal.

Do you think option 1 would be a step in the right direction, so that reads are simpler even though writes are still as verbose? Or would you rather wait for an update until if/when I can come up with a design for option 2?

[mhluska]

Hmm that is a tough call. I can see it being annoyingly difficult to update complex records with option 1. Would the user just have to pass in the fields they want to update?

Option 2 seems to make more sense to me especially if you sync your support of JSON:API with a particular version of the spec. I wish I could give more advice on the best way to implement this.

[ghost]

IMO the library should stay with the JSON:API spec. When you start flattening data you would gain a bit less verbose code but possibly loose the ability to differentiate. Next to that .attributes should still be available for backward compatibility (or you have a breaking change). Which would make a dump of the data in a object have duplicate entries. Taking that in consideration, I think it could become nasty mess.

Edit: Maybe access-functions would be helpful
e.g. user.username() and user.relation('todos')

[R3VoLuT1OneR]

I suggest to look on https://github.com/olosegres/jsona.

This is data formatter for JSON:API that can covert data attributes and relationships to simple model like:

user.username // data.attributes.usrname
user.todos // data.relationships.todos

and deserialize it back to JSON:API format easily.

I think it will be good to add as store config "dataProvider" that will serialize and deserialize from JSON:API JSON format into simple JS Object and back.

I am also working on library that using Jsona as "data formatter" for the requests.
You can look: https://github.com/ScholarshipOwl/jsona-vuex
The data formatter was missing for me so I created new library for my use.

[alex-nextraq]

you could also in theory have getters that return the flattened attributes. this way if you want a simpler way to display data, you could do: this.$store.getters['widgets/byIdFlat']({ id: 42 }); and get the flattened data structure. This wouldn't work for returning updated data, but it could be helpful in providing a simpler way of accessing data.

[CodingItWrong]

FYI, this library will be unmaintained going forward.

If you need new features or fixes, I recommend forking the repo and making changes, or finding an alternate library that meets your needs.