-
Notifications
You must be signed in to change notification settings - Fork 61
Update attachment package #735
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
base: main
Are you sure you want to change the base?
Conversation
🦋 Changeset detectedLatest commit: bd6a5b9 The changes in this PR will be included in the next version bump. This PR includes changesets to release 9 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
stevensJourney
left a comment
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.
This looks like a good improvement so far. I've added some comments for some items I spotted.
packages/attachments/src/storageAdapters/NodeFileSystemAdapter.ts
Outdated
Show resolved
Hide resolved
- Added `getAttachment` method to retrieve an attachment by ID in AttachmentContext. - Updated `upsertAttachment` to handle null values for optional fields. - Introduced `generateAttachmentId` method in AttachmentQueue for generating unique IDs. - Modified `watchActiveAttachments` to accept a throttle parameter. - Added `deleteFile` method to have attachment deletion. - Updated tests to cover new functionality and ensure reliability.
…ttachment sync operations - Added AttachmentErrorHandler interface to manage download, upload, and delete errors for attachments. - Updated AttachmentQueue and SyncingService to utilize the new error handler. - Enhanced tests to verify error handling behavior during attachment sync processes.
671e23a to
bea28d9
Compare
bea28d9 to
e42ae45
Compare
# Conflicts: # pnpm-lock.yaml
stevensJourney
left a comment
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.
Left some comments. Overall the APIs and code looks good so far.
demos/react-native-supabase-todolist/library/powersync/system.ts
Outdated
Show resolved
Hide resolved
stevensJourney
left a comment
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 noticed a few items in this review, but I do think this is looking good.
packages/react-native/src/attachments/ReactNativeFileSystemAdapter.ts
Outdated
Show resolved
Hide resolved
packages/react-native/package.json
Outdated
| "@rollup/plugin-replace": "^5.0.7", | ||
| "@rollup/plugin-terser": "^0.4.4", | ||
| "bson": "^6.10.4", | ||
| "expo-file-system": "^15.2.2", |
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 reviewing #803, I noticed that the latest version of expo-file-system is 19.0.21.
The current latest version uses a * peerDependency constraint for expo, which should theoretically be compatible with any version of Expo.
However, we're already 4 major versions behind expo-file-system, which raises an important question: what happens when the next major version (with breaking changes) is released? Bumping our peerDependency range for expo-file-system by a major version could be considered a breaking change for our users, requiring a major version bump of @powersync/react-native. I'd prefer to avoid making a major version bump solely for a filesystem dependency upgrade that only affects a small portion of this package's functionality (the attachment helpers).
We don't really have this issue for other JS platforms (or other SDKs) since the storage APIs (and general dependencies) we're using are quite standard.
Moving the FileSystem adapter out of this package is also not ideal, but does seem like a potentially more manageable alternative.
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 call, while not ideal, I'm not sure if there is a cleaner way to workaround the Expo dependency churn.
The lowest friction route I could think of, was to just create a straightforward@powersync/attachments-react-native package that handles both Expo and React Native file system adapters.
It's still a work-in-progress (docs and demos need updating) but the idea is there.
This a port of the Swift, Dart and Kotlin attachment's API to the JS SDK.
This addresses the following issues #715 and #714 by adding the
meta_datacolumn to the table and persisting it in the attachments table.It is currently still a work-in-progress so there are a couple things that still needs to be done: