feat: in memory collaboration in SuperdocDev#1257
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| const init = async () => { | ||
| let testId = 'document-123'; | ||
| // const testId = "document_6a9fb1e0725d46989bdbb3f9879e9e1b"; | ||
| const exists = await documentExists(); | ||
| const blankDoc = await getFileObject(BlankDOCX, 'Blank.docx', DOCX); | ||
|
|
||
| // Prepare document config with content if available | ||
| // IMPORTANT: Always provide the blank document for document structure | ||
| // isNewFile controls whether to seed the fragment with this content | ||
| const documentConfig = { | ||
| data: currentFile.value, | ||
| id: testId, | ||
| isNewFile: true, | ||
| id: documentId, | ||
| type: DOCX, | ||
| name: 'Collaboration Demo.docx', | ||
| data: blankDoc, // Both users need the document structure | ||
| isNewFile: !exists, // User 1 seeds fragment, User 2 syncs from it | ||
| }; |
There was a problem hiding this comment.
Restore uploaded file when collaboration disabled
The new init() logic always builds documentConfig from a blank DOCX (data: blankDoc and type: DOCX) and never uses currentFile.value anymore. When collaboration is not enabled (the default) or when the user uploads a PDF/DOCX through the dev UI, SuperdocDev now ignores the uploaded file and loads the empty template instead, so file previewing/editing no longer works. The previous code passed the selected file’s data and type through. Please use the uploaded file when collaboration is off (and only fall back to the blank template when seeding a collaborative room) so that the dev environment still displays arbitrary documents.
Useful? React with 👍 / 👎.
1602fbe to
a1cc4e1
Compare
harbournick
left a comment
There was a problem hiding this comment.
I'd probably skip the user stuff here. See my comment in the api side.
| params: { | ||
| ...config.params, | ||
| }, | ||
| params: config.params, |
There was a problem hiding this comment.
Just curious: why the change?
| const documentId = isInternal ? baseName : `${baseName}-external`; | ||
|
|
||
| // Use user from collaboration config if provided, otherwise use top-level user | ||
| const user = superdoc.config.modules.collaboration?.user || superdoc.config.user; |
There was a problem hiding this comment.
Curious: why the dual-user setup?
| ...superdoc.config.modules.collaboration?.params, | ||
| name: user?.name, | ||
| email: user?.email, | ||
| role: user?.role, |
There was a problem hiding this comment.
Why not keep user object rather than merging it with params?
| config: superdoc.config.modules.collaboration, | ||
| user: superdoc.config.user, | ||
| config: collabConfig, | ||
| user: user, |
There was a problem hiding this comment.
Since the user is now in the configuration too seems we're doubling up. I'm not clear on the intent here
|
|
||
| // Add user info to params so it's sent to the server | ||
| const collabConfig = { | ||
| ...superdoc.config.modules.collaboration, |
There was a problem hiding this comment.
If we need to do this twice, once per fn, let's extract to a helper
84f8ea5 to
2a443d8
Compare
Via L3 deep analysis · sensitive risk |
Not Prod ready, this PR is for engineering collaboration and early feedback. please don't review or test unless assigned to you by ticket