-
Notifications
You must be signed in to change notification settings - Fork 30
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
Replace links in "fields" with linked to entites from "includes" #181
Replace links in "fields" with linked to entites from "includes" #181
Conversation
## 0.5.0 | ||
|
||
* [#97](https://github.com/contentful-userland/contentful.ex/pull/97) switches underlying http adapter to `tesla` for higher flexibility. Thank you @OldhamMade | ||
* tests against Elixir 1.13 and updates required elixir version to 1.11 | ||
- [#97](https://github.com/contentful-userland/contentful.ex/pull/97) switches underlying http adapter to `tesla` for higher flexibility. Thank you @OldhamMade |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
my markdown formatter removed these, I don't think it needs both a -
and a *
to format correctly
a24a142
to
1c5109c
Compare
- Resolve all link fields found within "items" in an API response, and replace the links with the actual entities if available from the "includes" section of API response. Inspired by https://github.com/contentful/contentful.js/blob/master/ADVANCED.md#link-resolution - Breaking change: 'assets' field on Entry struct is no longer populated. All Assets for an Entry are embedded directly within 'fields' now instead
1c5109c
to
2caf63c
Compare
defstruct [:id, :revision, :version, :created_at, :updated_at, locale: nil, content_type: nil] | ||
defstruct [ | ||
:id, | ||
:revision, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
version wasn't a field I saw documented in the list of common attributes for API entities, and that field was never used in the code, so have removed it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
version
is relatively important for some entities that we have. It's there to deal with possible race conditions - and it has been moved to a header a while back (even though some payloads can still include it).
I am fine dropping it here, since most reading operations don't care about the field either.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good to know, apologies I didn't find any documentation on it, but I must have missed it
Oh wow thanks! Sorry for not being more attentive here, I didn't think that the elixir community was still interested ❤️ All the better and thanks for the effort. It's a holiday weekend in Berlin but I've set myself a reminder to come back to it next week 👌 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh,
I am late - as usual!
First of all - thanks a ton! This is good work and I appreciate it a lot! I will run a test manually tonight and personally, I think this looks quite mergeable to me.
Calling in on @asaaki for a slow motion "NoOOOOooOO" from the sideline <3
CHANGELOG.md
Outdated
@@ -2,83 +2,88 @@ | |||
|
|||
## Unreleased | |||
|
|||
## 1.0.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not really comfortable with immediately going v1 here - although I recognize that this introduces a breaking change so it might be prudent to do so.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, I'd take your direction on this, would you make this version 0.6.0 instead? I guess there's implicit instability in the version being less than 1, but I did recently have an experience with a library introducing a breaking change in a minor version, and it made what should have been a quick/simple update of our dependencies, turn into a protracted debugging task.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean, technically I already crossed the rubicon when I rewrote the lib between 0.1 and 0.2 - I think 0.6.0 would be fine actually, since I'd want more of the Delivery APIs covered for a v1.0.0.
Inspired by https://github.com/contentful/contentful.js/blob/master/ADVANCED.md#link-resolution | ||
""" | ||
@spec replace_in_situ(Entry.t(), map()) :: Entry.t() | ||
def replace_in_situ(%Entry{fields: fields} = entry, %{} = includes) do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While I appreciate the Latin here - replace_locally
or replace_in_position
? Public APIs tend to be hard to rename 😉
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I didn't love this name, it probably is too obscure a phrase. I was struggling to think of a name that doesn't just repeat the name of the module (it started out as LinkResolver.resolve_links
before I realised I was repeating myself). Out of the two options, replace_in_position
feels clearer than replace_locally
, I'm happy to rename to that. An alternative suggestion is replace_links_with_entities
– just re-reading how I described the change in the pull request, this is the phrase I used...maybe that's a sign of that being the most accurate description for this function? What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do like replace_links_with_entities
a lot. It's longer, but it's clear and also bespoke as a function in the API <3
defstruct [:id, :revision, :version, :created_at, :updated_at, locale: nil, content_type: nil] | ||
defstruct [ | ||
:id, | ||
:revision, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
version
is relatively important for some entities that we have. It's there to deal with possible race conditions - and it has been moved to a header a while back (even though some payloads can still include it).
I am fine dropping it here, since most reading operations don't care about the field either.
I noticed one of the CI jobs failed, with this error Code Readability
┃
┃ [R] ↘ The alias `Contentful.Delivery.Entries` is not alphabetically ordered
┃ among its group.
┃ lib/contentful/entry/link_resolver.ex:8:38 #(Contentful.Entry.LinkResolver)
┃ [R] ↘ The alias `Contentful.Entry` is not alphabetically ordered among its
┃ group.
┃ test/contentful/entry/link_resolver_test.exs:6:21 #(Contentful.Entry.LinkResolverTest)
Please report incorrect results: https://github.com/rrrene/credo/issues I'll fix that when I also rename the function as you have suggested. |
@floriank I think I've addressed all your feedback and fixed the ordering of aliases in some files so |
Pull Request Test Coverage Report for Build ad77c37f1c266f4dfa31049beaedc7eacddb3d4e-PR-181Details
💛 - Coveralls |
Yep! I am just on summer vacation right now (without a laptop) but will return on the weekend! (Apologies, bad timing is sort of my specialty 😬) |
Enjoy your vacation 😎! |
Created this to address issue #8, which means it's currently not possible to access any linked entities except Assets through the client (e.g. a linked Entry).
Open to adapting this, based on feedback. I've not made it completely backwards compatible (the previous 'assets' field on the Entry struct is no longer populated), but I have bumped a major version to compensate for this. It could be made backwards compatible, it would just make the code a bit more convoluted in
Contentful.Delivery.Entries.resolve_collection_response/1
and leave a slightly unclear design (as to why assets are treated differently to other links).I'm sure the link resolution code itself could be improved too, I just need fresh eyes on it because I've been looking at it too long.
Summary of changes: