Skip to content

Conversation

@luancazarine
Copy link
Collaborator

@luancazarine luancazarine commented Oct 20, 2025

Resolves #13401

Summary by CodeRabbit

  • New Features

    • Added document management actions: Create Doc, Update Doc, and Delete Doc.
    • Added document metadata fields: title, folder, and text.
  • Bug Fixes

    • Updated base API URL for Dart service endpoints.
  • Chores

    • Bumped component and source versions and package version; minor formatting newline fix.

…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.
@luancazarine luancazarine linked an issue Oct 20, 2025 that may be closed by this pull request
@coderabbitai
Copy link
Contributor

coderabbitai bot commented Oct 20, 2025

Walkthrough

Adds 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

Cohort / File(s) Summary
New Doc Actions
components/dart/actions/create-doc/create-doc.mjs, components/dart/actions/update-doc/update-doc.mjs, components/dart/actions/delete-doc/delete-doc.mjs
Added three new action modules: create-doc, update-doc, delete-doc. Each exports action metadata, props (including dart and op-specific fields like title, folder, text, docId) and a run method that calls the corresponding this.dart client method and exports a summary.
Task Action Version Bumps
components/dart/actions/create-task/create-task.mjs, components/dart/actions/find-or-create-task/find-or-create-task.mjs, components/dart/actions/update-task/update-task.mjs
Bumped action metadata versions for task-related actions (to 0.0.4). No functional changes reported.
Dart App Client Updates
components/dart/dart.app.mjs
Added propDefinitions: docId, title, folder, text. Changed base URL to https://app.dartai.com/api/v0. Added methods: createDoc, updateDoc, deleteDoc. Adjusted deleteDoc signature to accept { docId, ...opts }. createTransaction path updated to /public/transactions/create. listDocs path unchanged.
Source Version Bumps
components/dart/sources/new-doc-created/new-doc-created.mjs, components/dart/sources/new-doc-updated/new-doc-updated.mjs, components/dart/sources/new-task-created/new-task-created.mjs
Bumped exported source versions from 0.0.1 → 0.0.3. No behavior changes.
Package & Formatting
components/dart/package.json, components/configcat/configcat.app.mjs
package.json: package version 0.1.0 → 0.2.0; bumped @pipedream/platform ^3.0.0 → ^3.1.0. configcat.app.mjs: added trailing newline at EOF.

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
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Poem

🐰
I hopped through code with nimble paws,
New docs to make, update, remove—
The API changed its little laws,
Versions nudged and props improve.
A carrot cheer for smoother grooves!

Pre-merge checks and finishing touches

❌ Failed checks (2 warnings, 1 inconclusive)
Check name Status Explanation Resolution
Out of Scope Changes Check ⚠️ Warning The pull request contains changes primarily focused on dart component implementation (actions, sources, and supporting infrastructure), which are all within scope of issue #13401. However, there is one out-of-scope change: components/configcat/configcat.app.mjs contains only a minor formatting change (adding a trailing newline) that is unrelated to the dart components and the stated objectives of this pull request. This appears to be an incidental modification that should not be part of this changeset.
Description Check ⚠️ Warning The pull request description only contains "Resolves #13401" without following the required template structure. The template specifies a "WHY" section that should explain the rationale and context for the changes, but this section is entirely missing and not completed. The description fails to provide any context about what is being implemented or why these changes are necessary, leaving reviewers without essential information about the motivation behind the code changes.
Linked Issues Check ❓ Inconclusive The pull request implements three required actions (create-doc, delete-doc, and update-doc) with corresponding infrastructure in dart.app.mjs including new propDefinitions and API methods. However, the compliance cannot be fully verified for webhook sources (new-doc-created-instant, new-doc-updated-instant, new-task-created-instant) because the raw summary only shows version bumps without detailing implementation or confirming that required properties are present. Additionally, the delete-doc action summary only mentions docId as a prop but the issue requires both Doc ID and folder location as required properties. The base API URL was properly updated to support these new endpoints.
✅ Passed checks (2 passed)
Check name Status Explanation
Title Check ✅ Passed The title "13401 components dart" directly references the issue number and identifies the component area being modified. It clearly points to the dart components in relation to issue #13401, which is sufficient for a teammate to understand the general scope of the change. While the title could be more specific about the features being added (e.g., "Add doc actions and sources for dart components"), it is partially related to the changeset and conveys the primary area of modification.
Docstring Coverage ✅ Passed No functions found in the changes. Docstring coverage check skipped.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch 13401-components-dart

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Contributor

