-
Notifications
You must be signed in to change notification settings - Fork 35
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
feat: Allow assets to be saved in different locations #281
feat: Allow assets to be saved in different locations #281
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Thanks for the quick reply! |
1feab11
to
acd8322
Compare
This is a clever approach! I like adding the ability to do it while punting a little on what a "real/blessed" DB integration could look like. Looks like we need to update some tests, but I'm positive on this direction as a start this way. I like leaving this PR tight and focused, but it could be nice to follow it up with an example of using it with SQLite or something? |
Yes, that's a good idea. My first implementation will involve calling a backend to save or retrieve all assets, which could serve as an initial example. I have restarted the implementation, focusing on keeping the tests green since I had some issues fixing them. Could you enable the CI so I can review the results? (Locally, I sometimes get inconsistent results) |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #281 +/- ##
==========================================
+ Coverage 90.67% 91.04% +0.37%
==========================================
Files 30 30
Lines 2423 2445 +22
Branches 347 339 -8
==========================================
+ Hits 2197 2226 +29
+ Misses 226 219 -7 ☔ View full report in Codecov by Sentry. |
Ook, the tests are green, I think you can review this... |
const file = await readFile(assetConfigPath); | ||
const asset = JSON.parse(file.toString()); | ||
return asset; | ||
return videoConfig.loadAsset(assetConfigPath) |
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.
(blocking) I think we want the argument here for loadAsset
(and the other new hooks) to be the filePath
variable because we're doing a bunch of things in getAssetConfigPath
that are dependent on videoConfig settings.
Otherwise devs would have to import the getAssetConfigPath
function.
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.
Why devs "devs would have to import the getAssetConfigPath function" ?
The default implementation doesn't use getAssetConfigPath
...
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 bad, for some reason I was thinking someone had to provide this assetPath but it's just given to the callback.
This is an example of configuration that I tried and is working:
This is for a REST backend with a POST route |
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.
LGTM! thank you!
This proposal aims to keep next-video fully backward compatible while allowing assets to be saved to a database or sent to an API.
The idea is to make the asset-saving and uploading functions configurable, so developers can choose where to save them. The default configuration will maintain the current behavior of saving to the filesystem.
This is a draft; there are still some tests to fix, but I would appreciate any early feedback.