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

[Feature] Allow For Exclusion of Optional Resource Members #312

Open
kyleboe opened this issue Feb 21, 2024 · 5 comments
Open

[Feature] Allow For Exclusion of Optional Resource Members #312

kyleboe opened this issue Feb 21, 2024 · 5 comments

Comments

@kyleboe
Copy link

kyleboe commented Feb 21, 2024

Borrowing from the JSON:API Document Resource Objects:

A resource object MAY contain any of these top-level members:

  • attributes: an attributes object representing some of the resource’s data.
  • relationships: a relationships object describing relationships between the resource and other JSON:API resources.
  • links: a links object containing links related to the resource.
  • meta: a meta object containing non-standard meta-information about a resource that can not be represented as an attribute or relationship.

Ideally, there would be per-View configuration options allowing for exclusion from the returned JSON object. Patterns similar to the remove_links? functionality could be used to conditionally exclude these resource members.

@mattpolzin
Copy link
Member

I imagine the idea is to omit a certain property when it is empty (i.e. unused), or is the goal to sometimes remove populated properties in the response payload?

@kyleboe
Copy link
Author

kyleboe commented Feb 28, 2024

The goal is to remove populated properties to reduce payload size. For example, removing links from nested objects in an index query but maintaining links at the top level for pagination and such.

@mattpolzin
Copy link
Member

So is the goal is to omit based on which View is used or based on something found in the data or Plugn.Conn?

I wonder if this could also be achieved by adding support for nil returns from the existing links, meta, etc. Behavior callbacks for View.

@kyleboe
Copy link
Author

kyleboe commented Mar 4, 2024

Yep exactly.

Yeah that seems like a very viable solution. I'll play around with it locally and see what needs to be adjusted as a result.

Copy link
Contributor

This issue has been automatically marked as "stale:discard". We are sorry that we haven't been able to prioritize it yet.
If this issue still relevant, please leave any comment if you have any new additional information that helps to solve this issue. We encourage you to create a pull request, if you can. We are happy to help you with that.

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

No branches or pull requests

2 participants