feat: integrate AOSSIE-Org social share button in navbar#182
feat: integrate AOSSIE-Org social share button in navbar#182amankv1234 wants to merge 2 commits into
Conversation
WalkthroughThis PR integrates a SocialShareButton widget loaded from a jsDelivr CDN into the frontend. ChangesSocial Share Button Integration
Estimated code review effort: 2 (Simple) | ~15 minutes Sequence Diagram(s)sequenceDiagram
participant Navbar
participant Window as window.SocialShareButton
participant DOM as share-button div
Navbar->>Window: poll for availability
Window-->>Navbar: instance available
Navbar->>DOM: initialize into `#share-button`
Navbar->>Navbar: store instance in shareButtonRef
Navbar->>Window: update url/title on route change
Navbar->>Window: destroy() on unmount
Possibly related PRs
Suggested labels: Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (2 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment Warning |
|
@kpj2006 @rahul-vyas-dev , check this pr |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@frontend/index.html`:
- Around line 25-28: The external SocialShareButton assets loaded in index.html
are missing Subresource Integrity protection. Update the stylesheet link in the
page (and the matching script include referenced in the review) to add integrity
and crossorigin attributes, using the pinned CDN asset versions, so the browser
can verify the third-party content before applying it.
- Line 45: Add a loading attribute to the external SocialShareButton script so
it no longer blocks HTML parsing/rendering; update the classic script tag in
index.html to use defer (or async if appropriate) while keeping the widget load
behavior intact. Locate the change by the SocialShareButton CDN script reference
and ensure the script still executes after the document starts loading without
delaying initial render.
In `@frontend/src/components/Navbar.jsx`:
- Around line 267-275: The share widget is only rendered in the desktop navbar,
so mobile/tablet users cannot access it. Update Navbar.jsx by adding an
equivalent share-button entry to the mobile menu rendering path in addition to
the existing `#share-button` container in the desktop nav, using the same share
widget mount point so the feature is available across breakpoints.
- Around line 77-84: The Navbar useEffect that updates shareButtonRef.current
via updateOptions only tracks location.pathname and location.hash, so
query-string-only navigation is missed. Update the dependency array to include
location.search alongside the existing location fields so the share widget
refreshes whenever the full URL changes.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 0dabd2ae-030e-4dab-990b-345b343303e1
📒 Files selected for processing (3)
frontend/.env.examplefrontend/index.htmlfrontend/src/components/Navbar.jsx
💤 Files with no reviewable changes (1)
- frontend/.env.example
| useEffect(() => { | ||
| const initButton = () => { | ||
| if (initRef.current || !window.SocialShareButton) return; | ||
|
|
||
| shareButtonRef.current = new window.SocialShareButton({ | ||
| container: "#share-button", | ||
| }); | ||
| initRef.current = true; | ||
| }; | ||
|
|
||
| if (window.SocialShareButton) { | ||
| initButton(); | ||
| } | ||
|
|
||
| const checkInterval = setInterval(() => { | ||
| if (window.SocialShareButton) { | ||
| clearInterval(checkInterval); | ||
| initButton(); | ||
| } | ||
| }, 100); | ||
|
|
||
| return () => { | ||
| clearInterval(checkInterval); | ||
| if (shareButtonRef.current?.destroy) { | ||
| shareButtonRef.current.destroy(); | ||
| } | ||
| initRef.current = false; | ||
| }; | ||
| }, []); | ||
|
|
||
| useEffect(() => { | ||
| if (shareButtonRef.current?.updateOptions) { | ||
| shareButtonRef.current.updateOptions({ | ||
| url: window.location.href, | ||
| title: document.title, | ||
| }); | ||
| } | ||
| }, [location.pathname, location.hash]); |
There was a problem hiding this comment.
@CodeRabbit i think this is not needed in chainvoice(client) code, i think we are handling this inside https://github.com/AOSSIE-Org/SocialShareButton
There was a problem hiding this comment.
The PR description image shows a "Chainvoice" landing page in dark theme rendered at localhost:5173. The top navbar shows the Chainvoice logo/text on the left, and on the right: a "Share" button (with a share/link icon), an "About" button (with an info icon), and a green "Connect Wallet" button. The hero section shows "Web3 Invoicing Made Simple" headline, supporting text about end-to-end encryption and multi-chain support, three feature pill badges ("Lit Protocol Encrypted", "Multi-chain Support", "End-to-End Security"), and a preview card on the right showing an invoicing table with columns Client, Receiver, Amount, Status, Date, Actions, with a "Encrypted with Lit Protocol" callout badge at the bottom right. At the bottom, a centered tagline reads "Military-Grade Security Powered by Lit Protocol".
@kpj2006 That makes sense — if AOSSIE-Org/SocialShareButton already handles initialization, cleanup, and URL/title updates internally (e.g., via its own DOM-ready detection and reading window.location/document.title at share-time), then the polling loop, initRef/shareButtonRef bookkeeping, and the updateOptions effect in frontend/src/components/Navbar.jsx (Line 47-84) are redundant for Chainvoice's purposes. Keeping just the <div id="share-button"></div> mount point plus the CDN script/style tags in frontend/index.html should be enough for a minimal integration, consistent with issue #174's ask for a very minimal integration without extra fallback/error handling.
I'll skip flagging the lifecycle-management code going forward for this integration pattern.
✏️ Learnings added
Learnt from: kpj2006
Repo: StabilityNexus/Chainvoice PR: 182
File: frontend/src/components/Navbar.jsx:47-84
Timestamp: 2026-07-03T21:52:53.113Z
Learning: In the Chainvoice frontend (StabilityNexus/Chainvoice), the SocialShareButton widget is loaded from AOSSIE-Org/SocialShareButton via CDN script/CSS tags in `frontend/index.html`. Per PR author kpj2006, that library handles its own initialization, cleanup, and URL/title updates internally, so consuming code (e.g., `frontend/src/components/Navbar.jsx`) does not need to implement polling for `window.SocialShareButton`, manual init/destroy guards, or `updateOptions` calls on route change — a minimal `<div id="share-button"></div>` mount point is sufficient.
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.
There was a problem hiding this comment.
@CodeRabbit suggest the changes need to be done for @amankv1234
There was a problem hiding this comment.
@kpj2006, tagging @amankv1234 — here's the suggested simplification for frontend/src/components/Navbar.jsx based on the confirmation that AOSSIE-Org/SocialShareButton handles its own init/cleanup/URL-update lifecycle internally:
--- a/frontend/src/components/Navbar.jsx
+++ b/frontend/src/components/Navbar.jsx
@@ -1,6 +1,6 @@
import { ConnectButton } from "`@rainbow-me/rainbowkit`";
import NetworkSwitcher from "./NetworkSwitcher";
-import { useEffect, useState, useRef } from "react";
+import { useEffect, useState } from "react";
import { Link, useNavigate, useLocation } from "react-router-dom";
import { useAccount } from "wagmi";
import AccountBalanceWalletIcon from "`@mui/icons-material/AccountBalanceWallet`";
@@ -16,8 +16,6 @@ function Navbar() {
const [hasConnected, setHasConnected] = useState(false);
const [isScrolled, setIsScrolled] = useState(false);
const [isMobileMenuOpen, setIsMobileMenuOpen] = useState(false);
- const shareButtonRef = useRef(null);
- const initRef = useRef(false);
// Improved active route detection
const isActive = (path) => {
@@ -44,45 +42,6 @@ function Navbar() {
window.addEventListener("scroll", handleScroll);
return () => window.removeEventListener("scroll", handleScroll);
}, [isConnected, hasConnected, navigate, location.pathname, address]);
- useEffect(() => {
- const initButton = () => {
- if (initRef.current || !window.SocialShareButton) return;
-
- shareButtonRef.current = new window.SocialShareButton({
- container: "`#share-button`",
- });
- initRef.current = true;
- };
-
- if (window.SocialShareButton) {
- initButton();
- }
-
- const checkInterval = setInterval(() => {
- if (window.SocialShareButton) {
- clearInterval(checkInterval);
- initButton();
- }
- }, 100);
-
- return () => {
- clearInterval(checkInterval);
- if (shareButtonRef.current?.destroy) {
- shareButtonRef.current.destroy();
- }
- initRef.current = false;
- };
- }, []);
-
- useEffect(() => {
- if (shareButtonRef.current?.updateOptions) {
- shareButtonRef.current.updateOptions({
- url: window.location.href,
- title: document.title,
- });
- }
- }, [location.pathname, location.hash]);This leaves only the <div id="share-button"></div> mount container in the desktop nav (around Line 267-275) untouched, letting the CDN-loaded AOSSIE-Org/SocialShareButton script fully own initialization, cleanup, and URL/title updates — consistent with the "very minimal integration, no extra fallback/error handling" ask in issue #174.
If you'd like, let me know and I can kick off a formal plan for these code changes.
🧠 Learnings used
Learnt from: kpj2006
Repo: StabilityNexus/Chainvoice PR: 182
File: frontend/src/components/Navbar.jsx:47-84
Timestamp: 2026-07-03T21:52:53.113Z
Learning: In StabilityNexus/Chainvoice’s frontend, when using the SocialShareButton widget loaded from AOSSIE-Org/SocialShareButton via CDN tags in `frontend/index.html`, do not add consumer-side polling or lifecycle guards around `window.SocialShareButton` (e.g., no manual init/destroy, no route-change `updateOptions` calls). The CDN library handles initialization, cleanup, and URL/title updates internally. In components (such as `Navbar.jsx`), only provide the minimal mount element (e.g., `<div id="share-button"></div>`) and let the library manage the rest.
There was a problem hiding this comment.
@CodeRabbit
We removed the useEffect block that initializes SocialShareButton from frontend/src/components/Navbar.jsx. After committing the change, the share button no longer appears in the UI even though:
- The CDN script
https://cdn.jsdelivr.net/gh/AOSSIE-Org/[email protected]/src/social-share-button.jsloads successfully (network status 200). - The placeholder
<div id="share-button"></div>is still rendered in the Navbar component. - No console errors are shown.
Why does deleting the useEffect cause the button to disappear? Explain the role of that effect in the React app, how the library works (it only defines window.SocialShareButton and does not auto‑mount), and why we need to call new window.SocialShareButton({ container: '#share-button' }) after the component mounts. Also mention any side‑effects of the effect (e.g., interval cleanup, URL updates) that are needed for the button to work correctly.
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
curl -sL "https://cdn.jsdelivr.net/gh/AOSSIE-Org/[email protected]/src/social-share-button.js" -o /tmp/ssb.js
wc -l /tmp/ssb.js
echo "---- full file ----"
cat -n /tmp/ssb.js
echo "---- searching for auto-init patterns ----"
grep -nE 'DOMContentLoaded|querySelector|data-social|auto|window\.addEventListener|new SocialShareButton|module.exports|export default' /tmp/ssb.jsLength of output: 21355
@kpj2006, I re-fetched and read the entire social-share-button.js v1.0.3 source (all 398 lines, not just the constructor) to double-check, and I have to stand by the earlier analysis — the library does not auto-mount itself anywhere.
Here's the full picture from the source:
-
No auto-init hook exists anywhere in the file. I grepped for
DOMContentLoaded,querySelector-based auto-scanning of the whole document,data-*attribute conventions, or any top-level executed code — there is none. The only code that runs at script-load time is at the very bottom (Line 391-398):if (typeof module !== 'undefined' && module.exports) { module.exports = SocialShareButton; } if (typeof window !== 'undefined') { window.SocialShareButton = SocialShareButton; }
That's it — it just attaches the class constructor to
window. Nothing else executes. -
The constructor only self-inits if you already gave it a container (Line 33-35):
if (this.options.container) { this.init(); }
If nobody ever calls
new window.SocialShareButton({ container: ... }),init()never runs,createButton()never runs, and nothing is ever appended into#share-button. A bare<div id="share-button"></div>with the script loaded but never instantiated will stay empty forever — which matches exactly what amankv1234 observed after theuseEffectwas removed. -
destroy()(Line 332-340) exists, but it's an instance method — something has to hold a reference to the created instance and call.destroy()on it. The library itself never calls this; it's on the consumer to invoke it (e.g., on unmount). -
updateOptions()(Line 342-357) also exists as an instance method that merges new options and updates the modal's URL input value. Again, nothing inside the library calls this automatically onpopstateor route change — the consumer must call it explicitly.
So to directly answer your question: no, there is no "native ruleset" or self-initialization logic hidden in this library that mounts, destroys, or updates the button on your behalf. It's intentionally minimal — it hands you a class with init()/destroy()/updateOptions() methods, but Chainvoice's own code (the removed useEffect in Navbar.jsx) is what has to wire those methods to the component lifecycle and the mount point. Without that glue code, the button won't appear, which is consistent with what amankv1234 reported.
I'd still recommend restoring the useEffect block (polling for window.SocialShareButton, constructing the instance, and cleaning up on unmount) plus the updateOptions effect on route change, since those are the only things that actually invoke the library against #share-button.
(・_・;) — hope this settles the source-level question conclusively.
🧠 Learnings used
Learnt from: amankv1234
Repo: StabilityNexus/Chainvoice PR: 182
File: frontend/src/components/Navbar.jsx:47-84
Timestamp: 2026-07-04T07:53:27.931Z
Learning: In StabilityNexus/Chainvoice frontend, the AOSSIE-Org/SocialShareButton loaded via the CDN script/CSS in frontend/index.html only defines `window.SocialShareButton` (it does not auto-mount/init). When using it from React components, you must explicitly instantiate it after the script is loaded (e.g., poll/guard until `window.SocialShareButton` exists) with an explicit `container` option: `new window.SocialShareButton({ container: '`#share-button`' })`. A bare `<div id="share-button"></div>` is not sufficient. On remount/re-render, prevent duplicate instantiation (e.g., track via a ref flag). In cleanup, call `.destroy()` to avoid leftover/duplicate buttons. On route changes, call `.updateOptions({ url, title })` because the instance captures `url`/`title` at construction and does not automatically recompute them.
There was a problem hiding this comment.
@CodeRabbit suggest what minimal we need to include in client codebase and for that minimal what we need to changes in social-button codebase.
Because The main purpose for this library is to provide minimal code to our client and handling all the functioning on behalf of them, not everything in client codebase.
There was a problem hiding this comment.
@kpj2006, that's a fair goal, and it's achievable — but it requires adding auto-init capability to the library itself, since right now nothing in social-share-button.js v1.0.3 does that (confirmed from the full source in my earlier script run: the file only assigns window.SocialShareButton = SocialShareButton at the bottom, and init() only runs if a container was passed to the constructor explicitly).
Here's the split of responsibilities I'd suggest:
1. Changes needed in AOSSIE-Org/SocialShareButton
Add a small auto-init routine that runs once the script itself loads, so Chainvoice (and any other consumer) never has to write lifecycle code:
// At the bottom of social-share-button.js, after window.SocialShareButton = SocialShareButton;
function autoInit() {
document.querySelectorAll('[data-social-share]').forEach((el) => {
if (el.__socialShareInstance) return; // avoid duplicate init
el.__socialShareInstance = new SocialShareButton({
container: el,
url: el.dataset.url || window.location.href,
title: el.dataset.title || document.title,
});
});
}
if (typeof document !== 'undefined') {
if (document.readyState === 'loading') {
document.addEventListener('DOMContentLoaded', autoInit);
} else {
autoInit();
}
// Keep url/title fresh across SPA route changes without consumer code
['popstate', 'hashchange'].forEach((evt) =>
window.addEventListener(evt, () => {
document.querySelectorAll('[data-social-share]').forEach((el) => {
el.__socialShareInstance?.updateOptions?.({
url: window.location.href,
title: document.title,
});
});
})
);
// Auto-cleanup if the container is removed from the DOM (e.g., SPA unmount)
const observer = new MutationObserver(() => {
document.querySelectorAll('[data-social-share]').forEach((el) => {
if (!document.body.contains(el) && el.__socialShareInstance) {
el.__socialShareInstance.destroy?.();
el.__socialShareInstance = null;
}
});
});
observer.observe(document.body, { childList: true, subtree: true });
}This shifts the polling/init/destroy/updateOptions responsibilities you currently have in Navbar.jsx entirely into the library, keyed off a data-social-share attribute rather than requiring the consumer to call new window.SocialShareButton(...) at all. SPA route changes for React Router (which don't fire native popstate on pushState) would still need a hashchange/manual dispatch, but that's a library-side concern, not something Chainvoice should own.
2. Minimal code needed in Chainvoice (frontend/src/components/Navbar.jsx / frontend/index.html)
Once that auto-init exists upstream, Chainvoice only needs:
<!-- frontend/index.html — unchanged from current PR -->
<link rel="stylesheet" href="https://cdn.jsdelivr.net/gh/AOSSIE-Org/[email protected]/src/social-share-button.css" />
<script src="https://cdn.jsdelivr.net/gh/AOSSIE-Org/[email protected]/src/social-share-button.js"></script>{/* frontend/src/components/Navbar.jsx — no useEffect, no refs, no imports needed */}
<div data-social-share></div>No useRef, no useEffect, no polling, no destroy(), no updateOptions() calls in Chainvoice's codebase at all.
Until the library ships that
Since [email protected] (the currently pinned CDN version) doesn't have this auto-init behavior yet, the polling useEffect block that was removed from Navbar.jsx (Line 47-84 in the diff) is currently the only thing that makes the button actually appear and stay in sync with route changes. I'd suggest either:
- Restoring that
useEffectblock now (since it works against the current library version), and later removing it once an auto-init release ships upstream, or - Opening this as a feature request/PR against
AOSSIE-Org/SocialShareButtonfirst, pinning Chainvoice to that new version once released, and only then stripping theuseEffectfromNavbar.jsx.
Want me to open a follow-up issue on AOSSIE-Org/SocialShareButton (or in this repo, if you want to track it here) requesting the auto-init feature, so this isn't lost?
(・_・) ノ
✏️ Learnings added
Learnt from: kpj2006
Repo: StabilityNexus/Chainvoice PR: 182
File: frontend/src/components/Navbar.jsx:47-84
Timestamp: 2026-07-04T08:22:59.212Z
Learning: In StabilityNexus/Chainvoice PR `#182`, PR author kpj2006's design intent for the AOSSIE-Org/SocialShareButton integration is that the library itself should be responsible for all init/cleanup/URL-update behavior, so that `frontend/src/components/Navbar.jsx` only needs a minimal DOM element and no JS lifecycle code. As of the currently pinned CDN version (v1.0.3), the library does NOT support this (see other learning about v1.0.3 requiring explicit instantiation) — achieving the desired minimal client integration requires upstream changes to `AOSSIE-Org/SocialShareButton` (e.g., an auto-init routine keyed off a `data-social-share` attribute, with internal route-change listeners and MutationObserver-based cleanup) before Chainvoice's `Navbar.jsx` can safely drop its `useEffect`-based polling/init/destroy/updateOptions code.
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: amankv1234
Repo: StabilityNexus/Chainvoice PR: 182
File: frontend/src/components/Navbar.jsx:47-84
Timestamp: 2026-07-04T07:53:27.931Z
Learning: In StabilityNexus/Chainvoice frontend, the AOSSIE-Org/SocialShareButton loaded via the CDN script/CSS in frontend/index.html only defines `window.SocialShareButton` (it does not auto-mount/init). When using it from React components, you must explicitly instantiate it after the script is loaded (e.g., poll/guard until `window.SocialShareButton` exists) with an explicit `container` option: `new window.SocialShareButton({ container: '`#share-button`' })`. A bare `<div id="share-button"></div>` is not sufficient. On remount/re-render, prevent duplicate instantiation (e.g., track via a ref flag). In cleanup, call `.destroy()` to avoid leftover/duplicate buttons. On route changes, call `.updateOptions({ url, title })` because the instance captures `url`/`title` at construction and does not automatically recompute them.
There was a problem hiding this comment.
@CodeRabbit could you create an issue for above in social-share-button repo and their steps to verify such that client need to write minimal code?
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
repo="AOSSIE-Org/SocialShareButton"
body=$(cat <<'EOF'
## Summary
Consumers of `SocialShareButton` (e.g., StabilityNexus/Chainvoice) currently have to write custom lifecycle glue code around the library because the CDN script only attaches the `SocialShareButton` class to `window` and does not auto-mount, auto-cleanup, or auto-update itself. Today's consumer code must:
- Poll for `window.SocialShareButton` to exist (since script/DOM load order is not guaranteed).
- Manually call `new window.SocialShareButton({ container: '`#id`' })` to render the button.
- Track whether it's already initialized to avoid duplicate buttons on re-render/remount.
- Manually call `.destroy()` on unmount to avoid leftover/duplicate instances.
- Manually call `.updateOptions({ url, title })` on every route change, since `url`/`title` are captured once at construction time and never recomputed automatically.
This defeats the goal of the library: providing a minimal-code drop-in share button for client applications, especially SPAs using client-side routing (e.g., React Router) where native `popstate` does not fire on `pushState`.
## Proposed change
Add an opt-in auto-init routine to `social-share-button.js` that:
1. Scans the DOM for elements marked with a `data-social-share` attribute (or similar convention) on script load (`DOMContentLoaded` or immediately if already loaded), and instantiates `SocialShareButton` for each, using `data-url` / `data-title` attributes (falling back to `window.location.href` / `document.title`).
2. Guards against duplicate initialization per element (e.g., store the instance on the element itself).
3. Listens for `popstate` and `hashchange` to call `updateOptions({ url, title })` automatically. For SPA frameworks that use `history.pushState` without dispatching `popstate`, consider patching `history.pushState`/`replaceState` or documenting a small manual "notify" API consumers can call.
4. Cleans up automatically when the container is removed from the DOM (e.g., via a `MutationObserver` calling `.destroy()`), so SPA route unmounts don't leak instances.
## Rationale
Discussed in StabilityNexus/Chainvoice PR `#182`, where the integration currently requires ~40 lines of `useEffect`-based polling/init/destroy/updateOptions glue in `frontend/src/components/Navbar.jsx` just to use the library correctly. This is the opposite of the library's stated goal of minimal client-side integration.
## Affected areas
- `src/social-share-button.js` (constructor/auto-init logic, currently only assigns `window.SocialShareButton = SocialShareButton` at the bottom with no auto-init hook)
- Documentation / README (usage instructions should show the new minimal `data-social-share` attribute usage, and clarify SPA route-change behavior)
## Acceptance criteria
- [ ] A consumer can add `<div data-social-share></div>` to any page/component with only the CDN `<script>`/`<link>` tags, no additional JS required, and the button renders correctly.
- [ ] The share button reflects the current page URL/title without any consumer-side polling, initialization, or cleanup code.
- [ ] On SPA route changes (React Router or similar), the shared URL/title updates without consumer code (native `popstate`/`hashchange`, or a documented lightweight hook for `pushState`-based routers).
- [ ] Removing the container element from the DOM (e.g., component unmount in a SPA) does not leak duplicate button instances if the element is re-added later.
- [ ] No duplicate buttons are created if the auto-init logic runs more than once (e.g., React Strict Mode double-invoking effects, or the script being re-evaluated).
## Steps to verify
1. Include only the CDN `<script>` and `<link>` tags plus `<div data-social-share></div>` in a test HTML page — verify the share button renders without any extra JS.
2. Click the share button and confirm the shared URL/title match the current page.
3. In a SPA test harness (e.g., a small React Router app), navigate between routes and confirm the share button's URL/title update automatically, with no consumer glue code.
4. Mount/unmount the container element repeatedly and confirm no duplicate buttons or memory leaks (e.g., check via DOM inspection or a leak-detection script).
5. Verify existing manual usage (`new SocialShareButton({ container: ... })`) continues to work unchanged for backward compatibility.
## References
- StabilityNexus/Chainvoice PR: https://github.com/StabilityNexus/Chainvoice/pull/182
- Discussion comment: https://github.com/StabilityNexus/Chainvoice/pull/182#discussion_r3521950132
Requested by: `@kpj2006`
EOF
)
gh issue create \
--repo "$repo" \
--title "Add auto-init/auto-cleanup support so consumers need minimal integration code" \
--body "$body" \
--assignee "kpj2006" || \
gh issue create \
--repo "$repo" \
--title "Add auto-init/auto-cleanup support so consumers need minimal integration code" \
--body "$body"Length of output: 5235
@kpj2006, done — I've opened the issue on AOSSIE-Org/SocialShareButton:
AOSSIE-Org/SocialShareButton#166
It covers:
- Summary/rationale: why consumer apps like Chainvoice currently need ~40 lines of
useEffectglue (polling, init/destroy,updateOptions) just to use the library. - Proposed change: an opt-in auto-init routine keyed off a
data-social-shareattribute, with automaticpopstate/hashchange-based URL/title updates, andMutationObserver-based auto-cleanup when the container is removed from the DOM. - Affected areas:
src/social-share-button.jsand the README/usage docs. - Acceptance criteria and step-by-step verification steps (minimal HTML usage test, SPA route-change test, mount/unmount leak test, backward-compat check for existing manual
new SocialShareButton({ container })usage). - Backlinks to this PR (
#182) and this discussion thread.
Note: I wasn't able to assign the issue to you directly — GitHub's API returned Resource not accessible by integration when trying to set an assignee on that external repo (CodeRabbit's GitHub App doesn't have assignment permissions there), so the issue was created unassigned. You may want to self-assign it or ping a maintainer once you're ready to pick it up.
Once that upstream change ships, Chainvoice's Navbar.jsx can drop back down to a minimal <div data-social-share></div> (or similar) with no useEffect/useRef lifecycle code at all — until then, I'd still recommend keeping the current polling/init/destroy/updateOptions logic in frontend/src/components/Navbar.jsx so the button keeps working.
🧠 Learnings used
Learnt from: amankv1234
Repo: StabilityNexus/Chainvoice PR: 182
File: frontend/src/components/Navbar.jsx:47-84
Timestamp: 2026-07-04T07:53:27.931Z
Learning: In StabilityNexus/Chainvoice frontend, the AOSSIE-Org/SocialShareButton loaded via the CDN script/CSS in frontend/index.html only defines `window.SocialShareButton` (it does not auto-mount/init). When using it from React components, you must explicitly instantiate it after the script is loaded (e.g., poll/guard until `window.SocialShareButton` exists) with an explicit `container` option: `new window.SocialShareButton({ container: '`#share-button`' })`. A bare `<div id="share-button"></div>` is not sufficient. On remount/re-render, prevent duplicate instantiation (e.g., track via a ref flag). In cleanup, call `.destroy()` to avoid leftover/duplicate buttons. On route changes, call `.updateOptions({ url, title })` because the instance captures `url`/`title` at construction and does not automatically recompute them.
|
Could you please close PR #177 if you're no longer working on it? It would be better to keep only one PR open per issue/feature to avoid confusion. Thanks! |
3 participants
Addressed Issues:
Fixes #174
Screenshots
Recording
https://drive.google.com/file/d/1NjEXvqA7HSJeMXhnsashJSc43WsLafeQ/view?usp=sharing
Check one of the checkboxes below:
I have used the following AI models and tools: TODO
Checklist
Summary by CodeRabbit