feat: integrate AOSSIE-Org social share button in navbar #182

kpj2006 · 2026-07-03T21:51:48Z

@CodeRabbit i think this is not needed in chainvoice(client) code, i think we are handling this inside https://github.com/AOSSIE-Org/SocialShareButton

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.

@CodeRabbit suggest the changes need to be done for @amankv1234

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

@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.js loads 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.

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

Length 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 the useEffect was 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 on popstate or 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.

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

@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:

 <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 useEffect block 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/SocialShareButton first, pinning Chainvoice to that new version once released, and only then stripping the useEffect from Navbar.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.

@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?

🧩 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 useEffect glue (polling, init/destroy, updateOptions) just to use the library.

Proposed change: an opt-in auto-init routine keyed off a data-social-share attribute, with automatic popstate/hashchange-based URL/title updates, and MutationObserver-based auto-cleanup when the container is removed from the DOM.

Affected areas: src/social-share-button.js and 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.

-Original file line number
+Diff line change
@@ Expand Up / @@ -22,6 +22,10 @@ @@
       <link rel="preconnect" href="https://fonts.googleapis.com">
       <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
       <link href="https://fonts.googleapis.com/css2?family=Inter:wght@400;500;600;700&family=Montserrat:wght@600;700&display=swap" rel="stylesheet">
+      <link
+        rel="stylesheet"
+        href="https://cdn.jsdelivr.net/gh/AOSSIE-Org/[email protected]/src/social-share-button.css"
+      />
       <script type="text/javascript">
         (function (l) {
           if (l.search[1] === '/') {
@@ Expand All / @@ -38,5 +42,6 @@ @@
     <body>
       <div id="root"></div>
       <script type="module" src="/src/main.jsx"></script>
+      <script src="https://cdn.jsdelivr.net/gh/AOSSIE-Org/[email protected]/src/social-share-button.js"></script>
     </body>
     </html>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

feat: integrate AOSSIE-Org social share button in navbar #182

Uh oh!

Diff view

Diff view

There are no files selected for viewing

Uh oh!

Uh oh!

Uh oh!

kpj2006 Jul 3, 2026

Uh oh!

coderabbitai Bot Jul 3, 2026

Uh oh!

kpj2006 Jul 3, 2026

Uh oh!

coderabbitai Bot Jul 3, 2026

Uh oh!

amankv1234 Jul 4, 2026 •

edited

Loading

Uh oh!

coderabbitai Bot Jul 4, 2026

Uh oh!

kpj2006 Jul 4, 2026

Uh oh!

coderabbitai Bot Jul 4, 2026

Uh oh!

kpj2006 Jul 8, 2026

Uh oh!

coderabbitai Bot Jul 8, 2026

Uh oh!

Uh oh!

-Original file line number
+Diff line change
@@ -1,6 +1,6 @@
     import { ConnectButton } from "@rainbow-me/rainbowkit";
     import NetworkSwitcher from "./NetworkSwitcher";
-    import { useEffect, useState } from "react";
+    import { useEffect, useState, useRef } from "react";
     import { Link, useNavigate, useLocation } from "react-router-dom";
     import { useAccount } from "wagmi";
     import AccountBalanceWalletIcon from "@mui/icons-material/AccountBalanceWallet";
@@ Expand All / @@ -18,6 +18,8 @@ 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) => {
@@ Expand All / @@ -42,6 +44,44 @@ 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]);
       const handleScroll = (sectionId) => {
         if (location.pathname !== "/") {
@@ Expand Down Expand Up / @@ -224,6 +264,15 @@ function Navbar() { @@
                   </motion.div>
                 ))}
+                {/* ADD THIS: Social share button container left of About */}
+                <motion.div
+                  whileHover={{ scale: 1.05 }}
+                  whileTap={{ scale: 0.95 }}
+                  className="mr-2"
+                >
+                  <div id="share-button"></div>
+                </motion.div>
                 <motion.div
                   whileHover={{ scale: 1.05 }}
                   whileTap={{ scale: 0.95 }}
@@ Expand Down @@

Uh oh!

Uh oh!

feat: integrate AOSSIE-Org social share button in navbar #182

Uh oh!

feat: integrate AOSSIE-Org social share button in navbar #182

Uh oh!

Uh oh!

Diff view

Diff view

There are no files selected for viewing

Uh oh!

Uh oh!

Uh oh!

kpj2006 Jul 3, 2026

Choose a reason for hiding this comment

Uh oh!

coderabbitai Bot Jul 3, 2026

Choose a reason for hiding this comment

Uh oh!

kpj2006 Jul 3, 2026

Choose a reason for hiding this comment

Uh oh!

coderabbitai Bot Jul 3, 2026

Choose a reason for hiding this comment

Uh oh!

amankv1234 Jul 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

coderabbitai Bot Jul 4, 2026

Choose a reason for hiding this comment

Uh oh!

kpj2006 Jul 4, 2026

Choose a reason for hiding this comment

Uh oh!

coderabbitai Bot Jul 4, 2026

Choose a reason for hiding this comment

1. Changes needed in AOSSIE-Org/SocialShareButton

2. Minimal code needed in Chainvoice (frontend/src/components/Navbar.jsx / frontend/index.html)

Until the library ships that

Uh oh!

kpj2006 Jul 8, 2026

Choose a reason for hiding this comment

Uh oh!

coderabbitai Bot Jul 8, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

amankv1234 Jul 4, 2026 •

edited

Loading

1. Changes needed in `AOSSIE-Org/SocialShareButton`

2. Minimal code needed in Chainvoice (`frontend/src/components/Navbar.jsx` / `frontend/index.html`)