-
Notifications
You must be signed in to change notification settings - Fork 63
Conversation
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.
Just some questions about implementation that confused me/one potential improvement to make the code more explicit and understandable... but otherwise works great locally and the code looks good too. Nice work! LGTM 🚀
}, | ||
/** | ||
* Fetches related audios on `audioId` change | ||
* @param props |
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.
Generally I think we'd still give props
a type of object
(at least that's what we did in Gutenberg, not sure if it's actually necessary):
* @param props | |
* @param {object} props |
* @param props | ||
* @param {string} props.audioId | ||
* @param {any} props.service | ||
* @return {{audios: (Ref<UnwrapRef<[]>>|Ref<AudioDetail[]>)}} |
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 find it helpful to add some extra spacing so these types don't run together and are more readable
* @return {{audios: (Ref<UnwrapRef<[]>>|Ref<AudioDetail[]>)}} | |
* @return {{ audios: (Ref<UnwrapRef<[]>> | Ref<AudioDetail[]>) }} |
What does Ref<UnwrapRef<[]>>
do? UnwrapRef
sounds like something that should be passed a Ref
itself, not passed to a Ref
but I'm uneducated on this at the moment.
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.
Thank you for spacing suggestions, this way JSDoc comments look consistent with the codebase.
As for Ref<UnwrapRef<[]>>
, it was an auto-generated type annotation, and it's most likely incorrect, I will remove it. Thank you for spotting it!
computed: { | ||
errorMessage() { | ||
return this.$t('media-details.related-error') | ||
}, |
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.
What's the reason to create a computed
definition for this rather than inlining the call to $t
in the template?
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.
It was probably from the previous implementation where we added a media type to the message, and the $t
expression looked really long. But with a more generic message here, it is absolutely unnecessary :)
src/composables/use-related.js
Outdated
// fetch and fetchState are available as this.$fetch and this.$fetchState | ||
// in components, so there's no need to export them | ||
// eslint-disable-next-line no-unused-vars |
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 think it would make more sense to still return the fetchState
. Relying on the implicitly created $fetchState
in the components is actually kind of confusing now that useFetch
isn't even being called directly in the setup function. It might make a little more sense if useRelated
was named useFetchRelated
, because at least then where the $fetchState
was coming from would be slightly more easy to investigate to a new-comer... but the easiest to understand would just be an explicit fetchState
returned from the function and consumed in the component. That way there's absolutely 0 magic or obfuscation happening and someone reading the code and draw directly to the specific place the fetch state comes from.
Also... how would this work if there are multiple calls to useFetch
? Do they just get magically merged into one magic $fetchState
variable somehow? Or would that create a complication?
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 comment was based on the Nuxt Composition API's useFetch documentation:
$fetch and $fetchState will already be defined on the instance - so no need to return fetch or fetchState from setup.
I understand the confusion that this magic creates, but I also think it might be better to follow the advice of the library creators. Would adding a comment to the useFetch
documentation and renaming the composable to useFetchRelated help?
Nuxt's fetch hooks already have this magic within them: If you have a fetch hook in your component, you can access the $fetchState
object in the component, and it is probably not easy to understand where it comes from without knowing about Nuxt
's fetch
hook.
When I try returning fetch
and fetchState
, and using them in the component, they seem to work, but my editor complains...
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.
It's so strange that they would recommend relying on that magic! But if that's what the library authors think is best then I agree we can follow it. No need to rename it I guess, just an education thing!
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.
Looks good. I appreciate the use of Nuxt's fetch
hook, especially with the composition API.
Fixes
Related to #280 by @obulat
Description
This PR replaces the Vuex related store with a Vue composition API composable
useRelated
, and uses it in theRelatedAudios
andRelatedImages
components.The data about RelatedMedia is only used in one component, so it is not necessary to keep it in the global Vuex state. However, the data fetching logic is similar for different media types. This is why this PR uses the Composition API's composable to abstract the logic, while keeping the state local to the specific media type component. The
useRelated
composable is using@nuxtjs/composition-api
'suseFetch
to display the fetching state and errors.Testing Instructions
To try different fetching states, you can edit the
getRelatedMedia
'sdata/audio-service
:for error state,
if (config.dev) {throw Error('Server error')}
for pending state,
Checklist
Update index.md
).main
) or a parent feature branch.Developer Certificate of Origin
Developer Certificate of Origin