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
@yury-dymov I've found a couple of situations where it would have been useful to still have inside the object the type information from the jsonapi. I propose including it as a special $type attribute, which is guaranteed not to interfere with normal existing attributes, given that the jsonapi spec does not allow $ as a valid character in a member name.
With this change in place build for this jsonapi object
Makes sense? I can make the change and submit a pull request.
Update: my bad, I see that there's already an option to do this. It fits me as it is, and I'll use it. But I'd argue that the use of the name type is not ideal. An object could perfectly have an attribute named type, and this option would override it. Granted, it's an edge case, but it could technically happen.
The text was updated successfully, but these errors were encountered:
@yury-dymov I've found a couple of situations where it would have been useful to still have inside the object the
type
information from the jsonapi. I propose including it as a special$type
attribute, which is guaranteed not to interfere with normal existing attributes, given that the jsonapi spec does not allow $ as a valid character in a member name.With this change in place
build
for this jsonapi objectwould become this:
Makes sense? I can make the change and submit a pull request.
Update: my bad, I see that there's already an option to do this. It fits me as it is, and I'll use it. But I'd argue that the use of the name
type
is not ideal. An object could perfectly have an attribute namedtype
, and this option would override it. Granted, it's an edge case, but it could technically happen.The text was updated successfully, but these errors were encountered: