0. 為什麼接 LikeCoin|讓閱讀的最後一步,不只剩下離開頁面

Fishpond 現在已經能把影片、podcast 與外部素材整理成可搜尋、可累積的編輯導讀,但文章發布後,讀者與內容的互動仍然停在閱讀。看完一篇文章,讀者可以把連結貼到群組,卻沒有一個站內動作能直接表達「這篇值得繼續做」。

LikeCoin 提供的切入點很簡單:在文章最後放一個 LikeCoin Button,讓讀者用拍手支持創作者。這不是要把魚塘改造成交易網站,也不是把閱讀綁上錢包登入;它只是替每篇文章增加一個低摩擦的支持出口。

對 Fishpond 而言,這個整合有三個目的:

  1. 讓讀者在讀完文章的當下,可以直接提供正向回饋。
  2. 讓公開、免費的導讀內容,多一條廣告以外的支持管道。
  3. 觀察哪些文章真正讓讀者願意採取行動,作為後續選題參考。

最小可行版本只需要一個全站共用元件與一組 Liker ID 設定。文章內容不需要逐篇修改,也不需要讓 Fishpond 接觸讀者的私鑰或錢包資料。

圖 01:從魚塘導讀、讀完文章、拍手支持到創作者回饋

Fishpond 的文章頁目前由 EditorialLayout 與 SimpleLayout 負責組裝。以 editorial 版型為例,頁面依序包含文章 Hero、KPI、目錄與正文,最後才離開文章區域進入全站 Footer。

LikeCoin 支持區塊最適合放在正文結束後、文章容器結束前。這個位置有幾個好處:

  • 讀者已經看完內容,支持邀請不會打斷閱讀。
  • 元件仍然屬於特定文章,可以取得文章 slug 與 canonical URL。
  • 它不會和全站 Footer 混在一起,讀者知道自己支持的是剛讀完的內容。
  • 由 layout 統一渲染,新文章上站時會自動取得支持區塊。

不建議把按鈕寫進每篇 index.md。那會讓內容層綁定第三方服務,未來更換 Liker ID、按鈕網址、文案或停用整合時,必須批次修改所有文章。Fishpond 的 Content-as-Data 原則應該維持清楚:Markdown 負責文章,React layout 負責共用互動介面。

圖 02:LikeCoin 支持卡應位於正文後、Footer 前,並由共用 Layout 統一渲染

2. 資料流怎麼走|文章提供網址,LikeCoin 處理拍手

官方文件提供 iframe 與可點擊 widget 兩種 LikeCoin Button 嵌入方式。Fishpond 可以先採用較簡單的 widget 連結:

https://button.like.co/in/like/{LIKER_ID}?referrer={ARTICLE_URL}

這條資料流只有幾步:

  1. Fishpond 從文章 slug 組出正式 canonical URL。
  2. LikeCoinSupport 元件將 Liker ID 與文章 URL 組成 widget 連結。
  3. 讀者點擊「為這篇導讀拍手」。
  4. 瀏覽器開啟 LikeCoin 頁面,由 LikeCoin 處理登入與拍手。
  5. Fishpond 本身不接觸錢包、簽名、代幣或付款資料。

referrer 很重要。它讓 LikeCoin 知道這次支持對應哪一篇文章,而不是只知道支持整個網站。對魚塘來說,文章 URL 就是最穩定的內容識別;它已經由 slug 決定,也和正式站路由一致。

第一版採用外開 widget,比直接嵌 iframe 更保守。它不需要處理第三方 frame 的高度、行動版呈現與 Content Security Policy,也比較容易在 LikeCoin 服務異常時退化成普通連結。等互動與需求被驗證,再評估是否改成頁內 iframe。

圖 03:從文章 slug、正式網址、referrer 到 LikeCoin Widget 的五步資料流

3. 怎麼實作|一個元件、一個設定、兩個版型接點

實作可以拆成三層。

第一層是環境設定。Liker ID 不應硬寫在文章中,而應由 Vite 的公開環境變數提供,例如:

VITE_LIKECOIN_LIKER_ID=fishpond

這不是秘密金鑰,可以送到瀏覽器;但用設定管理仍有價值,因為 staging、正式站或不同團隊帳號可以各自切換。若環境變數未設定,元件直接不渲染,build 不應因此失敗。

第二層是共用元件。元件只負責組 URL、顯示說明與提供外部連結:

type LikeCoinSupportProps = {
  slug: string
}

export function LikeCoinSupport({ slug }: LikeCoinSupportProps) {
  const likerId = import.meta.env.VITE_LIKECOIN_LIKER_ID
  if (!likerId) return null

  const articleUrl =
    `https://fishpond.fishinwaters-cjp.workers.dev/articles/${slug}`
  const supportUrl =
    `https://button.like.co/in/like/${encodeURIComponent(likerId)}` +
    `?referrer=${encodeURIComponent(articleUrl)}`

  return (
    <aside aria-label="支持這篇導讀">
      <p>覺得這篇值得?用 LikeCoin 拍手支持魚塘繼續整理好內容。</p>
      <a href={supportUrl} target="_blank" rel="noopener noreferrer">
        為這篇導讀拍手
      </a>
    </aside>
  )
}

第三層是版型接入。在 EditorialLayout 與 SimpleLayout 的正文後加入同一個元件,並傳入 entry.slug。這樣現有文章與未來文章都會自動套用,不必讓 media-to-editorial pipeline 多寫任何特殊 Markdown。

元件視覺應沿用 Fishpond 的 paper-blueprint 語言:米白底、深海軍藍框線、銅橘色主按鈕、簡短說明。它是文章尾聲的一張支持卡,不該像橫幅廣告,也不應使用會遮住內容的浮動按鈕。

4. 安全與維運邊界|Fishpond 只負責導流,不碰資產

這個整合最重要的工程判斷,是維持清楚的信任邊界。

Fishpond 可以做的事:

  • 根據 slug 產生文章 canonical URL。
  • 把 Liker ID 與文章 URL 組成 LikeCoin 連結。
  • 以外部連結把讀者帶到 LikeCoin。
  • 在站內記錄支持按鈕的點擊事件,但不記錄錢包身分。

Fishpond 不應做的事:

  • 要求讀者把助記詞或私鑰輸入魚塘。
  • 代理簽署任何鏈上交易。
  • 在自己的前端偽裝成 LikeCoin 登入頁。
  • 宣稱按一次按鈕必然產生固定金額收益。
  • 把 2021 年的免費拍手或訂閱規則寫成今天仍固定不變。

LikeCoin 的產品與獎勵制度曾經演變。早期「讚賞公民」使用月費模式,後來轉向 Web3 質押與獎勵分配;官方文件也區分不同版本。因此魚塘的介面文案應保持中性,只說「透過 LikeCoin 拍手支持」,不要把特定金額、次數或收益寫死在元件裡。

外部服務也可能暫時不可用。第一版使用普通 <a> 連結的好處,是 LikeCoin 失效時不會拖垮文章渲染。元件本身不發 API request,Fishpond build 與頁面載入都不依賴 LikeCoin 回應。

圖 04:魚塘的安全邊界與 LikeCoin 整合三階段上線路線

5. 上線順序|先接最小版本,再決定要不要深化

建議分三個階段上線。

第一階段是最小整合:

  • 建立 LikeCoinSupport 共用元件。
  • 設定正式站 Liker ID。
  • 接到 editorial 與 simple 兩種文章版型。
  • 加入元件測試,確認未設定 Liker ID 時不顯示。
  • 驗證產生的 URL 正確包含 slug 與 referrer。

第二階段觀察使用:

  • 記錄按鈕點擊率,不追蹤錢包或個人資產。
  • 比較不同主題、篇幅與文章位置的互動差異。
  • 確認行動版文案與按鈕不影響閱讀。
  • 檢查 LikeCoin 端是否能正確辨識各篇文章。

第三階段才評估深化:

  • 是否改用 iframe,讓拍手留在文章頁內完成。
  • 是否為每位作者提供不同 Liker ID。
  • 是否在後台顯示文章支持數據。
  • 是否把支持訊號納入魚塘選題與內容維護優先級。

對 Fishpond 而言,LikeCoin 最合理的角色不是新的內容來源,也不是另一套會員系統,而是閱讀完成後的支持出口。只要把元件放在正確層級、守住資產安全邊界,這項整合就能維持很小的技術成本,同時讓每一篇公開導讀多一種被讀者回應的方式。

延伸閱讀:不用看廣告,拍拍拍拍拍手就能支持作者。