This lifts the player options logic from Next Cloudinary, which should basically reflect Nuxt and Svelte.
This allows us to maintain a single set of configuration options for the player that will support each framework that creates a similar CldVideoPlayer component.
As of now, I left out className and id as returned options as the function's intent is to return "player options", which would be invalid values for the player. This in come cases could cause unintentional side effects, so opting to not return those.
A potential solution would be to return an object, with player options as a property, but i'm leaning towards it being an unintuitive return shape given the name of the function. Open to thoughts on this.
As far as where this module is located, I opted to include it in /url-loader with the idea being that the family of component support functions could live under that package and in a future major release, we could rename it to something more appropriate for all. I'm open to other ideas / suggestions on this.
Issue Ticket Number
Fixes #154
Type of change
[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Fix or improve the documentation
[ ] This change requires a documentation update
Checklist
[ ] I have followed the contributing guidelines of this project as mentioned in CONTRIBUTING.md
Description
This lifts the player options logic from Next Cloudinary, which should basically reflect Nuxt and Svelte.
This allows us to maintain a single set of configuration options for the player that will support each framework that creates a similar CldVideoPlayer component.
It would work as such:
You can see some examples inside of the tests.
As of now, I left out
className
andid
as returned options as the function's intent is to return "player options", which would be invalid values for the player. This in come cases could cause unintentional side effects, so opting to not return those.A potential solution would be to return an object, with player options as a property, but i'm leaning towards it being an unintuitive return shape given the name of the function. Open to thoughts on this.
As far as where this module is located, I opted to include it in
/url-loader
with the idea being that the family of component support functions could live under that package and in a future major release, we could rename it to something more appropriate for all. I'm open to other ideas / suggestions on this.Issue Ticket Number
Fixes #154
Type of change
Checklist
Description
Issue Ticket Number
Fixes #
Type of change
Checklist