add Read more / Show less to Amsterdam agenda

src/app/day/2026/amsterdam/schedule-data.ts

@@ -55,7 +55,7 @@ export const amsterdamSessions: AmsterdamSession[] = [
     end: "2026-06-10T09:55:00+02:00",
     tags: ["GraphQL", "REST"],
     description:
-      '<p>Living in the GraphQL bubble for the last few years, I\'ve watched the ecosystem grow up in a way that\'s hard to appreciate from the outside. The spec, the tooling, the vendors, the federation story, all visibly stronger than just two years ago. GraphQL was never bad, It was misunderstood, overhyped and overused. Fast forward to today, the dust has settled. Enterprises are on the slope of enlightenment, yet the people who pick the query language still have to handle pushback: ""GraphQL breaks caching!,"" ""it has the N+1 problem,"" ""OpenAPI is much simpler."" Almost all of that pushback is grounded in views that were already outdated when first written down. So I traced 18 of the most repeated GraphQL vs REST claims back to their primary sources: papers, RFCs, doc pages, security reports. Only three survived cleanly. This talk sends you home able to articulate GraphQL\'s real strengths, and its honest trade-offs, with receipts. We\'ll close on where GraphQL\'s value is growing fastest: as an abstraction layer for LLMs and agents, where a single typed graph is a far simpler surface to integrate against than hundreds of REST API endpoints.</p>\n',
+      '<p>Living in the GraphQL bubble for the last few years, I\'ve watched the ecosystem grow up in a way that\'s hard to appreciate from the outside. The spec, the tooling, the vendors, the federation story, all visibly stronger than just two years ago. GraphQL was never bad, It was misunderstood, overhyped and overused. Fast forward to today, the dust has settled. Enterprises are on the slope of enlightenment, yet the people who pick the query language still have to handle pushback: ""GraphQL breaks caching!,"" ""it has the N+1 problem,"" ""OpenAPI is much simpler."" Almost all of that pushback is grounded in views that were already outdated when first written down.</p>\n<p>I traced 18 of the most repeated GraphQL vs REST claims back to their primary sources: papers, RFCs, doc pages, security reports. Only three survived cleanly. This talk sends you home able to articulate GraphQL\'s real strengths, and its honest trade-offs, with receipts. We\'ll close on where GraphQL\'s value is growing fastest: as an abstraction layer for LLMs and agents, where a single typed graph is a far simpler surface to integrate against than hundreds of REST API endpoints.</p>\n',
     venue: "TBA",
     speakers: [
       {
@@ -107,7 +107,7 @@ export const amsterdamSessions: AmsterdamSession[] = [
     end: "2026-06-10T10:20:00+02:00",
     tags: ["GraphQL", "MCP", "AI Agents"],
     description:
-      "<p>As AI assistants and MCP-style tools increasingly sit in front of GraphQL APIs, embeddings have become critical for fuzzy schema search, field retrieval, and natural-language-to-query systems. Yet most teams rely on general-purpose embedding models that were not specifically designed to understand GraphQL type systems, relationships, or naming patterns. This talk shares practical experience building schema-aware embedding pipelines with off-the-shelf and fine-tuned models while exploring how far preprocessing, chunking, and schema structuring can take you before custom training is needed. We’ll discuss evaluation methods, common failure modes like field confusion and hallucinated types, and the tradeoffs between large hosted models and compact, GraphQL-focused embeddings that can run with lightweight CPU inference. The goal is to give GraphQL platform teams concrete, production-ready guidelines for choosing, adapting, and shipping embeddings that actually understand their schemas.</p>\n",
+      "<p>As AI assistants and MCP-style tools increasingly sit in front of GraphQL APIs, embeddings have become critical for fuzzy schema search, field retrieval, and natural-language-to-query systems. Yet most teams rely on general-purpose embedding models that were not specifically designed to understand GraphQL type systems, relationships, or naming patterns.</p>\n<p>This talk shares practical experience building schema-aware embedding pipelines with off-the-shelf and fine-tuned models while exploring how far preprocessing, chunking, and schema structuring can take you before custom training is needed. We’ll discuss evaluation methods, common failure modes like field confusion and hallucinated types, and the tradeoffs between large hosted models and compact, GraphQL-focused embeddings that can run with lightweight CPU inference. The goal is to give GraphQL platform teams concrete, production-ready guidelines for choosing, adapting, and shipping embeddings that actually understand their schemas.</p>\n",
     venue: "TBA",
     speakers: [
       {

src/app/day/2026/amsterdam/schedule-section.tsx

@@ -1,3 +1,6 @@
+"use client"
+
+import { useState } from "react"
 import Image from "next/image"
 import clsx from "clsx"
 
@@ -10,6 +13,7 @@ import {
   SocialIconType,
 } from "@/app/conf/_design-system/social-icon"
 import { formatDescription } from "@/app/conf/2026/schedule/[id]/format-description"
+import ArrowDownIcon from "@/app/conf/_design-system/pixelarticons/arrow-down.svg?svgr"
 
 import {
   AmsterdamSession,
@@ -81,7 +85,7 @@ function SessionBlock({
       <SessionHeader session={session} className="px-2 py-8 sm:px-3 lg:py-12" />
       {session.description && (
         <>
-          <Hr className="mt-10 xl:mt-0 2xl:mt-16" />
+          <Hr className="mt-0 lg:mt-10 xl:mt-0 2xl:mt-16" />
           <SessionDescription
             description={session.description}
             sideSpeaker={sideSpeaker}
@@ -108,24 +112,46 @@ function SessionDescription({
   description: string
   sideSpeaker: AmsterdamSpeaker | null
 }) {
+  const [expanded, setExpanded] = useState(false)
   const paragraphs = parseParagraphs(description)
-  const splitAt =
-    sideSpeaker && paragraphs.length >= 2
-      ? paragraphs.length - 2
-      : paragraphs.length
-  const lead = paragraphs.slice(0, splitAt)
-  const tail = paragraphs.slice(splitAt)
+  const hasMore = paragraphs.length > 1
+  const visible = expanded ? paragraphs : paragraphs.slice(0, 1)
+  const splitAt = sideSpeaker ? Math.max(0, visible.length - 2) : visible.length
+  const lead = visible.slice(0, splitAt)
+  const tail = visible.slice(splitAt)
+  const lastInLead = tail.length === 0 ? lead.length - 1 : -1
+  const lastInTail = tail.length - 1
+
+  const toggle = hasMore && (
+    <>
+      {" "}
+      <button
+        type="button"
+        onClick={() => setExpanded(e => !e)}
+        aria-expanded={expanded}
+        className="typography-link"
+      >
+        {expanded ? "Show less." : "Read more…"}
+      </button>
+    </>
+  )
 
   return (
     <div className="typography-body-lg mt-8 px-2 pb-8 sm:px-3 lg:mt-12 xl:pb-12 [&>p+p]:mt-4 [&_a]:break-words">
       {lead.map((html, i) => (
-        <p key={`lead-${i}`} dangerouslySetInnerHTML={{ __html: html }} />
+        <p key={`lead-${i}`}>
+          <span dangerouslySetInnerHTML={{ __html: html }} />
+          {i === lastInLead && toggle}
+        </p>
       ))}
       {tail.length > 0 && (
-        <div className="mt-4 xl:flex xl:items-end xl:gap-6">
+        <div className="mt-4 first:mt-0 xl:flex xl:items-end xl:gap-6">
           <div className="xl:flex-1 [&>p+p]:mt-4">
             {tail.map((html, i) => (
-              <p key={`tail-${i}`} dangerouslySetInnerHTML={{ __html: html }} />
+              <p key={`tail-${i}`}>
+                <span dangerouslySetInnerHTML={{ __html: html }} />
+                {i === lastInTail && toggle}
+              </p>
             ))}
           </div>
           {sideSpeaker && (