-
Notifications
You must be signed in to change notification settings - Fork 5.5k
13401 components dart #18813
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: master
Are you sure you want to change the base?
13401 components dart #18813
Conversation
…date, and delete functionalities. Add new properties for document management and update package version to 0.2.0. Enhance existing actions for task management with version updates.
WalkthroughAdds Create/Update/Delete Doc actions and corresponding Dart app client methods/props, updates API base URL and transaction path, bumps several component and package versions, and makes minor formatting and newline fixes. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant Action
participant DartApp as Dart App Client
participant DartAPI as Dart API
User->>Action: invoke create-doc / update-doc / delete-doc
Action->>Action: read props (dart, title/folder/text/docId)
alt Create Doc
Action->>DartApp: createDoc({ $, title, folder, text })
DartApp->>DartAPI: POST https://app.dartai.com/api/v0/public/docs
else Update Doc
Action->>DartApp: updateDoc({ $, data: { item: { id, title, folder, text } } })
DartApp->>DartAPI: PUT https://app.dartai.com/api/v0/public/docs/{id}
else Delete Doc
Action->>DartApp: deleteDoc({ $, docId })
DartApp->>DartAPI: DELETE https://app.dartai.com/api/v0/public/docs/{docId}
end
DartAPI-->>DartApp: API response
DartApp-->>Action: response
Action->>Action: $.export("$summary", ...)
Action-->>User: return response
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
Pre-merge checks and finishing touches❌ Failed checks (2 warnings, 1 inconclusive)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 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.
Actionable comments posted: 1
🧹 Nitpick comments (2)
components/dart/actions/create-doc/create-doc.mjs (1)
35-49: Add defensive null check for response structure.The code assumes
response.item.idexists at line 47 without validation. If the API returns an unexpected response structure, this will cause a runtime error.Apply this diff to add a defensive check:
- $.export("$summary", `New doc successfully created with ID: ${response.item.id}`); + $.export("$summary", `New doc successfully created with ID: ${response?.item?.id || 'unknown'}`); return response;Alternatively, if the response structure is guaranteed by the API contract, consider verifying the response format:
const response = await this.dart.createDoc({ $, data: { item: { title: this.title, folder: this.folder, text: this.text, }, }, }); + + if (!response?.item?.id) { + throw new Error("Unexpected response format from createDoc API"); + } $.export("$summary", `New doc successfully created with ID: ${response.item.id}`); return response;components/dart/dart.app.mjs (1)
183-189: Consider refactoring for consistency and reduced coupling.The
updateDocmethod accessesopts.data.item.idto construct the path, which tightly couples it to the caller's data structure. In contrast,deleteDoc(lines 190-198) uses a destructureddocIdparameter, which is cleaner and more flexible.Consider refactoring
updateDocto matchdeleteDoc's approach:-updateDoc(opts = {}) { +updateDoc({ + docId, ...opts +}) { return this._makeRequest({ method: "PUT", - path: `/docs/${opts.data.item.id}`, + path: `/docs/${docId}`, ...opts, }); },Then update the caller in
components/dart/actions/update-doc/update-doc.mjs(line 43):const response = await this.dart.updateDoc({ + docId: this.docId, $, data: { item: { - id: this.docId, title: this.title, folder: this.folder, text: this.text, }, }, });
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (11)
components/dart/actions/create-doc/create-doc.mjs(1 hunks)components/dart/actions/create-task/create-task.mjs(1 hunks)components/dart/actions/delete-doc/delete-doc.mjs(1 hunks)components/dart/actions/find-or-create-task/find-or-create-task.mjs(1 hunks)components/dart/actions/update-doc/update-doc.mjs(1 hunks)components/dart/actions/update-task/update-task.mjs(1 hunks)components/dart/dart.app.mjs(4 hunks)components/dart/package.json(2 hunks)components/dart/sources/new-doc-created/new-doc-created.mjs(1 hunks)components/dart/sources/new-doc-updated/new-doc-updated.mjs(1 hunks)components/dart/sources/new-task-created/new-task-created.mjs(1 hunks)
🧰 Additional context used
🧬 Code graph analysis (3)
components/dart/actions/update-doc/update-doc.mjs (2)
components/dart/actions/create-doc/create-doc.mjs (1)
response(36-45)components/dart/actions/delete-doc/delete-doc.mjs (1)
response(24-27)
components/dart/actions/create-doc/create-doc.mjs (2)
components/dart/actions/delete-doc/delete-doc.mjs (1)
response(24-27)components/dart/actions/update-doc/update-doc.mjs (1)
response(43-53)
components/dart/actions/delete-doc/delete-doc.mjs (2)
components/dart/actions/create-doc/create-doc.mjs (1)
response(36-45)components/dart/actions/update-doc/update-doc.mjs (1)
response(43-53)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)
- GitHub Check: pnpm publish
- GitHub Check: Lint Code Base
- GitHub Check: Publish TypeScript components
- GitHub Check: Verify TypeScript components
🔇 Additional comments (16)
components/dart/package.json (1)
3-3: LGTM! Version bumps are appropriate.The package version bump from 0.1.0 to 0.2.0 aligns with the addition of new doc-related actions (create-doc, update-doc, delete-doc) and the dependency update is appropriate.
Also applies to: 16-16
components/dart/actions/find-or-create-task/find-or-create-task.mjs (1)
7-7: LGTM! Version bump for consistency.The version increment aligns with the broader package updates in this PR.
components/dart/actions/update-task/update-task.mjs (1)
7-7: LGTM! Version bump for consistency.The version increment aligns with the broader package updates in this PR.
components/dart/sources/new-doc-updated/new-doc-updated.mjs (2)
10-10: LGTM! Version bump aligns with new doc features.The version increment is appropriate for this source update.
20-27: Remove this review comment—the complete doc object is already emitted as the event payload.The
processEvent()method incommon/base.mjs(line 29) callsthis.$emit(item, meta), emitting the full doc object as the event payload. Consumers already have access to all doc fields includingupdatedByClientDuid(visible intest-event.mjs). ThegenerateMeta()method correctly creates only deduplication metadata (ID and timestamp), which is its intended purpose—not to duplicate the full payload.Likely an incorrect or invalid review comment.
components/dart/sources/new-task-created/new-task-created.mjs (2)
9-9: LGTM! Version bump aligns with package updates.The version increment is appropriate for this source update.
20-26: Creator ID is available in the emitted task object; verify if metadata inclusion is needed.The task object returned by
listTaskscontains the creator ID ascreatedByDuid. Since the base class (base.mjs) already emits the full task object viathis.$emit(item, meta), the complete creator information is accessible in the event payload. However, if explicit inclusion in metadata is a requirement per PR objectives, consider addingcreatedByDuidto thegenerateMeta()method for easier access.components/dart/sources/new-doc-created/new-doc-created.mjs (2)
9-9: LGTM! Version bump aligns with new doc features.The version increment is appropriate for this source update.
20-26: Review comment cannot be definitively verified without access to the PR objectives and full Dart API documentation.Based on examination of the codebase:
- The test event payload (
components/dart/sources/new-doc-created/test-event.mjs) containsduid,createdAt,drafterDuid, andeditorDuidsfields, but no explicitcreator,creatorId,createdBy, orauthorIdfield.- The
generateMetamethod currently uses available fields:doc.duidanddoc.createdAt.- Potentially related fields are
drafterDuid(nullable) oreditorDuids(array of user IDs).The review comment references "PR objectives" stating a required "creator id" prop should be included, but without access to the PR description or Dart API documentation, this claim cannot be confirmed. The test event structure suggests no dedicated creator field exists in the current API response.
Verify the PR objectives and Dart API response to confirm whether:
- A creator field exists in the full API documentation
drafterDuidoreditorDuids[0]should be treated as the creator- The requirement to include creator information is actually mandated
components/dart/actions/create-task/create-task.mjs (1)
7-7: LGTM! Version bump for consistency.The version increment aligns with the broader package updates in this PR.
components/dart/actions/create-doc/create-doc.mjs (1)
1-34: LGTM! Clean action structure.The action properly implements the create-doc functionality per PR objectives:
- Configurable doc name (title prop)
- Target folder specification (folder prop)
- Additional text content for doc body
The use of propDefinitions ensures consistency with the dart.app.mjs definitions.
components/dart/dart.app.mjs (2)
66-84: LGTM! Prop definition follows established patterns.The
docIdpropDefinition correctly maps API response fields (id→value,title→label) and follows the same pattern as other prop definitions in the file.
129-129: Verify the base URL and listDocs endpoint changes against Dart's current API.The endpoint changes cannot be conclusively verified from available documentation. While the base URL (
https://app.dartai.com/api/v0/public) appears consistent across the codebase, Dart's API structure uses OpenAPI and MCP specifications rather than traditional REST paths. Confirm that thelistDocspath change from/docsto/docs/listand thecreateDocpath (/docs) match Dart's current API specification before merging, as these are breaking changes to the integration.components/dart/actions/delete-doc/delete-doc.mjs (1)
14-31: LGTM! Implementation is clean and follows established patterns.The action correctly uses the
deleteDocmethod from the Dart app, properly passes parameters, and provides a clear success message.components/dart/actions/update-doc/update-doc.mjs (2)
14-41: LGTM! Props correctly configured for partial updates.All update properties (
title,folder,text) are optional, which aligns with the description stating "Any properties that are not specified will not be changed." Thetitleoverride tooptional: trueis appropriate since the base definition doesn't mark it optional, and this action supports partial updates.
42-57: I found the Dart AI service integration. Now let me check how the API client handles undefined values:Let me check how the API client handles undefined values when making requests:
Based on my verification, the original review comment about undefined/null handling can be resolved:
When JavaScript serializes objects to JSON, properties with undefined values are automatically omitted from the output. This means the current implementation in
update-doc.mjs(lines 48-50) correctly handles optional fields. Whentitle,folder, ortextare undefined, they are completely omitted from the JSON, which aligns with the API's documented behavior: "Any properties that are not specified will not be changed."The implementation is correct as-is. No changes are needed.
…task actions and document sources
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
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.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (8)
components/configcat/configcat.app.mjs(1 hunks)components/dart/actions/create-task/create-task.mjs(1 hunks)components/dart/actions/find-or-create-task/find-or-create-task.mjs(1 hunks)components/dart/actions/update-task/update-task.mjs(1 hunks)components/dart/dart.app.mjs(3 hunks)components/dart/sources/new-doc-created/new-doc-created.mjs(1 hunks)components/dart/sources/new-doc-updated/new-doc-updated.mjs(1 hunks)components/dart/sources/new-task-created/new-task-created.mjs(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- components/configcat/configcat.app.mjs
🚧 Files skipped from review as they are similar to previous changes (5)
- components/dart/sources/new-doc-created/new-doc-created.mjs
- components/dart/actions/create-task/create-task.mjs
- components/dart/sources/new-doc-updated/new-doc-updated.mjs
- components/dart/sources/new-task-created/new-task-created.mjs
- components/dart/actions/update-task/update-task.mjs
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)
- GitHub Check: pnpm publish
- GitHub Check: Lint Code Base
- GitHub Check: Verify TypeScript components
- GitHub Check: Publish TypeScript components
🔇 Additional comments (7)
components/dart/dart.app.mjs (6)
109-125: LGTM! New doc propDefinitions are well-defined.The new propDefinitions for
title,folder, andtextare clear, follow standard patterns, and have appropriate optional/required flags for doc operations.
176-182: LGTM! The createDoc method follows standard patterns.The
createDocmethod is implemented correctly with appropriate HTTP method and path.
190-198: LGTM! The deleteDoc method is well-implemented.The
deleteDocmethod uses clean destructuring and follows RESTful patterns correctly.
183-189: Remove the refactoring suggestion—the current implementation is correct.The nested
opts.data.item.idstructure is intentional and matches the actual calling convention. The action file (components/dart/actions/update-doc/update-doc.mjslines 43-46) callsupdateDocwith the nested structure:{ $, data: { item: { ... } } }. Refactoring to destructureddocIdwould break this existing call site. ThedeleteDocmethod has a different API contract and is not a valid comparison.Likely an incorrect or invalid review comment.
172-175: Path is consistent with established API design; no issues found.The
createTransactionendpoint at/public/transactions/createfollows the correct pattern. Analysis of the codebase shows this is intentional API design:
- Read operations (
listDocs,listTasks):/docs,/tasks— no/publicprefix- Write operations (
createTransaction,createDoc,updateDoc,deleteDoc):/public/*— all use/publicprefixThis is consistent, not an inconsistency. The
/publicprefix distinguishes mutation endpoints from read endpoints. Additionally,createTransactionhas no existing usages in the codebase, so there are no breaking changes to address.
129-129: The initial search returned results for the official Dart programming language APIs. However, the review context indicates this is a proprietary third-party service (based on the domain namesapp.itsdart.comandapp.dartai.com, and endpoints like "tasks", "dartboards", "users"). Let me search for information about this specific service:Confirm API migration timeline and update endpoint accordingly.
The domain change from itsdart.com to dartai.com reflects Dart's rebranding. API documentation is accessible at the new domain, and recent changelog entries confirm ongoing API improvements.
Before merging:
- Verify clients and integrations have been notified of the domain change
- Check if app.itsdart.com redirects to app.dartai.com or if both need support
- Confirm this aligns with the official Dart migration plan
components/dart/actions/find-or-create-task/find-or-create-task.mjs (1)
7-7: No action required—the path refactoring maintains functional compatibility.The commit refactored the base URL structure, moving
/publicfrom the base URL to individual method paths. The final API endpoint URL forcreateTransactionremains identical, so the existing action will continue to work without modification. The version bump appropriately documents this internal restructuring.
| docId: { | ||
| type: "string", | ||
| label: "Doc ID", | ||
| description: "The ID of the doc", | ||
| async options({ page }) { | ||
| const { results } = await this.listDocs({ | ||
| params: { | ||
| limit: constants.DEFAULT_LIMIT, | ||
| offset: page * constants.DEFAULT_LIMIT, | ||
| }, | ||
| }); | ||
| return results?.map(({ | ||
| id: value, title: label, | ||
| }) => ({ | ||
| value, | ||
| label, | ||
| })) || []; | ||
| }, | ||
| }, |
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.
🧩 Analysis chain
Verify the field name inconsistency between docs and tasks.
The docId propDefinition uses the id field (line 78), while taskId uses the duid field (line 59). If this reflects actual API response differences, this is correct. However, please verify that the Dart API returns id for docs and duid for tasks to ensure this inconsistency is intentional.
🏁 Script executed:
#!/bin/bash
# Description: Verify the field names returned by the API for docs vs tasks
# Check API documentation or example responses
rg -nP --type=js -C5 'listDocs|listTasks' | rg -P '(id|duid).*:'Length of output: 0
Let me search more directly for the implementations of these methods to understand the field naming:
---
🏁 Script executed:
```shell
#!/bin/bash
# Find listDocs and listTasks method definitions and see what fields they use/return
echo "=== Searching for listDocs implementation ==="
rg -nA20 'listDocs\s*\(' components/dart/dart.app.mjs | head -40
echo ""
echo "=== Searching for listTasks implementation ==="
rg -nA20 'listTasks\s*\(' components/dart/dart.app.mjs | head -40
echo ""
echo "=== Checking taskId destructuring (line 59 context) ==="
sed -n '47,65p' components/dart/dart.app.mjs
echo ""
echo "=== Checking docId destructuring (line 66-84 context) ==="
sed -n '66,84p' components/dart/dart.app.mjs
Length of output: 3211
Let me check if there's any API documentation or references in the codebase that confirm these field names:
---
🏁 Script executed:
```shell
#!/bin/bash
# Look for Dart API documentation, examples, or configuration that might explain the field names
echo "=== Searching for Dart API references/docs ==="
find . -type f \( -name "*.md" -o -name "*.json" -o -name "*config*" \) 2>/dev/null | head -20
echo ""
echo "=== Checking for comments about API structure ==="
rg -n 'duid|dartId' components/dart/ -B2 -A2
echo ""
echo "=== Checking README or docs in dart directory ==="
ls -la components/dart/ | grep -E '\.(md|txt|json)$'
Length of output: 9034
Correct the field name in docId propDefinition from id to duid.
The test data and source handlers confirm that both docs and tasks use the duid field in API responses. The docId propDefinition currently destructures id: value (line 78), but should destructure duid: value to match the actual API response and match the pattern used for taskId.
return results?.map(({
- id: value, title: label,
+ duid: value, title: label,
}) => ({
value,
label,
})) || [];📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| docId: { | |
| type: "string", | |
| label: "Doc ID", | |
| description: "The ID of the doc", | |
| async options({ page }) { | |
| const { results } = await this.listDocs({ | |
| params: { | |
| limit: constants.DEFAULT_LIMIT, | |
| offset: page * constants.DEFAULT_LIMIT, | |
| }, | |
| }); | |
| return results?.map(({ | |
| id: value, title: label, | |
| }) => ({ | |
| value, | |
| label, | |
| })) || []; | |
| }, | |
| }, | |
| docId: { | |
| type: "string", | |
| label: "Doc ID", | |
| description: "The ID of the doc", | |
| async options({ page }) { | |
| const { results } = await this.listDocs({ | |
| params: { | |
| limit: constants.DEFAULT_LIMIT, | |
| offset: page * constants.DEFAULT_LIMIT, | |
| }, | |
| }); | |
| return results?.map(({ | |
| duid: value, title: label, | |
| }) => ({ | |
| value, | |
| label, | |
| })) || []; | |
| }, | |
| }, |
🤖 Prompt for AI Agents
In components/dart/dart.app.mjs around lines 66 to 84, the docId propDefinition
destructures the API response using id: value but the API returns duid; change
the destructuring to use duid: value (keeping title as label) so results map to
{ value, label } correctly; ensure the fallback to [] remains unchanged.
Resolves #13401
Summary by CodeRabbit
New Features
Bug Fixes
Chores