Comments (5)
After thinking about it a bit more, I think the code is correct as-is, but the docs need to be updated. It needs to be clear that you can either specify the type when not using a serializer OR specify the type in the serializer. I can't think of a use case where you'd need to do both. I will close after I get a chance to update the docs.
from ja_serializer.
I agree that what you're trying to do make sense and it does seem like specifying the type in the parent serializer should take precedence. Having said that, this is not a use case I've run into before.
I'm curious why the pinned article needs to be a different type though. Based on your example, it seems like a pinned article is the same thing as a regular article, but has a specific relationship to the author. What is the rationale for needing to use a different type for the pinned article? If it truly is a different type, maybe it makes sense to have two different views as you proposed in your first solution.
from ja_serializer.
Looking around the code, found that type
is indeed something that can be defined on HasOne relation definition. But, find_type in ResourceIdentifier ignores it. Thought of maybe changing the resource identifier to do:
defp find_type(_data, _context, %{type: type}) when type != nil, do: type
# and then the rest of current implementation
This would work, but not sure how (yet) it would affect the rest of the system. And I have no solution for rendering type in included object. As far as I can tell, ResourceObject also ignores the type in relationship definition.
from ja_serializer.
I have a couple solution that work:
Duplicate logic in another view
defmodule AuthorView do
has_many :articles,
serializer: ArticleView,
link: :articles_url
has_one :pinned_article,
serializer: PinnedArticleView,
link: :pinned_article_url
end
defmodule ArticleView do
end
defmodule PinnedArticleView do
end
This works, but requires duplication of logic between those two views. I mean, I can get around duplication via use CommonStuff
or something similar, but it is a bit ugly.
Handle type in ArticleView
defmodule AuthorView do
has_many :articles,
serializer: ArticleView,
link: :articles_url
has_one :pinned_article,
serializer: PinnedArticleView,
link: :pinned_article_url
end
defmodule ArticleView do
def type(_, conn) do
if conn.request_path =~ "pinned" do
"pinned-article"
else
"article"
end
end
end
This one introduces coupling to paths used, so not a good idea either.
from ja_serializer.
Hmmm, good point! I assumed that relationship name determines type in a way. Mostly because if felt odd to have to search for included article
even though relation was pinned-article
. But you are correct. Lookup in included should rely on type and ID from relation section, so it is OK to have it be different from relation name. OK, that also solves the problem, thank you 😄 Feel free to close this or leave open, given how type
can still be defined on parent serializer (maybe that does not make sense?).
from ja_serializer.
Related Issues (20)
- Considering migrating to Jason? HOT 4
- How to get a custom attribute value formatter to work properly. HOT 4
- Remove Poison dependency
- Can not start app without poison
- Association links instead of data HOT 2
- phoenix 1.4.4 app errors due to Poison being required despite trying to use Jason HOT 3
- Omitting prev/next links when higher than total page number
- Offer camelCase keys
- Links won't use the page_base_url HOT 7
- Optional json-api version member ? HOT 4
- cannot use relationship named `location` HOT 1
- Using JaSerializer.PhoenixView results in no function clause matching in Plug.Conn.resp/3 HOT 2
- EctoErrorSerializer doesn't render errors from relationships and embedded objects HOT 4
- deep_format_keys implementation & mix release duplication error HOT 3
- Missing documentation for testing Phoenix controller responses HOT 2
- Serializer not loaded relationships model HOT 4
- Sparse field param for function based attribute breaks HOT 3
- Should links be output for an empty relationship? HOT 3
- Is it possible to use ja_serializer with a newly generated Phoenix 1.7.7 app? HOT 12
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ja_serializer.