feat(ft-1848): update sdk docs to be learning-focused#261
Conversation
calthejuggler
requested review from
bmsilva,
marcio-absmartly and
mario-silva
as code owners
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (11)
✅ Files skipped from review due to trivial changes (4)
🚧 Files skipped from review as they are similar to previous changes (4)
WalkthroughReorganises the SDK documentation: removes the Advanced and several Basic Usage pages and many language-specific examples; updates category metadata and several category.json files; adds new shared guides (initialise, create context, selecting treatment/variable, peeking, publish, config API, custom event logger, complete examples) and numerous per-language example snippets across JavaScript, Python, React, Swift, Vue2/3, Java, Go, .NET, PHP, Ruby and Flutter/Dart. Multiple MDX files and code snippets were added, removed or edited; no runtime/source code (non-documentation) public APIs were changed. Estimated code review effort🎯 3 (Moderate) | ⏱️ ~28 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
calthejuggler
force-pushed
the
feat/ft-1848/learning-focused-sdk-documentation
branch
from
b5641a8 to
3b10f06
Compare
✅ Deploy Preview for absmartly-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 11
Note
Due to the large number of review comments, Critical, Major severity comments were prioritized as inline comments.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
docs/APIs-and-SDKs/SDK-Documentation/_shared/config-api/_config-api.mdx (1)
66-66:⚠️ Potential issue | 🔴 CriticalCorrect the API signature in _config-api.mdx to match the SDK implementation.
The shared component shows
context.mergeConfig(cfg)at line 66, but this is inconsistent with the actual JavaScript SDK API. The SDK exportsmergeConfigas a standalone function (as shown in the import statements in config-api.mdx and the implementation examples), not as a method on the context object. Line 66 should be updated to usemergeConfig(context, cfg)instead to match the correct API signature and prevent misleading developers.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/APIs-and-SDKs/SDK-Documentation/_shared/config-api/_config-api.mdx` at line 66, The doc uses the wrong API signature `context.mergeConfig(cfg)`; update the text to use the actual SDK function signature `mergeConfig(context, cfg)` so it matches the exported standalone function `mergeConfig` and the import/usage examples (look for references to mergeConfig and context in this document and replace the method-style call with the standalone function call).docs/APIs-and-SDKs/SDK-Documentation/_shared/overriding/react/override.js (1)
1-7:⚠️ Potential issue | 🟠 MajorWrap
useABSmartly()hook usage inside React component/custom hook context.React hook rules require hooks to be called only inside function components or custom hooks. This affects multiple React documentation snippets throughout the
_sharedfolder (override.js, trackingGoals.js, finalize.js, peekAtVariant.js, peekAtVariables.js, publish.js, customAssignment.js, and customAssignments.js). When developers copy these examples directly, they violate React's rules of hooks and cause runtime errors.Most documentation sections provide only the hook-usage example without a component wrapper. The setAttributes documentation provides an alternative
setAttributesAsProps.tsxexample that is properly component-wrapped, but this pattern should be applied consistently across all React snippets.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/APIs-and-SDKs/SDK-Documentation/_shared/overriding/react/override.js` around lines 1 - 7, The snippets call the React hook useABSmartly() at top-level which violates React's rules of hooks; wrap hook usage inside a functional React component or a custom hook so useABSmartly() is only invoked in component scope and then call context.override(...) / context.overrides(...) from that component or from a custom hook. Locate usages of useABSmartly in override.js (and the other listed _shared files like trackingGoals.js, finalize.js, peekAtVariant.js, peekAtVariables.js, publish.js, customAssignment.js, customAssignments.js) and change each example to demonstrate calling useABSmartly() inside a function component (or export a named custom hook) and then invoke context.override or context.overrides within that component/hook to preserve the original example behavior while complying with hook rules. Ensure examples consistently mirror the setAttributesAsProps.tsx pattern used elsewhere.
🟡 Minor comments (12)
docs/APIs-and-SDKs/SDK-Documentation/_shared/selecting-a-variable/swift/selectingAVariable.swift-1-2 (1)
1-2:⚠️ Potential issue | 🟡 MinorAdd a fallback when resolving
UIColorfrom a remote variable value.On line 2,
UIColor(named:)returns an optional and will benilwhen the asset name does not exist in the Asset Catalogue (including the default"blue"unless that asset is defined). This makes the example unreliable for readers as the button background colour will not be set.Suggested fix
let buttonColor = context.getVariableValue("button.color", defaultValue: "blue") -ctaButton.backgroundColor = UIColor(named: buttonColor) +ctaButton.backgroundColor = UIColor(named: buttonColor) ?? .blue🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/APIs-and-SDKs/SDK-Documentation/_shared/selecting-a-variable/swift/selectingAVariable.swift` around lines 1 - 2, The example uses UIColor(named:) which can return nil so ctaButton.backgroundColor may remain unset; update the resolution to try UIColor(named: buttonColor) and fall back to a concrete color (e.g., UIColor.blue or .systemBlue) if nil. Locate the usage of context.getVariableValue("button.color", defaultValue: "blue") and the subsequent UIColor(named: buttonColor) call, and replace it with a resolution that provides a non-optional color for ctaButton.backgroundColor by using a nil-coalescing fallback.docs/APIs-and-SDKs/SDK-Documentation/_shared/selecting-a-variable/js/selectingAVariable.js-1-2 (1)
1-2:⚠️ Potential issue | 🟡 MinorGuard against a missing CTA element before setting style.
Line 2 can throw if
#cta-buttonis not present in the page where this snippet is copied.Proposed fix
const buttonColor = context.variableValue("button.color", "blue"); -document.getElementById("cta-button").style.backgroundColor = buttonColor; +const ctaButton = document.getElementById("cta-button"); +if (ctaButton) { + ctaButton.style.backgroundColor = buttonColor; +}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/APIs-and-SDKs/SDK-Documentation/_shared/selecting-a-variable/js/selectingAVariable.js` around lines 1 - 2, The snippet assumes the CTA element exists and will throw when calling document.getElementById("cta-button").style; update the code that uses context.variableValue("button.color", "blue") and buttonColor by first retrieving the element via document.getElementById("cta-button"), check that the result is non-null (and optionally is an HTMLElement) before assigning element.style.backgroundColor = buttonColor, and skip or log a safe fallback when the element is missing.docs/APIs-and-SDKs/SDK-Documentation/_shared/custom-assignments/_custom-assignments.mdx-43-43 (1)
43-43:⚠️ Potential issue | 🟡 MinorUse standard “JavaScript” capitalisation in tab label.
This is a minor docs consistency typo.
✏️ Proposed fix
-<TabItem value="js" label="Javascript"> +<TabItem value="js" label="JavaScript">🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/APIs-and-SDKs/SDK-Documentation/_shared/custom-assignments/_custom-assignments.mdx` at line 43, Tab label uses nonstandard capitalization ("Javascript") in the TabItem component; update the TabItem with value="js" so its label prop is "JavaScript" (e.g., change label="Javascript" to label="JavaScript") to match standard capitalization across docs.docs/APIs-and-SDKs/SDK-Documentation/_shared/install/_install.mdx-91-93 (1)
91-93:⚠️ Potential issue | 🟡 MinorUse official "Next.js" spelling.
The official spelling of the framework is "Next.js" rather than "NextJS".
📝 Suggested fix
The ABSmartly React SDK selects and renders treatments on the -client-side. If you wish to use server-side rendering with NextJS or +client-side. If you wish to use server-side rendering with Next.js or similar, you will need to use the Javascript SDK or a combination of the two.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/APIs-and-SDKs/SDK-Documentation/_shared/install/_install.mdx` around lines 91 - 93, Update the incorrect capitalization of the framework name by replacing "NextJS" with the official "Next.js" in the sentence that currently reads "If you wish to use server-side rendering with NextJS or similar..." within the SDK install docs (search for the string "NextJS" or the paragraph beginning "The ABSmartly React SDK selects and renders treatments...") so the text uses the correct "Next.js" spelling wherever it appears.docs/APIs-and-SDKs/SDK-Documentation/_shared/peeking/_peeking.mdx-33-33 (1)
33-33:⚠️ Potential issue | 🟡 MinorUse standard “JavaScript” capitalisation in SDK list text.
Line [33] should read
JavaScriptfor consistency with the rest of the docs.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/APIs-and-SDKs/SDK-Documentation/_shared/peeking/_peeking.mdx` at line 33, Update the SDK list entry that currently reads "Javascript, React, Vue: `peek()`" to use the standard capitalization "JavaScript" instead; locate the list item referencing peek() (the line with `peek()`) and change "Javascript" → "JavaScript" so it matches the rest of the docs.docs/APIs-and-SDKs/SDK-Documentation/_selecting-a-variable-basic.mdx-19-19 (1)
19-19:⚠️ Potential issue | 🟡 MinorUse standard “JavaScript” capitalisation.
Line [19] should be
JavaScript(capital S) for consistency with SDK naming.Suggested patch
-<TabItem value="js" label="Javascript"> +<TabItem value="js" label="JavaScript">🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/APIs-and-SDKs/SDK-Documentation/_selecting-a-variable-basic.mdx` at line 19, The TabItem component currently uses the label "Javascript" (TabItem value="js" label="Javascript"); update the label prop to the correct capitalization "JavaScript" so it reads TabItem value="js" label="JavaScript" to match SDK naming and maintain consistency across docs.docs/APIs-and-SDKs/SDK-Documentation/_selecting-a-treatment-basic.mdx-23-23 (1)
23-23:⚠️ Potential issue | 🟡 MinorUse standard “JavaScript” capitalisation in tab label.
Line [23] should be
JavaScript(capital S).Suggested patch
-<TabItem value="js" label="Javascript"> +<TabItem value="js" label="JavaScript">🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/APIs-and-SDKs/SDK-Documentation/_selecting-a-treatment-basic.mdx` at line 23, The TabItem component's label currently uses "Javascript" with a lowercase "s"; update the TabItem element (value="js", label="Javascript") so its label reads "JavaScript" (capital S) to follow standard capitalization.docs/APIs-and-SDKs/SDK-Documentation/_shared/selecting-a-treatment/dotnet/selectingATreatment.cs-3-7 (1)
3-7:⚠️ Potential issue | 🟡 MinorAdd a default branch for non-binary treatment values.
Lines [3-7] only handle
0and1. Include anelseto model safe behaviour when experiment configurations evolve.Suggested patch
if (treatment == 0) { ShowBanner("Welcome back!"); } else if (treatment == 1) { ShowBanner("Check out our latest deals!"); +} else { + ShowBanner("Welcome back!"); }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/APIs-and-SDKs/SDK-Documentation/_shared/selecting-a-treatment/dotnet/selectingATreatment.cs` around lines 3 - 7, The conditional currently only handles treatment == 0 and treatment == 1 and must include a default branch to handle any other/unknown treatment values; update the if/else-if chain that checks the treatment variable (the block calling ShowBanner) to add a final else that either shows a safe fallback banner (e.g., a neutral message) or performs a safe no-op/log so unexpected treatment values are handled predictably.docs/APIs-and-SDKs/SDK-Documentation/getting-started.mdx-48-48 (1)
48-48:⚠️ Potential issue | 🟡 MinorUpdate the section title to match the new context flow.
Line 48 still says “Create a New Context Request”, which sounds like legacy wording. Given
<CreateContextBasic />, a simpler title like “Create a Context” would be clearer.Suggested edit
-## Create a New Context Request +## Create a Context🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/APIs-and-SDKs/SDK-Documentation/getting-started.mdx` at line 48, Change the section header text "Create a New Context Request" to the simpler, updated title "Create a Context" to match the new context flow and the <CreateContextBasic /> component; locate the heading near the <CreateContextBasic /> usage and replace the wording so the section title aligns with current terminology.docs/APIs-and-SDKs/SDK-Documentation/getting-started.mdx-37-38 (1)
37-38:⚠️ Potential issue | 🟡 MinorAdd a comma after “By default”.
Line 37 reads more cleanly with a comma after the introductory phrase.
Suggested edit
-By default these are handled automatically, but you can plug in a custom event logger if you need to: +By default, these are handled automatically, but you can plug in a custom event logger if you need to:🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/APIs-and-SDKs/SDK-Documentation/getting-started.mdx` around lines 37 - 38, Add a comma after the introductory phrase "By default" in the sentence that begins "By default these are handled automatically..." in getting-started.mdx so it reads "By default, these are handled automatically..."; update the text surrounding that phrase to preserve spacing and punctuation and ensure there are no double spaces introduced.docs/APIs-and-SDKs/SDK-Documentation/_initialize-basic.mdx-517-517 (1)
517-517:⚠️ Potential issue | 🟡 MinorAvoid linking to a likely non-existent anchor from this shared component.
Line 517 points to
#using-a-custom-event-logger, but this component is embedded and that anchor may not exist (especially when the target is a<details><summary>block, not a heading).Suggested edit
-| `eventLogger` | none | Callback that fires on SDK events (exposures, goals, errors). See the [custom event logger](`#using-a-custom-event-logger`) section below. | +| `eventLogger` | none | Callback that fires on SDK events (exposures, goals, errors). See the custom event logger section on this page. |🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/APIs-and-SDKs/SDK-Documentation/_initialize-basic.mdx` at line 517, The table references an anchor `#using-a-custom-event-logger` that may not exist in embedded contexts; update the `eventLogger` row to avoid linking to that fragile anchor by either removing the inline anchor link, replacing it with a reference to a stable section or page (e.g., “see custom event logger section”), or adding the actual heading/anchor to the document; target the `eventLogger` table cell in _initialize-basic.mdx and ensure the final text points to a reliable location or uses plain text so the link won't break when embedded.docs/APIs-and-SDKs/SDK-Documentation/_initialize-basic.mdx-375-376 (1)
375-376:⚠️ Potential issue | 🟡 MinorUse
HttpClientterminology in the .NET DI note for accuracy.Lines 375-376 reference
IHttpClientinstances, butIHttpClientFactory.CreateClient(string name)returns concreteSystem.Net.Http.HttpClientinstances, not the interface type. The documentation should refer toHttpClientto correctly describe what is created and used at runtime.Suggested edit
-`IHttpClient` instances with the name `ABSmartlySDK.HttpClient` (available as the static +`HttpClient` instances with the name `ABSmartlySDK.HttpClient` (available as the static🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/APIs-and-SDKs/SDK-Documentation/_initialize-basic.mdx` around lines 375 - 376, The docs incorrectly refer to `IHttpClient` instances; update the text to say that `IHttpClientFactory.CreateClient(ABSdk.HttpClientName)` returns concrete `System.Net.Http.HttpClient` instances and that the SDK registers clients under the name `ABSmartlySDK.HttpClient` (accessible via the static field `ABSdk.HttpClientName`), so replace occurrences of `IHttpClient` with `HttpClient` and adjust the sentence to mention `IHttpClientFactory.CreateClient(string name)` returns `HttpClient` at runtime.
🧹 Nitpick comments (12)
docs/APIs-and-SDKs/SDK-Documentation/_shared/publish/_publish.mdx (1)
33-33: Standardise JavaScript capitalisation.The label uses "Javascript" with a lowercase 's', but the standard spelling is "JavaScript" with a capital 'S'. The PR commits also mention standardising JavaScript capitalisation.
📝 Proposed fix for consistency
-<TabItem value="js" label="Javascript"> +<TabItem value="js" label="JavaScript">🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/APIs-and-SDKs/SDK-Documentation/_shared/publish/_publish.mdx` at line 33, Update the TabItem label to use the correct capitalization "JavaScript" instead of "Javascript"; locate the TabItem JSX/MDX element with attributes value="js" and label="Javascript" in _publish.mdx (the TabItem element) and change the label text to "JavaScript", and scan nearby TabItem occurrences in the same file to apply the same capitalization consistently.docs/APIs-and-SDKs/SDK-Documentation/_shared/selecting-a-treatment/vue/UsingOnlyDefaultSlot.vue (1)
2-8: Usefailedin the flow (or remove it from slot props).
failedis introduced on Line 2 but never used, so the example still implies a perpetual loading state when not ready. Consider adding an explicit failure branch to keep the learning path complete.Proposed tweak
<treatment name="exp_test_experiment"> <template `#default`="{ treatment, ready, failed }"> <template v-if="ready"> <my-button v-if="treatment == 0"></my-button> <my-button v-else-if="treatment == 1"></my-button> <my-other-button v-else-if="treatment == 2"></my-other-button> </template> - <template v-else><my-spinner></my-spinner></template> + <template v-else-if="failed">Unable to load treatment.</template> + <template v-else><my-spinner></my-spinner></template> </template> </treatment>🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/APIs-and-SDKs/SDK-Documentation/_shared/selecting-a-treatment/vue/UsingOnlyDefaultSlot.vue` around lines 2 - 8, Slot prop "failed" is declared in the default slot signature but never used, leaving no explicit failure state; either remove "failed" from the slot props or add a failure branch to the template that handles it. Locate the template with "#default" and the slot props { treatment, ready, failed } and update the conditional logic in that block: after checking ready, add an explicit branch (e.g., v-else-if="failed") to render an error/fallback UI (or a retry button/message), or delete "failed" from the prop list if failure handling is not intended. Ensure the chosen fix keeps treatment and ready checks intact and uses the same identifiers (treatment, ready, failed).docs/APIs-and-SDKs/SDK-Documentation/_shared/config-api/_config-api.mdx (1)
122-129: Consider clearer pseudocode notation.The arrow notation (
->) used in the pseudocode may be unclear to some readers, even though it's explicitly labelled as pseudocode on line 122. Consider using a more conventional format such as// calls treatment(...)comments or explicit arrows (→) to improve clarity.📝 Alternative pseudocode format
-{ - header: -> calls treatment("experiment1"), returns { en: "Our beautiful header!", nl: "Onze mooie kop!" } - call_to_action1: -> calls treatment("experiment2"), returns { en: "Click here!", nl: "Klik Hier" } -} +{ + header: // calls treatment("experiment1"), returns { en: "Our beautiful header!", nl: "Onze mooie kop!" } + call_to_action1: // calls treatment("experiment2"), returns { en: "Click here!", nl: "Klik Hier" } +}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/APIs-and-SDKs/SDK-Documentation/_shared/config-api/_config-api.mdx` around lines 122 - 129, Replace the unclear arrow pseudocode notation by explicitly commenting the behavior: for the returned object properties like header and call_to_action1, annotate that they call treatment("experiment1") and treatment("experiment2") respectively (reference symbols: header, call_to_action1, treatment, "experiment1", "experiment2") using a conventional inline comment style (e.g., header: { /* calls treatment("experiment1") -> returns {...} */ } ) or a clear arrow symbol (→) so readers understand these are getter properties that invoke treatment and return the localized objects.docs/APIs-and-SDKs/SDK-Documentation/config-api.mdx (1)
30-31: Consider using HTTPS in example URLs.The example URLs use
http://whilst the shared component examples usehttps://. For consistency and to model secure practices, consider using HTTPS throughout.🔒 Proposed change to use HTTPS
- ? "http://cdn.com/hero-new.png" - : "http://cdn.com/hero-default.png", + ? "https://cdn.com/hero-new.png" + : "https://cdn.com/hero-default.png",- hero_image: "http://cdn.com/hero-default.png", + hero_image: "https://cdn.com/hero-default.png",Also applies to: 47-47
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/APIs-and-SDKs/SDK-Documentation/config-api.mdx` around lines 30 - 31, Update the example URLs to use HTTPS: replace the literal strings "http://cdn.com/hero-new.png" and "http://cdn.com/hero-default.png" (and the other similar example URL noted in the comment) with "https://cdn.com/hero-new.png" and "https://cdn.com/hero-default.png" so the example uses secure HTTPS URLs consistently.docs/APIs-and-SDKs/SDK-Documentation/_shared/selecting-a-variable/dotnet/selectingAVariable.cs (1)
1-2: UseColor.Parse()to support both named colours and hex strings from experiment variables.Line 2 currently uses
Color.FromName(), which only handles named colours (e.g., "red", "blue"). If experiment variables can provide hex strings (e.g., "#1E90FF"), the code will fail. UseColor.Parse()orColor.TryParse()instead to handle both named colours and hex/CSS formats.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/APIs-and-SDKs/SDK-Documentation/_shared/selecting-a-variable/dotnet/selectingAVariable.cs` around lines 1 - 2, The call to Color.FromName in the ctaButton.BackgroundColor assignment only supports named colours and will fail for hex/CSS values returned by context.GetVariableValue; replace the use of Color.FromName with Color.Parse or Color.TryParse when handling the value from context.GetVariableValue("button.color", "blue") in order to accept both named and hex colours, and add a fallback (e.g., default "blue") when parsing fails before assigning to ctaButton.BackgroundColor.docs/APIs-and-SDKs/SDK-Documentation/complete-example/js/completeExample.js (1)
37-39: Consider adding a null check for robustness in documentation.While this is example code,
getElementByIdcan returnnullif the element doesn't exist. Adding a guard clause would demonstrate defensive coding practices to readers.♻️ Suggested improvement
- document.getElementById("cta-button").addEventListener("click", () => { - context.track("cta_click", { page: "homepage" }); - }); + const ctaButton = document.getElementById("cta-button"); + ctaButton?.addEventListener("click", () => { + context.track("cta_click", { page: "homepage" }); + });🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/APIs-and-SDKs/SDK-Documentation/complete-example/js/completeExample.js` around lines 37 - 39, The example currently calls document.getElementById("cta-button") and directly invokes addEventListener which can throw if the element is null; update the snippet to first capture the element (e.g., const btn = document.getElementById("cta-button")) and guard before attaching the handler so you only call btn.addEventListener(...) when btn is non-null (or log/throw a helpful message), keeping the existing context.track("cta_click", { page: "homepage" }) inside the guarded handler.docs/APIs-and-SDKs/SDK-Documentation/_selecting-a-treatment-basic.mdx (1)
62-102: Consider extracting duplicated Vue2/Vue3 details content.Lines [62-102] repeat the same explanatory block and snippets for Vue2 and Vue3. A shared MDX fragment/component would reduce maintenance drift.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/APIs-and-SDKs/SDK-Documentation/_selecting-a-treatment-basic.mdx` around lines 62 - 102, The Vue2 and Vue3 TabItem blocks duplicate the same explanatory content and snippets (the details section containing the CodeBlock usages of VueUsingTreatmentAlias, VueUsingTreatmentIndex, and VueUsingOnlyDefaultSlot); extract that repeated details section into a single reusable MDX fragment or component (e.g., <VueTreatmentDetails /> or an MDX import) and replace the duplicated details blocks inside both TabItem instances (symbols: TabItem, CodeBlock, VueUsingTreatmentAlias, VueUsingTreatmentIndex, VueUsingOnlyDefaultSlot) with the shared fragment so updates are centralized and maintenance drift is prevented.docs/APIs-and-SDKs/SDK-Documentation/_shared/custom-event-logger/_custom-event-logger.mdx (1)
42-42: Standardise “JavaScript” spelling in the naming note and tab label.Lines 42 and 49 use
Javascript; useJavaScriptfor consistency and polish.Suggested edit
-Javascript, React, Vue, and Flutter use `"finalize"` for the close event. +JavaScript, React, Vue, and Flutter use `"finalize"` for the close event. ... -<TabItem value="js" label="Javascript"> +<TabItem value="js" label="JavaScript">Also applies to: 49-49
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/APIs-and-SDKs/SDK-Documentation/_shared/custom-event-logger/_custom-event-logger.mdx` at line 42, The documentation contains two occurrences of the misspelled token "Javascript" (in the naming note and the tab label) that should be standardized to "JavaScript"; update both occurrences of the string "Javascript" to "JavaScript" (preserving surrounding punctuation and casing) in _custom-event-logger.mdx so the naming note and the tab label match the correct spelling.docs/APIs-and-SDKs/SDK-Documentation/complete-example/_complete-example.mdx (1)
20-20: Use “JavaScript” capitalisation consistently.Line 20 uses
Javascript, which is inconsistent with standard naming and other docs updates.Suggested edit
-<TabItem value="js" label="Javascript"> +<TabItem value="js" label="JavaScript">🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/APIs-and-SDKs/SDK-Documentation/complete-example/_complete-example.mdx` at line 20, Update the TabItem label that currently reads "Javascript" to the correct capitalization "JavaScript" (the element is TabItem with props value="js" label="Javascript") to ensure consistent naming across the docs; search for other TabItem instances or labels in _complete-example.mdx using "Javascript" and replace them with "JavaScript" where appropriate.docs/APIs-and-SDKs/SDK-Documentation/_shared/custom-event-logger/ruby/customEventLogger.rb (1)
5-15: Avoid logging raw event payloads in sample code.Printing full
datafor every event can leak sensitive attributes in real integrations. Prefer demonstrating filtered/redacted fields or event metadata only.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/APIs-and-SDKs/SDK-Documentation/_shared/custom-event-logger/ruby/customEventLogger.rb` around lines 5 - 15, The sample event handlers currently log the raw `data` for every case (references: the when branches for EVENT_TYPE::EXPOSURE, ::GOAL, ::ERROR, ::PUBLISH, ::READY, ::REFRESH and the puts "X: #{data}" calls); change these to avoid printing full payloads by logging only safe metadata or a redacted view. Implement or call a small helper (e.g., redact_event or extract_event_metadata) and replace each puts "…: #{data}" with a log of the helper output (for example: event type, timestamp, event id, and any allowed fields), or explicitly filter `data` to a whitelist of keys before logging. Ensure the change is applied to all when branches that currently output `data`.docs/APIs-and-SDKs/SDK-Documentation/_initialize-basic.mdx (1)
6-6: Standardise the tab label to “JavaScript”.Line 6 uses “Javascript”, which is inconsistent with standard capitalisation.
Suggested edit
-<TabItem value="js" label="Javascript"> +<TabItem value="js" label="JavaScript">🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/APIs-and-SDKs/SDK-Documentation/_initialize-basic.mdx` at line 6, Update the TabItem component label to use the standard capitalization "JavaScript" instead of "Javascript"; locate the TabItem element with value="js" and change its label prop from "Javascript" to "JavaScript" so the tab label matches standard styling.docs/APIs-and-SDKs/SDK-Documentation/_create-context-basic.mdx (1)
6-6: Standardise the tab label to “JavaScript”.Line 6 uses “Javascript”, which is inconsistent with standard capitalisation and the rest of the docs style.
Suggested edit
-<TabItem value="js" label="Javascript"> +<TabItem value="js" label="JavaScript">🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/APIs-and-SDKs/SDK-Documentation/_create-context-basic.mdx` at line 6, Update the TabItem component where label="Javascript" (TabItem value="js" label="Javascript") to use the correct capitalization "JavaScript" so it matches the project's docs style; locate the TabItem instance in _create-context-basic.mdx and change the label prop to "JavaScript".
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/APIs-and-SDKs/SDK-Documentation/_shared/peeking/_peeking.mdx`:
- Around line 128-130: The sentence incorrectly states both Python and Ruby use
peek_variable_value(); update the copy to list per-language method names: keep
peekVariableValue() for most SDKs, change the Python name to peek_variable() and
the Ruby name to peek_variable_value(); edit the sentence referencing
peekVariableValue() / peek_variable_value() to explicitly map "most SDKs:
peekVariableValue(), Python: peek_variable(), Ruby: peek_variable_value()" so
readers see the exact method names used in each SDK.
In `@docs/APIs-and-SDKs/SDK-Documentation/_shared/publish/react/publish.js`:
- Line 1: The call to useABSmartly() is at module scope which breaks React's
Rules of Hooks; move the hook call inside a function component or a custom hook
(e.g., create a component like PublishComponent or a hook like
usePublishContext) so that useABSmartly() is only invoked inside that function;
update any references that currently rely on the module-scoped const { context }
to instead retrieve context from the component/hook (for example call const {
context } = useABSmartly() inside PublishComponent or inside a new
usePublishContext wrapper) and export/use the component/hook consumers
accordingly.
In
`@docs/APIs-and-SDKs/SDK-Documentation/_shared/selecting-a-treatment/go/selectingATreatment.go`:
- Around line 1-7: The snippet discards the error from context.GetTreatment and
lacks a fallback for unexpected treatment values; update the code to check the
returned error from context.GetTreatment (do not ignore it), log or handle the
error and set a safe default treatment if an error occurs, and replace the
if/else chain with a switch or if/else that includes a default branch to handle
any treatment values other than 0 or 1 by calling showBanner with a generic
fallback message; refer to context.GetTreatment, the treatment variable, and
showBanner when making these changes.
In
`@docs/APIs-and-SDKs/SDK-Documentation/_shared/selecting-a-treatment/react/usingUseTreatment.js`:
- Around line 1-7: The example is invalid because useTreatment and return are
used at module scope; wrap the snippet inside a React component (e.g., function
HomepageBanner() or const HomepageBanner = () => { ... }) so that
useTreatment("homepage_banner_experiment") is called inside the component body
and the conditional returns render <Banner ... /> from within that component,
then export the component (export default HomepageBanner) so the example is
executable; keep the existing variant check and Banner usage unchanged.
In
`@docs/APIs-and-SDKs/SDK-Documentation/_shared/selecting-a-variable/flutter/selectingAVariable.dart`:
- Line 2: The ButtonStyle.backgroundColor field expects a WidgetStateProperty
(e.g., MaterialStateProperty<Color?>), but the code currently passes a raw Color
from colorFromName(buttonColor); update the ctaButton.style creation (the
ButtonStyle(...) call) to wrap the Color with a MaterialStateProperty such as
MaterialStateProperty.all<Color?>(colorFromName(buttonColor)) (or use
MaterialStateProperty.resolveWith if state-specific colors are needed) so the
backgroundColor parameter receives the correct WidgetStateProperty<Color?>?
type.
In
`@docs/APIs-and-SDKs/SDK-Documentation/_shared/selecting-a-variable/go/selectingAVariable.go`:
- Line 1: Change the call to context.GetVariableValue so you capture and check
the returned error instead of discarding it—assign to (buttonColor, err) from
GetVariableValue("button.color", "blue"), and if err != nil or the returned
value is empty, set buttonColor to the provided default ("blue") and handle/log
the error appropriately; update any surrounding code that assumes
GetVariableValue always succeeds (references: GetVariableValue, buttonColor).
In
`@docs/APIs-and-SDKs/SDK-Documentation/_shared/selecting-a-variable/react/inUseEffect.js`:
- Around line 1-4: The snippet is using useABSmartly() and a return at module
scope; wrap this logic inside a React functional component (e.g., a function
component that calls useABSmartly(), reads context.variableValue("button.color",
"blue") into buttonColor, and returns the <button> element) so the hook and
return are inside a component body; ensure the component is exported (default or
named) as needed and that useABSmartly is only called inside the component
scope.
In
`@docs/APIs-and-SDKs/SDK-Documentation/complete-example/dotnet/completeExample.cs`:
- Around line 1-3: The sample should be made null-safe and compilable by
replacing any GetService<IHttpClientFactory>() calls with
GetRequiredService<IHttpClientFactory>() to avoid null returns and by adding the
missing using directives for System.Collections.Generic and
Microsoft.Extensions.Http so Dictionary<string, object> and IHttpClientFactory
types resolve; update occurrences where Dictionary<string, object> is used
(e.g., the block around lines 47–57) to rely on the added using rather than
undeclared types and ensure any IHttpClientFactory usage references the non-null
value from GetRequiredService.
In `@docs/APIs-and-SDKs/SDK-Documentation/complete-example/go/completeExample.go`:
- Line 33: The example is discarding errors from SDK calls; update the code
around the ctx.GetTreatment and ctx.GetVariableValue calls to capture and handle
their returned errors (e.g., treatment, err :=
ctx.GetTreatment("homepage_banner_experiment") and similarly for
GetVariableValue), check err for nil, and then log/return/handle the error
instead of ignoring it so the example models explicit error handling; reference
the ctx variable and the GetTreatment and GetVariableValue methods when applying
the changes.
In
`@docs/APIs-and-SDKs/SDK-Documentation/complete-example/java/completeExample.java`:
- Around line 25-35: The example calls undefined methods showBanner(String
message) and setButtonColor(String color), causing compilation errors; add
simple private methods to the class with those exact signatures (e.g., private
void showBanner(String message) and private void setButtonColor(String color))
that perform minimal example behavior (log/print the message or set a mock UI
property) so the sample compiles and demonstrates usage of context.getTreatment
and context.getVariableValue; ensure method names and parameter types match the
calls in the snippet.
In `@docs/APIs-and-SDKs/SDK-Documentation/config-api.mdx`:
- Around line 44-54: The call to mergeConfig is using an incorrect signature;
mergeConfig accepts only the config object. Update the invocation that currently
passes context and config to call mergeConfig with only the config object
(replace mergeConfig(context, config) with mergeConfig(config)); ensure the
import of mergeConfig and the variable named config remain unchanged.
---
Outside diff comments:
In `@docs/APIs-and-SDKs/SDK-Documentation/_shared/config-api/_config-api.mdx`:
- Line 66: The doc uses the wrong API signature `context.mergeConfig(cfg)`;
update the text to use the actual SDK function signature `mergeConfig(context,
cfg)` so it matches the exported standalone function `mergeConfig` and the
import/usage examples (look for references to mergeConfig and context in this
document and replace the method-style call with the standalone function call).
In `@docs/APIs-and-SDKs/SDK-Documentation/_shared/overriding/react/override.js`:
- Around line 1-7: The snippets call the React hook useABSmartly() at top-level
which violates React's rules of hooks; wrap hook usage inside a functional React
component or a custom hook so useABSmartly() is only invoked in component scope
and then call context.override(...) / context.overrides(...) from that component
or from a custom hook. Locate usages of useABSmartly in override.js (and the
other listed _shared files like trackingGoals.js, finalize.js, peekAtVariant.js,
peekAtVariables.js, publish.js, customAssignment.js, customAssignments.js) and
change each example to demonstrate calling useABSmartly() inside a function
component (or export a named custom hook) and then invoke context.override or
context.overrides within that component/hook to preserve the original example
behavior while complying with hook rules. Ensure examples consistently mirror
the setAttributesAsProps.tsx pattern used elsewhere.
---
Minor comments:
In `@docs/APIs-and-SDKs/SDK-Documentation/_initialize-basic.mdx`:
- Line 517: The table references an anchor `#using-a-custom-event-logger` that
may not exist in embedded contexts; update the `eventLogger` row to avoid
linking to that fragile anchor by either removing the inline anchor link,
replacing it with a reference to a stable section or page (e.g., “see custom
event logger section”), or adding the actual heading/anchor to the document;
target the `eventLogger` table cell in _initialize-basic.mdx and ensure the
final text points to a reliable location or uses plain text so the link won't
break when embedded.
- Around line 375-376: The docs incorrectly refer to `IHttpClient` instances;
update the text to say that
`IHttpClientFactory.CreateClient(ABSdk.HttpClientName)` returns concrete
`System.Net.Http.HttpClient` instances and that the SDK registers clients under
the name `ABSmartlySDK.HttpClient` (accessible via the static field
`ABSdk.HttpClientName`), so replace occurrences of `IHttpClient` with
`HttpClient` and adjust the sentence to mention
`IHttpClientFactory.CreateClient(string name)` returns `HttpClient` at runtime.
In `@docs/APIs-and-SDKs/SDK-Documentation/_selecting-a-treatment-basic.mdx`:
- Line 23: The TabItem component's label currently uses "Javascript" with a
lowercase "s"; update the TabItem element (value="js", label="Javascript") so
its label reads "JavaScript" (capital S) to follow standard capitalization.
In `@docs/APIs-and-SDKs/SDK-Documentation/_selecting-a-variable-basic.mdx`:
- Line 19: The TabItem component currently uses the label "Javascript" (TabItem
value="js" label="Javascript"); update the label prop to the correct
capitalization "JavaScript" so it reads TabItem value="js" label="JavaScript" to
match SDK naming and maintain consistency across docs.
In
`@docs/APIs-and-SDKs/SDK-Documentation/_shared/custom-assignments/_custom-assignments.mdx`:
- Line 43: Tab label uses nonstandard capitalization ("Javascript") in the
TabItem component; update the TabItem with value="js" so its label prop is
"JavaScript" (e.g., change label="Javascript" to label="JavaScript") to match
standard capitalization across docs.
In `@docs/APIs-and-SDKs/SDK-Documentation/_shared/install/_install.mdx`:
- Around line 91-93: Update the incorrect capitalization of the framework name
by replacing "NextJS" with the official "Next.js" in the sentence that currently
reads "If you wish to use server-side rendering with NextJS or similar..."
within the SDK install docs (search for the string "NextJS" or the paragraph
beginning "The ABSmartly React SDK selects and renders treatments...") so the
text uses the correct "Next.js" spelling wherever it appears.
In `@docs/APIs-and-SDKs/SDK-Documentation/_shared/peeking/_peeking.mdx`:
- Line 33: Update the SDK list entry that currently reads "Javascript, React,
Vue: `peek()`" to use the standard capitalization "JavaScript" instead; locate
the list item referencing peek() (the line with `peek()`) and change
"Javascript" → "JavaScript" so it matches the rest of the docs.
In
`@docs/APIs-and-SDKs/SDK-Documentation/_shared/selecting-a-treatment/dotnet/selectingATreatment.cs`:
- Around line 3-7: The conditional currently only handles treatment == 0 and
treatment == 1 and must include a default branch to handle any other/unknown
treatment values; update the if/else-if chain that checks the treatment variable
(the block calling ShowBanner) to add a final else that either shows a safe
fallback banner (e.g., a neutral message) or performs a safe no-op/log so
unexpected treatment values are handled predictably.
In
`@docs/APIs-and-SDKs/SDK-Documentation/_shared/selecting-a-variable/js/selectingAVariable.js`:
- Around line 1-2: The snippet assumes the CTA element exists and will throw
when calling document.getElementById("cta-button").style; update the code that
uses context.variableValue("button.color", "blue") and buttonColor by first
retrieving the element via document.getElementById("cta-button"), check that the
result is non-null (and optionally is an HTMLElement) before assigning
element.style.backgroundColor = buttonColor, and skip or log a safe fallback
when the element is missing.
In
`@docs/APIs-and-SDKs/SDK-Documentation/_shared/selecting-a-variable/swift/selectingAVariable.swift`:
- Around line 1-2: The example uses UIColor(named:) which can return nil so
ctaButton.backgroundColor may remain unset; update the resolution to try
UIColor(named: buttonColor) and fall back to a concrete color (e.g.,
UIColor.blue or .systemBlue) if nil. Locate the usage of
context.getVariableValue("button.color", defaultValue: "blue") and the
subsequent UIColor(named: buttonColor) call, and replace it with a resolution
that provides a non-optional color for ctaButton.backgroundColor by using a
nil-coalescing fallback.
In `@docs/APIs-and-SDKs/SDK-Documentation/getting-started.mdx`:
- Line 48: Change the section header text "Create a New Context Request" to the
simpler, updated title "Create a Context" to match the new context flow and the
<CreateContextBasic /> component; locate the heading near the
<CreateContextBasic /> usage and replace the wording so the section title aligns
with current terminology.
- Around line 37-38: Add a comma after the introductory phrase "By default" in
the sentence that begins "By default these are handled automatically..." in
getting-started.mdx so it reads "By default, these are handled
automatically..."; update the text surrounding that phrase to preserve spacing
and punctuation and ensure there are no double spaces introduced.
---
Nitpick comments:
In `@docs/APIs-and-SDKs/SDK-Documentation/_create-context-basic.mdx`:
- Line 6: Update the TabItem component where label="Javascript" (TabItem
value="js" label="Javascript") to use the correct capitalization "JavaScript" so
it matches the project's docs style; locate the TabItem instance in
_create-context-basic.mdx and change the label prop to "JavaScript".
In `@docs/APIs-and-SDKs/SDK-Documentation/_initialize-basic.mdx`:
- Line 6: Update the TabItem component label to use the standard capitalization
"JavaScript" instead of "Javascript"; locate the TabItem element with value="js"
and change its label prop from "Javascript" to "JavaScript" so the tab label
matches standard styling.
In `@docs/APIs-and-SDKs/SDK-Documentation/_selecting-a-treatment-basic.mdx`:
- Around line 62-102: The Vue2 and Vue3 TabItem blocks duplicate the same
explanatory content and snippets (the details section containing the CodeBlock
usages of VueUsingTreatmentAlias, VueUsingTreatmentIndex, and
VueUsingOnlyDefaultSlot); extract that repeated details section into a single
reusable MDX fragment or component (e.g., <VueTreatmentDetails /> or an MDX
import) and replace the duplicated details blocks inside both TabItem instances
(symbols: TabItem, CodeBlock, VueUsingTreatmentAlias, VueUsingTreatmentIndex,
VueUsingOnlyDefaultSlot) with the shared fragment so updates are centralized and
maintenance drift is prevented.
In `@docs/APIs-and-SDKs/SDK-Documentation/_shared/config-api/_config-api.mdx`:
- Around line 122-129: Replace the unclear arrow pseudocode notation by
explicitly commenting the behavior: for the returned object properties like
header and call_to_action1, annotate that they call treatment("experiment1") and
treatment("experiment2") respectively (reference symbols: header,
call_to_action1, treatment, "experiment1", "experiment2") using a conventional
inline comment style (e.g., header: { /* calls treatment("experiment1") ->
returns {...} */ } ) or a clear arrow symbol (→) so readers understand these are
getter properties that invoke treatment and return the localized objects.
In
`@docs/APIs-and-SDKs/SDK-Documentation/_shared/custom-event-logger/_custom-event-logger.mdx`:
- Line 42: The documentation contains two occurrences of the misspelled token
"Javascript" (in the naming note and the tab label) that should be standardized
to "JavaScript"; update both occurrences of the string "Javascript" to
"JavaScript" (preserving surrounding punctuation and casing) in
_custom-event-logger.mdx so the naming note and the tab label match the correct
spelling.
In
`@docs/APIs-and-SDKs/SDK-Documentation/_shared/custom-event-logger/ruby/customEventLogger.rb`:
- Around line 5-15: The sample event handlers currently log the raw `data` for
every case (references: the when branches for EVENT_TYPE::EXPOSURE, ::GOAL,
::ERROR, ::PUBLISH, ::READY, ::REFRESH and the puts "X: #{data}" calls); change
these to avoid printing full payloads by logging only safe metadata or a
redacted view. Implement or call a small helper (e.g., redact_event or
extract_event_metadata) and replace each puts "…: #{data}" with a log of the
helper output (for example: event type, timestamp, event id, and any allowed
fields), or explicitly filter `data` to a whitelist of keys before logging.
Ensure the change is applied to all when branches that currently output `data`.
In `@docs/APIs-and-SDKs/SDK-Documentation/_shared/publish/_publish.mdx`:
- Line 33: Update the TabItem label to use the correct capitalization
"JavaScript" instead of "Javascript"; locate the TabItem JSX/MDX element with
attributes value="js" and label="Javascript" in _publish.mdx (the TabItem
element) and change the label text to "JavaScript", and scan nearby TabItem
occurrences in the same file to apply the same capitalization consistently.
In
`@docs/APIs-and-SDKs/SDK-Documentation/_shared/selecting-a-treatment/vue/UsingOnlyDefaultSlot.vue`:
- Around line 2-8: Slot prop "failed" is declared in the default slot signature
but never used, leaving no explicit failure state; either remove "failed" from
the slot props or add a failure branch to the template that handles it. Locate
the template with "#default" and the slot props { treatment, ready, failed } and
update the conditional logic in that block: after checking ready, add an
explicit branch (e.g., v-else-if="failed") to render an error/fallback UI (or a
retry button/message), or delete "failed" from the prop list if failure handling
is not intended. Ensure the chosen fix keeps treatment and ready checks intact
and uses the same identifiers (treatment, ready, failed).
In
`@docs/APIs-and-SDKs/SDK-Documentation/_shared/selecting-a-variable/dotnet/selectingAVariable.cs`:
- Around line 1-2: The call to Color.FromName in the ctaButton.BackgroundColor
assignment only supports named colours and will fail for hex/CSS values returned
by context.GetVariableValue; replace the use of Color.FromName with Color.Parse
or Color.TryParse when handling the value from
context.GetVariableValue("button.color", "blue") in order to accept both named
and hex colours, and add a fallback (e.g., default "blue") when parsing fails
before assigning to ctaButton.BackgroundColor.
In `@docs/APIs-and-SDKs/SDK-Documentation/complete-example/_complete-example.mdx`:
- Line 20: Update the TabItem label that currently reads "Javascript" to the
correct capitalization "JavaScript" (the element is TabItem with props
value="js" label="Javascript") to ensure consistent naming across the docs;
search for other TabItem instances or labels in _complete-example.mdx using
"Javascript" and replace them with "JavaScript" where appropriate.
In `@docs/APIs-and-SDKs/SDK-Documentation/complete-example/js/completeExample.js`:
- Around line 37-39: The example currently calls
document.getElementById("cta-button") and directly invokes addEventListener
which can throw if the element is null; update the snippet to first capture the
element (e.g., const btn = document.getElementById("cta-button")) and guard
before attaching the handler so you only call btn.addEventListener(...) when btn
is non-null (or log/throw a helpful message), keeping the existing
context.track("cta_click", { page: "homepage" }) inside the guarded handler.
In `@docs/APIs-and-SDKs/SDK-Documentation/config-api.mdx`:
- Around line 30-31: Update the example URLs to use HTTPS: replace the literal
strings "http://cdn.com/hero-new.png" and "http://cdn.com/hero-default.png" (and
the other similar example URL noted in the comment) with
"https://cdn.com/hero-new.png" and "https://cdn.com/hero-default.png" so the
example uses secure HTTPS URLs consistently.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
| The peek variable method returns the variable value just like `variableValue()`, | ||
| but without recording an exposure. It's called `peekVariableValue()` in most SDKs | ||
| and `peek_variable_value()` in Python and Ruby. |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify documented Python/Ruby variable peeking names against snippet implementations.
rg -nP 'peek_[a-z_]+\(' docs/APIs-and-SDKs/SDK-Documentation/_shared/peeking/python/peekAtVariables.py -C2
rg -nP 'peek_[a-z_]+\(' docs/APIs-and-SDKs/SDK-Documentation/_shared/peeking/ruby/peekAtVariables.rb -C2
rg -nP 'peek_variable_value' docs/APIs-and-SDKs/SDK-Documentation/_shared/peeking -C2Repository: absmartly/docs
Length of output: 963
Variable peeking method names differ between Python and Ruby SDKs.
Lines 128–130 claim both Python and Ruby use peek_variable_value(), but the actual implementations show:
- Python uses
peek_variable()(without_value) - Ruby uses
peek_variable_value()(with_value)
This documentation conflates two distinct method names and will mislead developers. Update to specify the correct names for each language.
Suggested patch
-The peek variable method returns the variable value just like `variableValue()`,
-but without recording an exposure. It's called `peekVariableValue()` in most SDKs
-and `peek_variable_value()` in Python and Ruby.
+The peek variable method returns the variable value just like `variableValue()`,
+but without recording an exposure. It's called `peekVariableValue()` in most SDKs
+and `peek_variable()` in Python and `peek_variable_value()` in Ruby.📝 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 peek variable method returns the variable value just like `variableValue()`, | |
| but without recording an exposure. It's called `peekVariableValue()` in most SDKs | |
| and `peek_variable_value()` in Python and Ruby. | |
| The peek variable method returns the variable value just like `variableValue()`, | |
| but without recording an exposure. It's called `peekVariableValue()` in most SDKs | |
| and `peek_variable()` in Python and `peek_variable_value()` in Ruby. |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/APIs-and-SDKs/SDK-Documentation/_shared/peeking/_peeking.mdx` around
lines 128 - 130, The sentence incorrectly states both Python and Ruby use
peek_variable_value(); update the copy to list per-language method names: keep
peekVariableValue() for most SDKs, change the Python name to peek_variable() and
the Ruby name to peek_variable_value(); edit the sentence referencing
peekVariableValue() / peek_variable_value() to explicitly map "most SDKs:
peekVariableValue(), Python: peek_variable(), Ruby: peek_variable_value()" so
readers see the exact method names used in each SDK.
There was a problem hiding this comment.
Checked the actual Python SDK source (sdk/context.py) -- the method is defined as peek_variable_value(), matching what the docs say. The SDK's README uses peek_variable() inconsistently, but that's a README issue, not a docs one. No change needed.
| treatment, _ := context.GetTreatment("homepage_banner_experiment") | ||
|
|
||
| if treatment == 0 { | ||
| showBanner("Welcome back!") | ||
| } else if treatment == 1 { | ||
| showBanner("Check out our latest deals!") | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify whether treatment examples are currently ignoring Go SDK errors.
rg -nP --type=go '^\s*\w+\s*,\s*_\s*:=\s*context\.GetTreatment\(' -C2
rg -nP --type=go '\bGetTreatment\s*\(' -C2Repository: absmartly/docs
Length of output: 1327
🏁 Script executed:
cat -n docs/APIs-and-SDKs/SDK-Documentation/_shared/selecting-a-treatment/go/selectingATreatment.goRepository: absmartly/docs
Length of output: 301
Add error handling and fallback treatment branch to the Go canonical example.
Line 1 discards the error from GetTreatment, and lines 3–7 lack a fallback path for treatment values outside 0 and 1. In a learning-focused guide, this pattern teaches incomplete error handling and leaves unhandled treatments unspecified.
Suggested patch
-treatment, _ := context.GetTreatment("homepage_banner_experiment")
+treatment, err := context.GetTreatment("homepage_banner_experiment")
+if err != nil {
+ // handle/log error and fall back to a safe default
+ showBanner("Welcome back!")
+ return
+}
if treatment == 0 {
showBanner("Welcome back!")
} else if treatment == 1 {
showBanner("Check out our latest deals!")
+} else {
+ showBanner("Welcome back!")
}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@docs/APIs-and-SDKs/SDK-Documentation/_shared/selecting-a-treatment/go/selectingATreatment.go`
around lines 1 - 7, The snippet discards the error from context.GetTreatment and
lacks a fallback for unexpected treatment values; update the code to check the
returned error from context.GetTreatment (do not ignore it), log or handle the
error and set a safe default treatment if an error occurs, and replace the
if/else chain with a switch or if/else that includes a default branch to handle
any treatment values other than 0 or 1 by calling showBanner with a generic
fallback message; refer to context.GetTreatment, the treatment variable, and
showBanner when making these changes.
There was a problem hiding this comment.
Valid observation, but this is a focused snippet teaching treatment selection, not production Go. Adding error handling here would obscure the concept being taught. The complete example page handles this more thoroughly.
| const { variant } = useTreatment("homepage_banner_experiment"); | ||
|
|
||
| if (variant === 0) { | ||
| return <Banner text="Welcome back!" />; | ||
| } | ||
|
|
||
| return <Banner text="Check out our latest deals!" />; |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
FILE='docs/APIs-and-SDKs/SDK-Documentation/_shared/selecting-a-treatment/react/usingUseTreatment.js'
echo "== File content =="
nl -ba "$FILE"
echo "== Top-level return statements (should be none in a valid module snippet) =="
rg -nP '^\s*return\b' "$FILE"
echo "== Hook call placement =="
rg -nP '^\s*const\s*\{\s*variant\s*\}\s*=\s*useTreatment\s*\(' "$FILE"
echo "== Component/function wrapper detection =="
rg -nP '^\s*(export\s+default\s+function\s+\w+\s*\(|function\s+\w+\s*\(|const\s+\w+\s*=\s*\([^)]*\)\s*=>|const\s+\w+\s*=\s*function\s*\()' "$FILE" || trueRepository: absmartly/docs
Length of output: 136
🏁 Script executed:
#!/bin/bash
set -euo pipefail
FILE='docs/APIs-and-SDKs/SDK-Documentation/_shared/selecting-a-treatment/react/usingUseTreatment.js'
echo "== File exists and content =="
if [ -f "$FILE" ]; then
cat -n "$FILE"
else
echo "File not found: $FILE"
exit 1
fi
echo ""
echo "== Top-level return statements =="
rg -nP '^\s*return\b' "$FILE" || echo "No top-level return statements found"
echo ""
echo "== Hook call placement (useTreatment) =="
rg -n 'useTreatment' "$FILE" || echo "No useTreatment calls found"
echo ""
echo "== Component/function wrapper detection =="
rg -nP '(function|=>|const\s+\w+\s*=)' "$FILE" | head -5 || echo "No function/component wrappers found"Repository: absmartly/docs
Length of output: 645
Wrap this snippet in a React component; it is currently invalid JavaScript.
Lines 4 and 7 contain return statements at module scope, which violates JavaScript syntax. Line 1 calls useTreatment() outside a component or custom hook, which violates React Hooks rules. The example must be wrapped in a component to be executable and correct.
Proposed fix
-const { variant } = useTreatment("homepage_banner_experiment");
-
-if (variant === 0) {
- return <Banner text="Welcome back!" />;
-}
-
-return <Banner text="Check out our latest deals!" />;
+export default function HomepageBanner() {
+ const { variant } = useTreatment("homepage_banner_experiment");
+
+ if (variant === 0) {
+ return <Banner text="Welcome back!" />;
+ } else {
+ return <Banner text="Check out our latest deals!" />;
+ }
+}📝 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.
| const { variant } = useTreatment("homepage_banner_experiment"); | |
| if (variant === 0) { | |
| return <Banner text="Welcome back!" />; | |
| } | |
| return <Banner text="Check out our latest deals!" />; | |
| export default function HomepageBanner() { | |
| const { variant } = useTreatment("homepage_banner_experiment"); | |
| if (variant === 0) { | |
| return <Banner text="Welcome back!" />; | |
| } else { | |
| return <Banner text="Check out our latest deals!" />; | |
| } | |
| } |
🧰 Tools
🪛 Biome (2.4.11)
[error] 4-4: Illegal return statement outside of a function
(parse)
[error] 7-7: Illegal return statement outside of a function
(parse)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@docs/APIs-and-SDKs/SDK-Documentation/_shared/selecting-a-treatment/react/usingUseTreatment.js`
around lines 1 - 7, The example is invalid because useTreatment and return are
used at module scope; wrap the snippet inside a React component (e.g., function
HomepageBanner() or const HomepageBanner = () => { ... }) so that
useTreatment("homepage_banner_experiment") is called inside the component body
and the conditional returns render <Banner ... /> from within that component,
then export the component (export default HomepageBanner) so the example is
executable; keep the existing variant check and Banner usage unchanged.
There was a problem hiding this comment.
Same pattern as all other React snippets in the repo -- these are partial component body fragments shown in MDX context, not standalone files. Wrapping this one would be inconsistent with every other React snippet.
| @@ -0,0 +1,2 @@ | |||
| final buttonColor = context.getVariableValue("button.color", "blue"); | |||
| ctaButton.style = ButtonStyle(backgroundColor: colorFromName(buttonColor)); | |||
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Verify the documented type for ButtonStyle.backgroundColor.
curl -fsSL https://api.flutter.dev/flutter/material/ButtonStyle/backgroundColor.html \
| rg -n "MaterialStateProperty|WidgetStateProperty|Color"
# Verify styleFrom is a supported way to set a solid background colour.
curl -fsSL https://api.flutter.dev/flutter/material/ElevatedButton/styleFrom.html \
| rg -n "backgroundColor|ButtonStyle"Repository: absmartly/docs
Length of output: 3515
🏁 Script executed:
find . -type f -name "selectingAVariable.dart" 2>/dev/nullRepository: absmartly/docs
Length of output: 157
🏁 Script executed:
head -n 5 "./docs/APIs-and-SDKs/SDK-Documentation/_shared/selecting-a-variable/flutter/selectingAVariable.dart"Repository: absmartly/docs
Length of output: 203
Use a Flutter-compatible ButtonStyle background colour assignment.
Line 2 passes a raw Color into ButtonStyle.backgroundColor, which does not match the Flutter API type expected for this field (WidgetStateProperty<Color?>?), causing compile errors for documentation consumers.
✅ Suggested fix
-ctaButton.style = ButtonStyle(backgroundColor: colorFromName(buttonColor));
+ctaButton.style = ElevatedButton.styleFrom(
+ backgroundColor: colorFromName(buttonColor),
+);📝 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.
| ctaButton.style = ButtonStyle(backgroundColor: colorFromName(buttonColor)); | |
| ctaButton.style = ElevatedButton.styleFrom( | |
| backgroundColor: colorFromName(buttonColor), | |
| ); |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@docs/APIs-and-SDKs/SDK-Documentation/_shared/selecting-a-variable/flutter/selectingAVariable.dart`
at line 2, The ButtonStyle.backgroundColor field expects a WidgetStateProperty
(e.g., MaterialStateProperty<Color?>), but the code currently passes a raw Color
from colorFromName(buttonColor); update the ctaButton.style creation (the
ButtonStyle(...) call) to wrap the Color with a MaterialStateProperty such as
MaterialStateProperty.all<Color?>(colorFromName(buttonColor)) (or use
MaterialStateProperty.resolveWith if state-specific colors are needed) so the
backgroundColor parameter receives the correct WidgetStateProperty<Color?>?
type.
There was a problem hiding this comment.
Technically correct about the Flutter API, but this snippet illustrates how to use an ABSmartly variable value, not how to use Flutter's ButtonStyle API. The colorFromName helper is fictional anyway. Adding WidgetStateProperty.all() wrapping would be Flutter boilerplate that distracts from the point.
There was a problem hiding this comment.
@calthejuggler, that's a fair point — the snippet is clearly scoped to demonstrating how to retrieve and apply an ABSmartly variable value, and colorFromName being fictional already signals to readers that the surrounding Flutter code is illustrative rather than production-ready. Adding WidgetStateProperty.all() wrapping would shift the reader's focus away from the SDK interaction toward Flutter internals. Happy to leave it as-is.
🐇💭
✏️ Learnings added
Learnt from: calthejuggler
Repo: absmartly/docs PR: 261
File: docs/APIs-and-SDKs/SDK-Documentation/_shared/selecting-a-variable/flutter/selectingAVariable.dart:2-2
Timestamp: 2026-04-15T12:30:21.510Z
Learning: In the absmartly/docs repository, Flutter (and other platform-specific) code snippets in the SDK documentation are intentionally simplified and may use fictional helpers (e.g., `colorFromName`) to keep focus on ABSmartly SDK usage. Platform-specific boilerplate (e.g., Flutter's `WidgetStateProperty.all()`) should not be flagged as an issue in these illustrative snippets.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
| const { context } = useABSmartly(); | ||
| const buttonColor = context.variableValue("button.color", "blue"); | ||
|
|
||
| return <button style={{ backgroundColor: buttonColor }}>Get Started</button>; |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify the current syntax issue by locating top-level returns in this snippet.
rg -n -C2 '^\s*return\b' docs/APIs-and-SDKs/SDK-Documentation/_shared/selecting-a-variable/react/inUseEffect.jsRepository: absmartly/docs
Length of output: 209
🏁 Script executed:
cat -n docs/APIs-and-SDKs/SDK-Documentation/_shared/selecting-a-variable/react/inUseEffect.jsRepository: absmartly/docs
Length of output: 267
Wrap code inside a function or component to make return valid.
The file currently has a return statement at line 4 that exists at module scope, which is invalid JavaScript syntax. The code must be wrapped in a function or component body for the return statement to be valid.
Suggested fix
+import { useABSmartly } from "@absmartly/react-sdk";
+
+export default function CTAButton() {
-const { context } = useABSmartly();
-const buttonColor = context.variableValue("button.color", "blue");
+ const { context } = useABSmartly();
+ const buttonColor = context.variableValue("button.color", "blue");
-return <button style={{ backgroundColor: buttonColor }}>Get Started</button>;
+ return <button style={{ backgroundColor: buttonColor }}>Get Started</button>;
+}📝 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.
| const { context } = useABSmartly(); | |
| const buttonColor = context.variableValue("button.color", "blue"); | |
| return <button style={{ backgroundColor: buttonColor }}>Get Started</button>; | |
| import { useABSmartly } from "@absmartly/react-sdk"; | |
| export default function CTAButton() { | |
| const { context } = useABSmartly(); | |
| const buttonColor = context.variableValue("button.color", "blue"); | |
| return <button style={{ backgroundColor: buttonColor }}>Get Started</button>; | |
| } |
🧰 Tools
🪛 Biome (2.4.11)
[error] 4-4: Illegal return statement outside of a function
(parse)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@docs/APIs-and-SDKs/SDK-Documentation/_shared/selecting-a-variable/react/inUseEffect.js`
around lines 1 - 4, The snippet is using useABSmartly() and a return at module
scope; wrap this logic inside a React functional component (e.g., a function
component that calls useABSmartly(), reads context.variableValue("button.color",
"blue") into buttonColor, and returns the <button> element) so the hook and
return are inside a component body; ensure the component is exported (default or
named) as needed and that useABSmartly is only called inside the component
scope.
There was a problem hiding this comment.
Same deliberate pattern as all React snippets in the repo. These are partial component body fragments embedded in MDX, not standalone JS files.
There was a problem hiding this comment.
@calthejuggler, understood — thanks for the clarification! These are intentional partial component body fragments meant to be embedded in MDX documentation, not standalone executable JS files, so the top-level return and hook calls are expected. I'll note this pattern for future reviews.
✏️ Learnings added
Learnt from: calthejuggler
Repo: absmartly/docs PR: 261
File: docs/APIs-and-SDKs/SDK-Documentation/_shared/selecting-a-variable/react/inUseEffect.js:1-4
Timestamp: 2026-04-15T12:32:02.214Z
Learning: In the absmartly/docs repository, React `.js` files under `docs/APIs-and-SDKs/SDK-Documentation/_shared/` (and similar shared snippet directories) are intentionally partial component body fragments embedded in MDX documentation pages. They are not standalone JS files. Top-level `return` statements, hook calls (e.g., `useABSmartly()`), and missing function/component wrappers are deliberate — do not flag these as syntax errors or missing component wrappers.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
| if (context.getTreatment("homepage_banner_experiment") == 1) { | ||
| // Variant B: show a personalized banner | ||
| showBanner("Welcome back, we have new deals for you!"); | ||
| } else { | ||
| // Variant A (control): show the existing banner | ||
| showBanner("Welcome back!"); | ||
| } | ||
|
|
||
| // Use a variable set in the Web Console for more flexibility | ||
| String buttonColor = context.getVariableValue("button.color", "blue"); | ||
| setButtonColor(buttonColor); |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify whether helper methods are declared anywhere in Java docs snippets.
rg -nP --type=java '\b(static\s+)?void\s+(showBanner|setButtonColor)\s*\(' -C2Repository: absmartly/docs
Length of output: 40
🏁 Script executed:
cat -n docs/APIs-and-SDKs/SDK-Documentation/complete-example/java/completeExample.javaRepository: absmartly/docs
Length of output: 2190
Add missing method definitions to make the Java example compilable.
Lines 27, 30, and 35 call showBanner() and setButtonColor() methods, but these are not defined in the class. The example will not compile as provided.
Suggested edit
public class ExperimentExample {
public static void main(String[] args) {
@@
}
}
+
+ private static void showBanner(String text) {
+ System.out.println(text);
+ }
+
+ private static void setButtonColor(String color) {
+ System.out.println("Button colour: " + color);
+ }
}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@docs/APIs-and-SDKs/SDK-Documentation/complete-example/java/completeExample.java`
around lines 25 - 35, The example calls undefined methods showBanner(String
message) and setButtonColor(String color), causing compilation errors; add
simple private methods to the class with those exact signatures (e.g., private
void showBanner(String message) and private void setButtonColor(String color))
that perform minimal example behavior (log/print the message or set a mock UI
property) so the sample compiles and demonstrates usage of context.getTreatment
and context.getVariableValue; ensure method names and parameter types match the
calls in the snippet.
There was a problem hiding this comment.
Calling undefined placeholder methods like showBanner() and setButtonColor() is intentional -- they represent "your app logic here." This is consistent across all language examples (Go, Python, etc. all do the same thing). Readers understand they need to implement these themselves.
There was a problem hiding this comment.
@calthejuggler, understood! That's a sensible documentation pattern — placeholder method calls like showBanner() and setButtonColor() serve as clear signals to readers about where their own application logic should go, without cluttering the snippet with irrelevant boilerplate. I'll note this for future reviews.
(∧ ω ∧)
✏️ Learnings added
Learnt from: calthejuggler
Repo: absmartly/docs PR: 261
File: docs/APIs-and-SDKs/SDK-Documentation/complete-example/java/completeExample.java:25-35
Timestamp: 2026-04-15T12:34:06.121Z
Learning: In the absmartly/docs repository, complete example snippets (e.g., `docs/APIs-and-SDKs/SDK-Documentation/complete-example/`) across all SDK languages (Java, Go, Python, Flutter/Dart, etc.) intentionally call undefined placeholder methods such as `showBanner()` and `setButtonColor()` to represent "your app logic here." These are not compilation errors to be flagged; they are deliberate pedagogical placeholders consistent across all language examples. Do not raise issues about undefined helper methods in these complete example files.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
🧠 Learnings used
Learnt from: calthejuggler
Repo: absmartly/docs PR: 261
File: docs/APIs-and-SDKs/SDK-Documentation/_shared/selecting-a-variable/flutter/selectingAVariable.dart:2-2
Timestamp: 2026-04-15T12:30:21.510Z
Learning: In the absmartly/docs repository, Flutter (and other platform-specific) code snippets in the SDK documentation are intentionally simplified and may use fictional helpers (e.g., `colorFromName`) to keep focus on ABSmartly SDK usage. Platform-specific boilerplate (e.g., Flutter's `WidgetStateProperty.all()`) should not be flagged as an issue in these illustrative snippets.
| import { mergeConfig } from "@absmartly/javascript-sdk"; | ||
|
|
||
| let config = { | ||
| hero_image: "http://cdn.com/hero-default.png", | ||
| button: { | ||
| color: "blue", | ||
| cta: "Learn more", | ||
| }, | ||
| }; | ||
|
|
||
| config = mergeConfig(context, config); |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Verify the correct mergeConfig API signature and import path
# Search for package.json to confirm the package name
fd -e json package.json --exec cat {} \; | jq -r '.name' 2>/dev/null | head -5
# Look for mergeConfig exports in JavaScript SDK files
fd -e js -e ts . --exec rg -l 'export.*mergeConfig' {} \;
# Check for any existing documentation or examples of mergeConfig usage
rg -n -C3 'mergeConfig' --type=js --type=tsRepository: absmartly/docs
Length of output: 1661
🏁 Script executed:
# Check the _config-api.mdx file referenced in the review comment (line 66)
fd -n '_config-api.mdx' -x cat -n {} | head -80Repository: absmartly/docs
Length of output: 288
🏁 Script executed:
# Look at the full context of the mergeConfig examples
cat -n docs/APIs-and-SDKs/SDK-Documentation/_shared/config-api/js/mergeConfig.jsRepository: absmartly/docs
Length of output: 538
🏁 Script executed:
# Look at the full context of mergeTranslationConfigs.js
cat -n docs/APIs-and-SDKs/SDK-Documentation/_shared/config-api/js/mergeTranslationConfigs.jsRepository: absmartly/docs
Length of output: 206
🏁 Script executed:
# Find and display the _config-api.mdx file
fd '_config-api.mdx' -type fRepository: absmartly/docs
Length of output: 228
🏁 Script executed:
# If found, read the file around line 66
find . -name '_config-api.mdx' -type f -exec cat -n {} \; | sed -n '50,80p'Repository: absmartly/docs
Length of output: 1177
🏁 Script executed:
# Search for context object creation and mergeConfig method
rg -n 'context\s*=' --type=js --type=ts -A 5 | head -40Repository: absmartly/docs
Length of output: 3122
🏁 Script executed:
# Look for any TypeScript definitions or .d.ts files
fd -e 'd.ts' -e 'ts'Repository: absmartly/docs
Length of output: 186
🏁 Script executed:
# Search for SDK setup or initialization that might show the actual API
rg -n -C3 'createContext\|getContext\|javascript-sdk' docs/Repository: absmartly/docs
Length of output: 40
🌐 Web query:
@absmartly/javascript-sdk mergeConfig API documentation
💡 Result:
The mergeConfig function is part of the @absmartly/javascript-sdk's Config API, designed to integrate A/B experiment treatments into application configuration objects seamlessly. Import: import { mergeConfig } from "@absmartly/javascript-sdk"; Usage: const myAppConfig = mergeConfig(getConfigFromFile('config.json')); This wraps config values with getters that automatically call context.treatment(experimentName) when accessed, applying the assigned variant without manual treatment calls. Example: Original config: let cfg = { button: { color: "blue", cta: "Click me", }, hero_image: "http://cdn.com/img1.png", }; After mergeConfig(cfg) with experiments 'button_color' (variant "green") and 'homepage_cta' (variant "Click here"): { button: { get color { context.treatment("button_color"); return "green"; }, get cta { context.treatment("homepage_cta"); return "Click here"; }, }, get hero_image { context.treatment("homepage_cta"); return "http://cdn.com/img1.png"; }, } This simplifies experiment integration into config-driven apps, automatically tracking treatments on access. Works with nested objects and supports internationalization examples like translations. Official documentation: https://docs.absmartly.com/docs/apis-and-sdks/sdk-documentation/basic-usage/ Source reference in SDK: config.js file (1.8KB) in package.
Citations:
- 1: https://docs.absmartly.com/docs/apis-and-sdks/sdk-documentation/getting-started/
- 2: https://docs.absmartly.com/docs/apis-and-sdks/sdk-documentation/
- 3: https://www.npmjs.com/package/@absmartly/javascript-sdk
- 4: https://github.com/absmartly/javascript-sdk
- 5: https://docs.absmartly.com/docs/SDK-Documentation/getting-started
- 6: https://docs.absmartly.com/docs/apis-and-sdks/sdk-documentation/basic-usage/
- 7: https://www.github.com/absmartly/javascript-sdk
🌐 Web query:
site:npmjs.com @absmartly/javascript-sdk mergeConfig
💡 Result:
mergeConfig is not explicitly documented in the official ABsmartly JavaScript SDK documentation or README files across npm, GitHub repository, and docs.absmartly.com. However, the SDK package includes a config.js file (1.8KB in es/ and lib/ directories) as part of its source code structure, suggesting configuration merging or handling functionality exists internally, likely for merging SDK options like endpoint, apiKey, environment, and application during SDK instantiation (new absmartly.SDK({ ... })). No public API or usage example for a 'mergeConfig' method or function was found in available sources. For exact implementation, inspect the source code from the GitHub repo https://github.com/absmartly/javascript-sdk or unpkg.com/@absmartly/javascript-sdk/es/config.js.
Citations:
- 1: https://www.npmjs.com/package/@absmartly/javascript-sdk
- 2: https://github.com/absmartly/javascript-sdk
- 3: https://docs.absmartly.com/docs/apis-and-sdks/sdk-documentation/getting-started/
🏁 Script executed:
# Search for other uses of mergeConfig in the docs to see if there's a pattern
rg -n 'mergeConfig' docs/ --type=mdx --type=js --type=ts -B 2 -A 2Repository: absmartly/docs
Length of output: 85
🏁 Script executed:
# Search for other uses of mergeConfig in the docs with broader approach
rg -n 'mergeConfig' docs/ -B 2 -A 2Repository: absmartly/docs
Length of output: 4636
Correct the mergeConfig() function signature—it accepts only the config object, not the context.
The function signature shown on line 54 is incorrect. According to the official SDK documentation and examples, mergeConfig() takes a single parameter (the config object only), not the context as the first parameter:
config = mergeConfig(config);Remove the context parameter. The SDK handles the context internally when the wrapped config properties are accessed.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/APIs-and-SDKs/SDK-Documentation/config-api.mdx` around lines 44 - 54,
The call to mergeConfig is using an incorrect signature; mergeConfig accepts
only the config object. Update the invocation that currently passes context and
config to call mergeConfig with only the config object (replace
mergeConfig(context, config) with mergeConfig(config)); ensure the import of
mergeConfig and the variable named config remain unchanged.
There was a problem hiding this comment.
Checked the actual SDK source (javascript-sdk/src/config.ts). The function signature is mergeConfig(context, previousConfig) -- it does take context as the first parameter. The documentation is correct. This comment is factually wrong.
There was a problem hiding this comment.
@calthejuggler, thank you for verifying this directly against the SDK source. You're absolutely right — my comment was incorrect. The mergeConfig function signature in javascript-sdk/src/config.ts is mergeConfig(context, previousConfig), and the documentation as written is correct. I apologise for the noise.
✏️ Learnings added
Learnt from: calthejuggler
Repo: absmartly/docs PR: 261
File: docs/APIs-and-SDKs/SDK-Documentation/config-api.mdx:44-54
Timestamp: 2026-04-15T12:36:03.201Z
Learning: In the `absmartly/javascript-sdk`, the `mergeConfig` function signature is `mergeConfig(context, previousConfig)` — it takes the ABSmartly context as the first parameter and the config object as the second. The correct usage is `config = mergeConfig(context, config)`. Do not flag this as incorrect in future reviews of the absmartly/docs repository.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
🧠 Learnings used
Learnt from: calthejuggler
Repo: absmartly/docs PR: 261
File: docs/APIs-and-SDKs/SDK-Documentation/_shared/selecting-a-variable/react/inUseEffect.js:1-4
Timestamp: 2026-04-15T12:32:02.214Z
Learning: In the absmartly/docs repository, React `.js` files under `docs/APIs-and-SDKs/SDK-Documentation/_shared/` (and similar shared snippet directories) are intentionally partial component body fragments embedded in MDX documentation pages. They are not standalone JS files. Top-level `return` statements, hook calls (e.g., `useABSmartly()`), and missing function/component wrappers are deliberate — do not flag these as syntax errors or missing component wrappers.
9644943 to
fc5061c
Compare
1 participant
This PR updates the SDK documentation to take a learning-focused approach, instead of the previous reference-focused approach that it had before.
Summary by CodeRabbit