Adding websdk docs, simplifying js-sdk docs #85
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
madhavanmalolan seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account. You have signed the CLA already but the status is still pending? Let us recheck it. |
|
Note Other AI code review bot(s) detectedCodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review. WalkthroughRemoved the JS SDK API reference file, updated multiple JS SDK guides (init signature, added setParams and setAppCallbackUrl, UI/progress guidance, wording), changed JS SDK metadata/title (removed api-reference), and added an Changes
Sequence Diagram(s)sequenceDiagram
autonumber
actor Developer
participant Frontend
participant SDK as "Reclaim JS SDK"
participant Backend
participant Verifier
Developer->>Frontend: ReclaimProofRequest.init(appId, appSecret, providerId, proofRequestOptions)
Frontend->>SDK: init(...)
SDK-->>Frontend: configured instance
Developer->>Frontend: setParams(params) / setAppCallbackUrl(url)
Frontend->>SDK: setParams(...) / setAppCallbackUrl(...)
SDK-->>Frontend: params/callback applied
Developer->>Frontend: triggerReclaimFlow()
Frontend->>SDK: triggerReclaimFlow()
SDK->>Backend: startSession / deliver proofs (callback or upload)
Backend->>Verifier: verifyProof(proof)
Verifier-->>Backend: verification result
Backend-->>Frontend: callback/notify result
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (6)
content/docs/js-sdk/preparing-request.mdx (1)
64-64: Fix the section heading capitalization.Line 64 uses "Advance Options" but the convention (and grammatical correctness) is "Advanced Options" (also used in the generating-proof.mdx file). Please standardize to "Advanced Options".
Also applies to: 101-101
content/docs/js-sdk/generating-proof.mdx (3)
45-47: Make onSuccess callback async pattern consistent across examples.The quickstart example (lines 45–47) doesn't use
awaitforuploadProofs, while the React hook example (lines 82–85) does. Since the comment indicates proofs should be uploaded and verified before continuing business logic, both examples should consistently useawait uploadProofs(proofs)to ensure proper error handling and sequencing.Apply this diff to the quickstart example:
await reclaimProofRequest.startSession({ - onSuccess: (proofs) => { + onSuccess: async (proofs) => { - // upload proofs to your backend and verify + await uploadProofs(proofs); + // verify via backend // ... continue business logic },Also applies to: 82-85
101-101: Fix section heading capitalization.Line 101 uses "Advance options" but should be "Advanced Options" to match standard terminology and other documentation in the SDK.
170-170: Apply hyphenation to compound adjective.Line 170 should read "mission-critical variables" (with hyphen) rather than "mission critical" when used as a compound adjective.
content/docs/js-sdk/verifying-proofs.mdx (2)
7-7: Apply hyphenation to compound adjective "client-side".Line 7 uses "client side operation" but should be "client-side operation" when used as a compound adjective.
9-9: Consider hyphenating "tamper-resistant" for consistency.Line 9 uses "tamper resistant" but "tamper-resistant" (with hyphen) is the more standard form when used as a compound adjective describing the data.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
content/docs/flutter/meta.json(1 hunks)content/docs/js-sdk/api-reference.mdx(0 hunks)content/docs/js-sdk/generating-proof.mdx(5 hunks)content/docs/js-sdk/installation.mdx(1 hunks)content/docs/js-sdk/meta.json(1 hunks)content/docs/js-sdk/preparing-request.mdx(3 hunks)content/docs/js-sdk/verifying-proofs.mdx(2 hunks)
💤 Files with no reviewable changes (1)
- content/docs/js-sdk/api-reference.mdx
🧰 Additional context used
🪛 LanguageTool
content/docs/js-sdk/verifying-proofs.mdx
[grammar] ~7-~7: Use a hyphen to join words.
Context: ...n](/js-sdk/generating-proof) is a client side operation to protect the privacy an...
(QB_NEW_EN_HYPHEN)
[grammar] ~9-~9: Use a hyphen to join words.
Context: ...gnatures to make sure the data is tamper resistant. # Quickstart ## Setup the ca...
(QB_NEW_EN_HYPHEN)
content/docs/js-sdk/generating-proof.mdx
[grammar] ~170-~170: Use a hyphen to join words.
Context: ...o maintain state separately. For mission critical variables that should not be po...
(QB_NEW_EN_HYPHEN)
🔇 Additional comments (4)
content/docs/flutter/meta.json (1)
3-3: No concerns with the metadata update.The addition of "api-reference" to the Flutter SDK pages is consistent with the PR's documentation restructuring.
content/docs/js-sdk/preparing-request.mdx (1)
22-26: Clarify whetherproofRequestOptionsis required or optional in the init signature.The quickstart examples (lines 22–26 and 47–51) show
ReclaimProofRequest.init()with three parameters, while the "Advanced Options" section (line 76) shows a fourth parameterproofRequestOptions. It's unclear whether this is a required parameter, optional with defaults, or only used in advanced scenarios. Please explicitly document the method signature and parameter optionality.Also applies to: 47-51, 64-77
content/docs/js-sdk/meta.json (1)
2-2: SDK rebrand and documentation restructuring looks good.The title change to "NextJS/React SDK" and removal of the standalone "api-reference" page aligns with the PR's goal of simplifying the documentation structure. The API reference content is now integrated into the relevant guides.
Also applies to: 7-7
content/docs/js-sdk/verifying-proofs.mdx (1)
1-47: Documentation restructuring and verification flow clarification look solid.The updated language on lines 7–9 more clearly communicates the threat model and necessity of backend verification. The reorganized structure with explicit sections and TODO placeholders for the Next.js sample is appropriate for guiding users through the verification process.
| 3. Uploading the proof to the backend and verifying it | ||
| 1. [Preparing](preparing-request) the proof request on the backend | ||
| 2. Asking the user to [generate](generating-proof) the proof on the frontend | ||
| 3. Uploading the proof to the backend and [verifying](verifying-proof) it |
There was a problem hiding this comment.
Fix broken link: "verifying-proof" should be "verifying-proofs".
Line 33 links to "verifying-proof" but the actual file is "verifying-proofs.mdx" (plural). This will result in a 404 error in the documentation site.
Apply this diff to fix the broken link:
-3. Uploading the proof to the backend and [verifying](verifying-proof) it
+3. Uploading the proof to the backend and [verifying](verifying-proofs) it📝 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.
| 3. Uploading the proof to the backend and [verifying](verifying-proof) it | |
| 3. Uploading the proof to the backend and [verifying](verifying-proofs) it |
🤖 Prompt for AI Agents
In content/docs/js-sdk/installation.mdx around line 33, the link target
"verifying-proof" is incorrect; update the link to "verifying-proofs" (matching
the actual filename verifying-proofs.mdx) so the markdown reference points to
the existing page and avoids a 404.
| reclaimProofRequest.triggerReclaimFlow(options) | ||
| ``` | ||
|
|
||
| ## Passing variables through the proof object |
There was a problem hiding this comment.
This is incorrect the params are used to pre set the {{}} variable.
| You need to prepare a proof request that will then be presented to the user on the frontend. | ||
| This proof request, most importantly, tells the user | ||
| 1. With which application they will be sharing the proof | ||
| 1. With which application they will be sharing the data with |
There was a problem hiding this comment.
proof request does not give any info to the user
alt phrasing
allows devs to configure which provider/datasoure they want to request user to verify. Also takes care of authenticating the request making sure you(data requesting app) are the one initiating the proof request.
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (3)
content/docs/js-sdk/verifying-proofs.mdx (2)
17-20: Clarify the "Decode the proof object" section title.The section is titled "Decode the proof object," but the code only shows
JSON.parse()without any preceding decode operation. While this is intentional per the AI summary (the decode step has been removed), the section title may mislead readers into thinking decoding is a separate step. Consider retitling to "Parse the proof object" for clarity.
43-46: Address or defer TODO placeholders.Lines 43 and 46 contain
TODOcomments for the "Sanity Check" and "Sample implementation in Next.js" sections. These should either be completed in this PR or tracked as separate issues to ensure the guide is comprehensive.Would you like me to help generate sample implementations for these sections, or should these be tracked as separate follow-up tasks?
content/docs/js-sdk/generating-proof.mdx (1)
82-84: Clarify the uploadProofs function and backend integration.Lines 82–84 show the React example calling
uploadProofs(proofs)within an asynconSuccesshandler, with a comment that proofs should be uploaded to the backend. However,uploadProofsis not defined in this documentation or the related files. This could mislead developers into thinking there's a built-in SDK function.Clarify that
uploadProofsis a custom application function that developers must implement, or provide a code example showing how to implement it.Add a brief note or example showing how developers should implement the
uploadProofsfunction, e.g.:// Example implementation (developers must create this function) async function uploadProofs(proofs) { const response = await fetch('/api/verify-proof', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ proofs }) }); return response.json(); }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
content/docs/js-sdk/generating-proof.mdx(5 hunks)content/docs/js-sdk/preparing-request.mdx(3 hunks)content/docs/js-sdk/verifying-proofs.mdx(2 hunks)
🧰 Additional context used
🪛 LanguageTool
content/docs/js-sdk/verifying-proofs.mdx
[grammar] ~7-~7: Use a hyphen to join words.
Context: ...n](/js-sdk/generating-proof) is a client side operation. On Success Callback is o...
(QB_NEW_EN_HYPHEN)
[grammar] ~9-~9: Use a hyphen to join words.
Context: ...gnatures to make sure the data is tamper resistant. # Quickstart ## Setup the ca...
(QB_NEW_EN_HYPHEN)
🔇 Additional comments (5)
content/docs/js-sdk/preparing-request.mdx (2)
99-102: Verify the Set Callback code block is complete.Lines 99–102 define the "Set Callback" section with a code block. The provided context ends at line 102, making it unclear if the code block is properly closed with backticks. Ensure the code block has both opening and closing markers.
Please verify the code block closure at line 102 and confirm the section is complete.
87-96: The review comment is incorrect.setParams()and UI customization are separate concerns.The "Customize UI" section in generating-proof.mdx documents UI appearance and behavior options (theme, modal titles, callbacks) passed to
triggerReclaimFlow(). ThesetParams()method in preparing-request.mdx is for pre-setting extracted parameter values to validate proof data—an entirely different feature that belongs in the request preparation phase, not the UI customization section.No cross-reference is needed or appropriate here. The documentation correctly separates these concerns across the two files.
Likely an incorrect or invalid review comment.
content/docs/js-sdk/generating-proof.mdx (3)
8-14: Verify the available options list is comprehensive and links are correct.Lines 8–14 present a restructured intro and enumerate available verification options. Please verify that:
- All available options are listed (AppClip, Instant Apps, App, Browser Extension, Remote browser)
- The links in the available options are correct (especially line 14's reference to
preparing-request#forcing-remote-browser-use)- This list aligns with what the SDK actually supports in the current version
139-146: Document the new getStatusUrl() method.Lines 139–146 introduce the "Showing Progress" section with
getStatusUrl()for polling proof generation progress. Verify that:
- This method is actually supported by the JS SDK in the current version
- Consider adding an example of how to use this URL (e.g., polling interval, response format)
- Clarify when developers should use this vs. the
onSuccesscallbackVerify that
getStatusUrl()is a public API in the current SDK version and provide details on polling behavior/response format if available.
147-165: Verify the Customize UI options and parameter references.Lines 147–165 document UI customization options for
triggerReclaimFlow(options). The options object includestheme,modalTitle,modalSubtitle,autoCloseModal,autoCloseDelay,showExtensionPrompt,onModalOpen, andonModalClose.Verify that:
- All listed options are actually supported by the SDK
- Default values are correct
- Consider adding an example showing how to use these options in practice
- The comment about parameter usage and setParams (mentioned in the AI summary) should be clarified or cross-referenced
Verify these options are supported in the current SDK version and consider adding a practical example of how to use them.
| # Advance Options | ||
| ## Forcing Remote Browser use | ||
| <Callout type="warning"> | ||
| Remote Browser use is available only for users on a premium enterprise plan. Please [contact support](https://t.me/protocolreclaim) for more details. | ||
| </Callout> | ||
| ``` | ||
| proofRequestOptions = { | ||
| ..., //other options, if any | ||
| useAppClip: false, | ||
| customSharePageUrl: 'CONTACT_SUPPORT_FOR_URL' | ||
| } | ||
| const proofRequest = await ReclaimProofRequest.init(appId, appSecret, providerId, proofRequestOptions); | ||
| ``` |
There was a problem hiding this comment.
🧩 Analysis chain
Verify "Advance Options" vs "Advanced Options" terminology.
Line 64 uses "Advance Options" as a section header. For consistency with similar documentation, consider confirming whether this should be "Advance Options" or "Advanced Options" across all three files. Check generating-proof.mdx (line 101) to ensure the terminology is uniform.
Run the following to check consistency:
🏁 Script executed:
#!/bin/bash
# Check for "Advance Options" and "Advanced Options" across JS SDK docs
rg -n "Advance\w*\s+[Oo]ptions" content/docs/js-sdk/Length of output: 125
I need to check if "Advance" should be "Advanced" and review the header capitalization pattern in these files.
🏁 Script executed:
#!/bin/bash
# Check other headers in both files to understand capitalization convention
rg -n "^#+\s" content/docs/js-sdk/preparing-request.mdx content/docs/js-sdk/generating-proof.mdxLength of output: 1761
🏁 Script executed:
#!/bin/bash
# Verify if "Advanced" appears anywhere in JS SDK docs
rg -n "Advanced" content/docs/js-sdk/Length of output: 0
🌐 Web query:
"Advance Options" vs "Advanced Options" documentation terminology
💡 Result:
Use "Advanced options" (or "Advanced Options" in UI title case). "Advanced" is the adjective/past-participle that correctly modifies "options" (more complex or additional settings); "advance" is a verb/noun and is incorrect there except in specialized phrasing. See dictionary and major docs guidance: Merriam‑Webster on "advanced" [1], Google Developer docs recommending "Advanced options" for UI copy [2], and Microsoft docs using "advanced options" in procedure headings [3].
Sources:
[1] Merriam‑Webster — definition of "advanced".
[2] Google Developer Documentation Style Guide — examples using "Advanced options".
[3] Microsoft Learn documentation — section heading "Connect using advanced options (optional)".
Fix incorrect terminology: Change "Advance Options" to "Advanced Options" in both files.
The term "Advance" is a verb/noun, while "Advanced" is the correct adjective that modifies "options." Major documentation standards (Google Developer docs, Microsoft Learn) use "Advanced options."
- content/docs/js-sdk/preparing-request.mdx:64: Change "# Advance Options" to "# Advanced Options"
- content/docs/js-sdk/generating-proof.mdx:101: Change "# Advance options" to "# Advanced Options" (also capitalize for consistency)
🤖 Prompt for AI Agents
In content/docs/js-sdk/preparing-request.mdx around lines 64–77 and
content/docs/js-sdk/generating-proof.mdx around line 101, update the section
headings that currently read "Advance Options"/"Advance options" to the correct
adjective form "Advanced Options" (capitalize both words for consistency);
simply replace the heading text in both files so the documentation uses
"Advanced Options" consistently.
|
|
||
| # Why do I need to verify, when the proof has already been generated? | ||
| The [proof generation](/js-sdk/generating-proof) is a client side operation to protect the privacy and security of the user. Once the proof is generate, the proof is uploaded to the backend. A malicious user may generate a proof (or not) on their client side - and choose to upload an arbitrary json object to your backend. If you don't verify the proof, the arbitrary JSON object and the actual Prooj JSON object will be indistinguishable. | ||
| The [proof generation](/js-sdk/generating-proof) is a client side operation. On Success Callback is only responsible for notifying when the proof is generated successfully. All the proofs generated should be verified on your backend as a malicious user can bypass any check you add on the frontend. |
There was a problem hiding this comment.
Fix hyphenation: "client side" → "client-side".
Line 7 uses "client side" which should be hyphenated when used as a compound adjective.
Apply this diff:
-The [proof generation](/js-sdk/generating-proof) is a client side operation. On Success Callback is only responsible for notifying when the proof is generated successfully. All the proofs generated should be verified on your backend as a malicious user can bypass any check you add on the frontend.
+The [proof generation](/js-sdk/generating-proof) is a client-side operation. On Success Callback is only responsible for notifying when the proof is generated successfully. All the proofs generated should be verified on your backend as a malicious user can bypass any check you add on the frontend.📝 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.
| The [proof generation](/js-sdk/generating-proof) is a client side operation. On Success Callback is only responsible for notifying when the proof is generated successfully. All the proofs generated should be verified on your backend as a malicious user can bypass any check you add on the frontend. | |
| The [proof generation](/js-sdk/generating-proof) is a client-side operation. On Success Callback is only responsible for notifying when the proof is generated successfully. All the proofs generated should be verified on your backend as a malicious user can bypass any check you add on the frontend. |
🧰 Tools
🪛 LanguageTool
[grammar] ~7-~7: Use a hyphen to join words.
Context: ...n](/js-sdk/generating-proof) is a client side operation. On Success Callback is o...
(QB_NEW_EN_HYPHEN)
🤖 Prompt for AI Agents
In content/docs/js-sdk/verifying-proofs.mdx around line 7, the phrase "client
side" should be corrected to the hyphenated compound adjective "client-side";
update the text to read "The [proof generation](/js-sdk/generating-proof) is a
client-side operation." and ensure any other occurrences in the file use
"client-side" when used as a compound adjective.
| The [proof generation](/js-sdk/generating-proof) is a client side operation. On Success Callback is only responsible for notifying when the proof is generated successfully. All the proofs generated should be verified on your backend as a malicious user can bypass any check you add on the frontend. | ||
|
|
||
| Verifying proofs is a very simple light weight operation. You can think of it as verifying the digital signatures to make sure the data is tamper proof. | ||
| Verifying proofs is a very simple light weight operation. You can think of it as verifying the digital signatures to make sure the data is tamper resistant. |
There was a problem hiding this comment.
Fix hyphenation: "tamper resistant" → "tamper-resistant".
Line 9 uses "tamper resistant" which should be hyphenated when used as a compound adjective.
Apply this diff:
-Verifying proofs is a very simple light weight operation. You can think of it as verifying the digital signatures to make sure the data is tamper resistant.
+Verifying proofs is a very simple light weight operation. You can think of it as verifying the digital signatures to make sure the data is tamper-resistant.📝 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.
| Verifying proofs is a very simple light weight operation. You can think of it as verifying the digital signatures to make sure the data is tamper resistant. | |
| Verifying proofs is a very simple light weight operation. You can think of it as verifying the digital signatures to make sure the data is tamper-resistant. |
🧰 Tools
🪛 LanguageTool
[grammar] ~9-~9: Use a hyphen to join words.
Context: ...gnatures to make sure the data is tamper resistant. # Quickstart ## Setup the ca...
(QB_NEW_EN_HYPHEN)
🤖 Prompt for AI Agents
In content/docs/js-sdk/verifying-proofs.mdx around line 9, the phrase "tamper
resistant" should be hyphenated as "tamper-resistant"; update the sentence to
replace the two-word form with the compound adjective "tamper-resistant" so the
line reads "...to make sure the data is tamper-resistant."
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
content/docs/js-sdk/preparing-request.mdx (1)
58-71: Fix incorrect terminology: Change "Advance Options" to "Advanced Options".This issue was flagged in a prior review. The term "Advance" is a verb/noun, while "Advanced" is the correct adjective. Major documentation standards (Google, Microsoft) use "Advanced Options."
Apply this diff:
-# Advance Options +# Advanced Options
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
content/docs/js-sdk/meta.json(1 hunks)content/docs/js-sdk/preparing-request.mdx(3 hunks)
🔇 Additional comments (5)
content/docs/js-sdk/meta.json (1)
3-8: Removal of "api-reference" from pages aligns with PR objectives.The "api-reference" entry was removed from the pages array in sync with the deletion of
content/docs/js-sdk/api-reference.mdx. This aligns with the PR's restructuring toward NextJS/React documentation focus.content/docs/js-sdk/preparing-request.mdx (4)
6-28: Clear and concise quickstart flow.The streamlined quickstart section effectively guides users through the essential steps for backend request setup. The flow is logical and easy to follow.
30-55: Well-structured Next.js example with security best practices.The sample implementation demonstrates secure handling of APP_ID/APP_SECRET via environment variables and provides clear comments for customization points.
73-90: Well-documented new API methods with practical examples.The Set Context and Set Parameters sections clearly explain the purpose and usage of setContext() and setParams(). Examples are practical and help developers understand the constraints they enable.
93-97: Clear documentation of backend callback configuration.The Set Callback section concisely explains the purpose and benefit of setAppCallbackUrl() for secure backend proof processing. The explanation clarifies the advantage over frontend-based proof upload.
| @@ -1,10 +1,9 @@ | |||
| { | |||
| "title": "JavaScript SDK", | |||
| "title": "Javascript SDK", | |||
There was a problem hiding this comment.
Revert capitalization to "JavaScript SDK" per prior feedback.
The title was changed to "Javascript SDK" (lowercase 's'), which contradicts the prior review comment requesting to "stick with JavaScript SDK". JavaScript is a proper noun requiring both letters capitalized.
Apply this diff:
- "title": "Javascript SDK",
+ "title": "JavaScript SDK",📝 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.
| "title": "Javascript SDK", | |
| "title": "JavaScript SDK", |
🤖 Prompt for AI Agents
content/docs/js-sdk/meta.json around line 2: the title was changed to
"Javascript SDK" with a lowercase 's'; revert the capitalization to "JavaScript
SDK" by updating the title value on that line to exactly "JavaScript SDK" so it
matches prior reviews and proper noun style.
|
|
||
| ## Set Callback | ||
| ``` | ||
| reclaimProofRequest.setAppCallbackUrl(url) |
There was a problem hiding this comment.
we have support for jsonResponse by default it is URL-encoded form data
reclaimProofRequest.setAppCallbackUrl(url: string, jsonResponse?: boolean);
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
This is the final PR Bugbot will review for you during this billing cycle
Your free Bugbot reviews will reset on November 20
Details
Your team is on the Bugbot Free tier. On this plan, Bugbot will review limited PRs each billing cycle for each member of your team.
To receive Bugbot reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.
| # Quickstart | ||
| ## Setup the callback endpoint | ||
| This should be the same callback endpoint that was set when [building the proof request](preparing-request). | ||
| This should be the endpoint that will be called by your [`onSuccess` callback](generating-proof). |
There was a problem hiding this comment.
Bug: Documentation Bug: Undefined Variable Reference
The code references decodedBody which is undefined. The previous line that decoded the request body with decodeURIComponent(req.body) was removed, but the code still tries to parse decodedBody. This will cause a runtime error when developers follow this documentation.
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (1)
content/docs/js-sdk/preparing-request.mdx (1)
58-58: Fix terminology: Change "Advance Options" to "Advanced Options"."Advance" is a verb/noun, while "Advanced" is the correct adjective form. This issue was flagged in the previous review and remains present.
Apply this diff:
-# Advance Options +# Advanced Options
🧹 Nitpick comments (1)
content/docs/js-sdk/preparing-request.mdx (1)
16-20: Align quickstart init example with advanced usage.The quickstart example (lines 16–20) shows a 3-parameter init call, but the "Advanced Options" section (line 70) demonstrates a 4-parameter init that includes
proofRequestOptions. To improve consistency and clarity for users who need advanced configuration, consider whether the quickstart should acknowledge or briefly reference this parameter, even if only in a note.Alternatively, add a brief clarification comment in the quickstart:
const reclaimProofRequest = await ReclaimProofRequest.init( 'APP_ID', 'APP_SECRET', 'PROVIDER_ID' -) +) +// Note: For advanced options like Remote Browser, pass a 4th parameter: proofRequestOptions
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
content/docs/js-sdk/preparing-request.mdx(3 hunks)
⏰ 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). (1)
- GitHub Check: Cursor Bugbot
🔇 Additional comments (1)
content/docs/js-sdk/preparing-request.mdx (1)
95-95: Verify parameter naming forsetAppCallbackUrl.Line 95 documents the parameter as
useJson, but a past comment from kryptocodes indicates the parameter should bejsonResponse. Confirm the actual SDK API signature to ensure the documentation matches the implementation.If the parameter is indeed
jsonResponse, update the documentation:-reclaimProofRequest.setAppCallbackUrl(url, useJson) +reclaimProofRequest.setAppCallbackUrl(url, jsonResponse)
| @@ -1,10 +1,9 @@ | |||
| { | |||
| "title": "JavaScript SDK", | |||
| "title": "Javascript SDK", | |||
There was a problem hiding this comment.
Bug: Standardize product name capitalization. (Bugbot Rules)
The title was changed from JavaScript SDK to Javascript SDK (lowercase 's'), but a reviewer explicitly commented "should stick with 'JavaScript SDK'". The proper capitalization for JavaScript is with an uppercase 'S'.
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (1)
content/docs/js-sdk/preparing-request.mdx (1)
58-58: Correct section heading: "Advance Options" → "Advanced Options"Per the previous review, "Advanced" is the correct adjective form; "Advance" is a verb/noun. This aligns with major documentation standards (Google, Microsoft).
Apply this diff:
-# Advance Options +# Advanced Options
🧹 Nitpick comments (2)
content/docs/js-sdk/preparing-request.mdx (2)
16-20: Clarify that the initialization accepts optional proofRequestOptions.The quickstart examples show a 3-parameter
init()call, while the "Advance Options" section (line 69) shows a 4-parameter version withproofRequestOptions. Consider adding a brief note thatproofRequestOptionsis optional, to set expectations for users who will discover advanced configuration later.Example note: "For advanced configuration options, see the 'Advanced Options' section below."
Also applies to: 41-45
93-99: Document the default value for theuseJsonparameter.Line 99 explains the behavior when
useJsonis true or false, but doesn't state the default value. Based on the prior review context, the default should befalse(URL-encoded form data). Consider adding:"By default (
useJsonisfalse), the POST body will contain the Proof JSON URL-encoded. SetuseJsontotrueto send raw JSON instead."Can you confirm the default value is
falseand that my suggested clarification is accurate?
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
content/docs/js-sdk/preparing-request.mdx(3 hunks)
⏰ 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). (1)
- GitHub Check: Cursor Bugbot
🔇 Additional comments (2)
content/docs/js-sdk/preparing-request.mdx (2)
73-79: Set Context section is clear and well-documented.The examples and parameter explanations are helpful and provide concrete guidance for users.
81-90: Set Parameters section provides clear guidance with good use-case examples.The explanation of the validation behavior (proof generation fails if parameters don't match) is important and well-documented.
Adding websdk to js-sdk.
Note
Revamps JS SDK docs with new flow guidance and advanced options, removes in-repo JS API reference, and adds an API reference entry to Flutter docs.
getStatusUrl), UI customization fortriggerReclaimFlow(options), extension detection, and redirect support.setContext,setParams,setAppCallbackUrl(url, useJson)).api-referencepage and its entry; minor title casing change inmeta.json.api-referencetocontent/docs/flutter/meta.jsonpages.Written by Cursor Bugbot for commit 26bb9c3. This will update automatically on new commits. Configure here.
Summary by CodeRabbit
Documentation
Breaking Changes