@coderabbitai coderabbitai bot left a 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.id exists 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 updateDoc method accesses opts.data.item.id to construct the path, which tightly couples it to the caller's data structure. In contrast, deleteDoc (lines 190-198) uses a destructured docId parameter, which is cleaner and more flexible.

Consider refactoring updateDoc to match deleteDoc'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

📥 Commits

Reviewing files that changed from the base of the PR and between ffab7aa and 31bcfa6.

⛔ Files ignored due to path filters (1)
  • pnpm-lock.yaml is 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 in common/base.mjs (line 29) calls this.$emit(item, meta), emitting the full doc object as the event payload. Consumers already have access to all doc fields including updatedByClientDuid (visible in test-event.mjs). The generateMeta() 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 listTasks contains the creator ID as createdByDuid. Since the base class (base.mjs) already emits the full task object via this.$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 adding createdByDuid to the generateMeta() 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) contains duid, createdAt, drafterDuid, and editorDuids fields, but no explicit creator, creatorId, createdBy, or authorId field.
  • The generateMeta method currently uses available fields: doc.duid and doc.createdAt.
  • Potentially related fields are drafterDuid (nullable) or editorDuids (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:

  1. A creator field exists in the full API documentation
  2. drafterDuid or editorDuids[0] should be treated as the creator
  3. 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 docId propDefinition correctly maps API response fields (idvalue, titlelabel) 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 the listDocs path change from /docs to /docs/list and the createDoc path (/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 deleteDoc method 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." The title override to optional: true is 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. When title, folder, or text are 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.

lcaresia
lcaresia previously approved these changes Oct 21, 2025
@vercel
Copy link

vercel bot commented Oct 22, 2025

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment
Project Deployment Preview Comments Updated (UTC)
pipedream-docs-redirect-do-not-edit Ignored Ignored Oct 22, 2025 7:42pm

Copy link
Contributor

@coderabbitai coderabbitai bot left a 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

📥 Commits

Reviewing files that changed from the base of the PR and between 31bcfa6 and 99c1c03.

⛔ Files ignored due to path filters (1)
  • pnpm-lock.yaml is 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, and text are clear, follow standard patterns, and have appropriate optional/required flags for doc operations.


176-182: LGTM! The createDoc method follows standard patterns.

The createDoc method is implemented correctly with appropriate HTTP method and path.


190-198: LGTM! The deleteDoc method is well-implemented.

The deleteDoc method uses clean destructuring and follows RESTful patterns correctly.


183-189: Remove the refactoring suggestion—the current implementation is correct.

The nested opts.data.item.id structure is intentional and matches the actual calling convention. The action file (components/dart/actions/update-doc/update-doc.mjs lines 43-46) calls updateDoc with the nested structure: { $, data: { item: { ... } } }. Refactoring to destructured docId would break this existing call site. The deleteDoc method 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 createTransaction endpoint at /public/transactions/create follows the correct pattern. Analysis of the codebase shows this is intentional API design:

  • Read operations (listDocs, listTasks): /docs, /tasks — no /public prefix
  • Write operations (createTransaction, createDoc, updateDoc, deleteDoc): /public/* — all use /public prefix

This is consistent, not an inconsistency. The /public prefix distinguishes mutation endpoints from read endpoints. Additionally, createTransaction has 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 names app.itsdart.com and app.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 /public from the base URL to individual method paths. The final API endpoint URL for createTransaction remains identical, so the existing action will continue to work without modification. The version bump appropriately documents this internal restructuring.

Comment on lines +66 to +84
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,
})) || [];
},
},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 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.

Suggested change
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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Components] dart

2 participants