broadcast — คอมเมนต์เด้งขึ้นทุกแท็บ และ Turbo เหมาะกับงานแบบไหน

ปัญหา: แท็บอื่นไม่รู้ว่ามีคอมเมนต์ใหม่

ลองนึกภาพ: คุณเปิดบทความ "ราดหน้าหมูหมัก" ไว้สองแท็บ · ส่งคอมเมนต์จากแท็บซ้าย แท็บซ้ายเปลี่ยนทันที (บท 132) · แต่แท็บขวานิ่งสนิท ต้องกด refresh เองถึงจะเห็น

เหตุผลอยู่ที่วิธีคุยของเว็บปกติ (HTTP): เบราว์เซอร์ต้องถามก่อน server ถึงจะตอบ · ถามหนึ่งครั้งได้คำตอบหนึ่งครั้ง แล้วจบ · server ไม่มีทางวิ่งไปบอกแท็บขวาเองได้ เพราะแท็บขวาไม่ได้ถามอะไรอยู่

สิ่งที่เราอยากได้เรียกว่า real-time — ข้อมูลใหม่วิ่งมาหาเราเองทันทีที่เกิด โดยเราไม่ต้องกดอะไร · ทางแก้คือให้เบราว์เซอร์ต่อสายค้างไว้กับ server ตั้งแต่เปิดหน้า · สายแบบนี้ชื่อ WebSocket · ต่อครั้งเดียวแล้วคุยได้สองทาง ใครมีเรื่องก็พูดได้เลย ไม่ต้องรออีกฝั่งถาม

เทียบกับฝั่ง React ที่เพิ่งเรียน: ใน บท 74 การ "เปิด WebSocket" คือตัวอย่างงานที่ต้องเขียนใน useEffect เอง พร้อม cleanup ตอนปิด · ใน Rails บทนี้เราไม่เขียน JavaScript สักบรรทัด — Turbo เปิดและปิดสายให้เอง

สองชิ้นที่ต้องมี — คนประกาศ กับ โต๊ะที่เปิดลำโพง

real-time ใน Rails ต้องมีสองฝั่งเสมอ: ฝั่งที่ประกาศ (เกิดคอมเมนต์ใหม่ → ส่งข่าว) กับฝั่งที่ฟัง (หน้าเว็บที่รอรับข่าว) · ขาดฝั่งไหนก็ไม่ทำงาน · เราจะใส่ทีละฝั่ง แล้วดูผลจริงแต่ละขั้น

ชิ้นที่ 1 — คนประกาศ: broadcasts_to :post ใน model

เปิดไฟล์ app/models/comment.rb แล้วเพิ่ม 2 บรรทัดใต้ belongs_to :post พร้อมบรรทัดว่างคั่นก่อน validates ให้หน้าตาเป็นแบบนี้ (บรรทัดคอมเมนต์ # พิมพ์ตามไว้ด้วย ไฟล์จะได้ตรงกับบทเรียน):

class Comment < ApplicationRecord
  belongs_to :post

  # คอมเมนต์ใหม่เด้งขึ้นทุกแท็บที่เปิดหน้าโพสต์นี้ (ส่งต่อให้ job · หลัง commit)
  broadcasts_to :post

  validates :author_name, presence: true, length: { maximum: 50 }
  validates :body, presence: true, length: { maximum: 1000 }
end

• broadcasts_to — แปลว่า "ทุกครั้งที่คอมเมนต์ถูกสร้าง · แก้ · ลบ ให้ประกาศข่าว" · broadcast = ประกาศถึงทุกคนที่ฟังอยู่
• :post — "ประกาศในช่องของบทความที่คอมเมนต์นี้อยู่" · Rails เรียก comment.post แล้วใช้บทความนั้นเป็นชื่อช่อง · คอมเมนต์ของบทความ 23 จึงประกาศในช่องของบทความ 23 เท่านั้น คนเปิดบทความ 24 ไม่ได้ยิน
• ข่าวที่ประกาศตอนสร้างคือใบสั่ง Turbo Stream แบบเดียวกับบท 132: "append คอมเมนต์นี้ ต่อท้ายกล่อง comments" · Rails เดาให้หมด: ใช้ partial comments/_comment (ชื่อตาม model) และ target comments (ชื่อ model แบบพหูพจน์)
• บรรทัดคอมเมนต์ (ส่งต่อให้ job · หลัง commit) — job คืองานที่ฝากไว้ให้ทำทีหลัง (ละเอียดใน Day 3 Part 2 ซึ่งยังไม่มา) · commit คือจังหวะ COMMIT ที่ตู้เซ็นรับแฟ้ม (บท 111) · ทั้งสองอย่างจะเห็นด้วยตาในหัวข้อ "อ่าน log" ข้างล่าง

ไม่ต้อง restart server — แก้ไฟล์ใน app/ ตอน development Rails โหลดใหม่ให้เอง

before A {"marker":"A","count":"0","n":0,"ids":[],"source":false,"connected":null}
before B {"marker":"B","count":"0","n":0,"ids":[],"source":false,"connected":null}
after  A {"marker":"A","count":"1","n":1,"ids":["comment_1"],"source":false,"connected":null}
after  B {"marker":"B","count":"0","n":0,"ids":[],"source":false,"connected":null}

Started POST "/posts/30/comments" for ::1 at …
…
[ActiveJob] [Turbo::Streams::ActionBroadcastJob] […] [ActionCable] Broadcasting to Z2lkOi8vd29uZ25vay1ibG9nLWFsbC1pbi1vbmUvUG9zdC8zMA: "<turbo-stream action=\"append\" target=\"comments\"…

ชิ้นที่ 2 — เปิดลำโพง: turbo_stream_from @post ในหน้า show

เปิด app/views/posts/show.html.erb · หา <section class="mt-10 space-y-4"> (ส่วนความคิดเห็นจากบท 132) แล้วเพิ่ม 2 บรรทัดนี้ (บรรทัดที่สองคือบรรทัดว่าง) เป็นบรรทัดแรกในนั้น:

  <section class="mt-10 space-y-4">
    <%= turbo_stream_from @post %>

    <h2 class="text-xl font-bold">
      ความคิดเห็น (<span id="comment_count"><%= @post.comments.count %></span>)
    </h2>

• turbo_stream_from @post — "หน้านี้ขอฟังช่องของบทความนี้" · ต้องเป็นของชิ้นเดียวกับที่ model ประกาศ (:post ↔ @post) ไม่งั้นต่างคนต่างอยู่คนละช่อง
• ใช้ <%= %> (มีเครื่องหมาย =) เพราะมันต้องวางแท็กลงบนจาน — ลืม = แล้วไม่มีลำโพง (บท 122)
• วางไว้ตรงไหนในหน้าก็ได้ · ที่วางใน <section> เพราะอยู่ใกล้ส่วนที่มันจะเปลี่ยน อ่านแล้วเข้าใจ · แท็กนี้ไม่มีหน้าตาให้เห็นบนจอ

ดูว่าเบราว์เซอร์ได้อะไรจริง (บทความเลข 23 ของเรา · ของคุณใช้เลขไหนก็ได้):

$ curl -s localhost:3000/posts/23 | grep -B1 -A4 turbo-cable-stream-source

  <section class="mt-10 space-y-4">
    <turbo-cable-stream-source channel="Turbo::StreamsChannel" signed-stream-name="IloybGtPaTh2ZDI5dVoyNXZheTFpYkc5bkxXRnNiQzFwYmkxdmJtVXZVRzl6ZEM4eU13Ig==--5bd6c5ff5bee9fefc0a058276b908435619e744c593415866dc65f0536ff2a9c"></turbo-cable-stream-source>

    <h2 class="text-xl font-bold">
      ความคิดเห็น (<span id="comment_count">1</span>)
    </h2>

• ตัวนับเป็น 1 เพราะบทความ 23 ของเรามีคอมเมนต์จากการทดลองอยู่แล้ว 1 อัน · บรรทัด <%= turbo_stream_from @post %> กลายเป็นแท็กยาว ๆ บรรทัดที่สอง
• <turbo-cable-stream-source> — นี่แหละลำโพง · เป็นแท็กพิเศษของ Turbo พอเบราว์เซอร์เจอแท็กนี้ JavaScript ของ Turbo จะต่อ WebSocket ไปที่ /cable ให้เอง
• channel="Turbo::StreamsChannel" — ใช้ "สายประเภท Turbo Stream" ของ Action Cable
• signed-stream-name="…--5bd6…" — ชื่อช่องแบบมีลายเซ็น · ข้างในคือ "บทความเลข 23 ของแอปนี้" (gid://wongnok-blog-all-in-one/Post/23) ที่ถูกแปลงเป็นตัวอักษรชุดหนึ่ง (ไม่ใช่ความลับ ใครก็ถอดกลับได้ — ส่วนที่ขึ้นต้น Z2lk ใน log ก็คือชื่อนี้) · ส่วนหลัง -- คือลายเซ็นจาก server — ใครแอบแก้ชื่อในเบราว์เซอร์ให้ไปฟังช่องอื่น ลายเซ็นจะไม่ตรง server ไม่ยอม · ลายเซ็นของคุณจะต่างจากในบทแน่นอน เพราะแต่ละเครื่องมีกุญแจลับสำหรับเซ็นของตัวเอง
• เปิด Chrome DevTools แท็บ Elements จะเห็นแท็กนี้มีคำว่า connected ต่อท้ายเพิ่มมา = ต่อสายติดแล้ว (เราตรวจด้วยสคริปต์ว่า attribute นี้มีจริงหลังโหลดหน้า)

ส่งคอมเมนต์จากแท็บซ้ายอีกครั้ง (บทความเลข 29) — ผลจริง:

before A {"marker":"A","count":"0","n":0,"ids":[],"source":true,"connected":true}
before B {"marker":"B","count":"0","n":0,"ids":[],"source":true,"connected":true}
after  A {"marker":"A","count":"1","n":1,"ids":["comment_2"],"source":true,"connected":true}
after  B {"marker":"B","count":"0","n":1,"ids":["comment_2"],"source":true,"connected":true}

แท็บขวา (after B) ได้คอมเมนต์ comment_2 โดยไม่ต้องกดอะไร และ marker ยังเป็น "B" = มาโดยไม่โหลดหน้าใหม่ 🎉 · แต่สังเกต "count":"0" — หัวข้อยังเขียนว่า "ความคิดเห็น (0)" ทั้งที่มีคอมเมนต์ 1 อัน · เพราะ broadcasts_to ประกาศแค่ "append คอมเมนต์" ไม่ได้ประกาศเรื่องตัวนับ · ต้องเพิ่มเอง (หัวข้อถัดไป)

ให้ตัวนับในแท็บอื่นขยับด้วย — บรรทัดที่สาม

กลับไปที่ app/models/comment.rb เพิ่มอีก 2 บรรทัดต่อจาก broadcasts_to :post (ก่อนบรรทัดว่าง) · ไฟล์ทั้งไฟล์จะเป็นแบบนี้ (ตรงกับโค้ดของบทเรียนทุกบรรทัด):

class Comment < ApplicationRecord
  belongs_to :post

  # คอมเมนต์ใหม่เด้งขึ้นทุกแท็บที่เปิดหน้าโพสต์นี้ (ส่งต่อให้ job · หลัง commit)
  broadcasts_to :post
  # ตัวนับในแท็บอื่นต้องเปลี่ยนตามด้วย
  after_create_commit -> { broadcast_update_later_to post, target: "comment_count", html: post.comments.count }

  validates :author_name, presence: true, length: { maximum: 50 }
  validates :body, presence: true, length: { maximum: 1000 }
end

แกะบรรทัดยาวทีละท่อน:

• after_create_commit — callback (บท 112) "หลังตู้เซ็นรับคอมเมนต์ใหม่แล้ว" · เฉพาะตอนสร้าง ไม่รวมแก้/ลบ
• -> { … } — ก้อนโค้ดที่เก็บไว้รันทีหลัง (Ruby เรียกว่า lambda) · คล้าย block { |x| … } ที่ใช้กับ each แต่ตั้งไว้ก่อน รอ Rails เรียกตอนถึงจังหวะ
• broadcast_update_later_to post — "ประกาศในช่องของบทความนี้ ให้เปลี่ยนเนื้อใน (update) ของ…" · คำว่า later = ฝากเป็นงานไว้ให้ทำต่อ ไม่ทำตรงนี้ (เดี๋ยวเห็นใน log)
• post (ไม่มี @) — โค้ดนี้อยู่ใน model ของคอมเมนต์ · post เฉย ๆ จึงแปลว่า "บทความของคอมเมนต์ตัวนี้" (เหมือนเขียน comment.post ใน console) ได้มาจาก belongs_to :post · @post เป็นของ controller/view ใช้ใน model ไม่ได้
• target: "comment_count" — ของที่จะเปลี่ยนคือ <span id="comment_count"> ที่มีอยู่แล้วตั้งแต่บท 132
• html: post.comments.count — เนื้อใหม่ = นับคอมเมนต์ของบทความนี้ใหม่จากฐานข้อมูล

ทดลองรอบที่สาม (บทความเลข 28) — ผลจริง:

after  A {"marker":"A","count":"1","n":1,"ids":["comment_3"],"source":true,"connected":true}
after  B {"marker":"B","count":"1","n":1,"ids":["comment_3"],"source":true,"connected":true}

แท็บขวา "count":"1" แล้ว — ตัวนับขยับตาม

ไม่ต้องรัน tailwindcss:build ใหม่ (ไม่มีคลาส CSS ใหม่) และไม่มี gem หรือ migration ใหม่

แท็บที่กดส่งเอง ได้ใบสั่งสองใบ — ทำไมคอมเมนต์ไม่ซ้ำ

มีเรื่องแปลกที่ต้องสังเกต: แท็บซ้ายก็เปิดลำโพงอยู่เหมือนกัน · ตอนกดส่ง มันจึงได้ใบสั่ง "append คอมเมนต์" สองใบ — ใบแรกจากคำตอบของฟอร์ม (create.turbo_stream.erb บท 132) ใบที่สองจากเสียงตามสาย

after  A {"marker":"A","count":"1","n":1,"ids":["comment_3"],"source":true,"connected":true}
A appended ids: ["comment_3","comment_3"]

after  A {"marker":"A","count":"1","n":2,"ids":["",""],"source":true,"connected":true}
after  B {"marker":"B","count":"1","n":1,"ids":[""],"source":true,"connected":true}

อ่าน log ของ server — ข่าววิ่งไปถึงใครบ้าง

ภาพรวมของสิ่งที่เกิดขึ้นตอนกดส่งหนึ่งครั้ง:

log จริงของการกดส่งหนึ่งครั้ง (มีสองแท็บเปิดบทความ 23 อยู่ · ส่วนที่ตัดออกแทนด้วย …: บรรทัดที่ไม่เกี่ยว · บรรทัด ↳ · ท้ายบรรทัดที่ยาวเกิน · ชื่อช่องย่อเหลือ Z2lk…UG9zdC8yMw):

Started POST "/posts/23/comments" for ::1 at 2026-11-07 11:01:29 +0700
Processing by CommentsController#create as TURBO_STREAM
  …
  TRANSACTION (1.1ms)  BEGIN
  Comment Create (3.0ms)  INSERT INTO "comments" (…) VALUES ('สวัสดีจากแท็บซ้าย', 'ต้นกล้า', 23, …) RETURNING "id"
  TRANSACTION (1.2ms)  COMMIT
[ActiveJob] Enqueued Turbo::Streams::ActionBroadcastJob (Job ID: 1e8b4d1c-…) to Async(default) with arguments: "Z2lk…UG9zdC8yMw", {action: :append, target: "comments", …
  Comment Count (1.1ms)  SELECT COUNT(*) FROM "comments" WHERE "comments"."post_id" = 23
[ActiveJob] Enqueued Turbo::Streams::ActionBroadcastJob (Job ID: 09095142-…) to Async(default) with arguments: "Z2lk…UG9zdC8yMw", {action: :update, target: "comment_count", …
…
[ActiveJob] [Turbo::Streams::ActionBroadcastJob] [1e8b4d1c-…]   Rendered comments/_comment.html.erb (Duration: 0.3ms | GC: 0.0ms)
[ActiveJob] [Turbo::Streams::ActionBroadcastJob] [1e8b4d1c-…] [ActionCable] Broadcasting to Z2lk…UG9zdC8yMw: "<turbo-stream action=\"append\" target=\"comments\">…
…
Turbo::StreamsChannel transmitting "<turbo-stream action=\"append\" target=\"comments\"><template>…<article id=\"comment_8\" …
Turbo::StreamsChannel transmitting "<turbo-stream action=\"append\" target=\"comments\"><template>…<article id=\"comment_8\" …
  Rendering comments/create.turbo_stream.erb
  …
Completed 200 OK in 37ms (Views: 7.1ms | ActiveRecord: 5.9ms (4 queries, 1 cached) | GC: 0.0ms)
…
[ActiveJob] [Turbo::Streams::ActionBroadcastJob] [09095142-…] [ActionCable] Broadcasting to Z2lk…UG9zdC8yMw: "<turbo-stream action=\"update\" target=\"comment_count\"><template>1</template></turbo-stream>"
…
Turbo::StreamsChannel transmitting "<turbo-stream action=\"update\" target=\"comment_count\"><template>1</template></turbo-stream>" (via streamed from Z2lk…UG9zdC8yMw)
Turbo::StreamsChannel transmitting "<turbo-stream action=\"update\" target=\"comment_count\"><template>1</template></turbo-stream>" (via streamed from Z2lk…UG9zdC8yMw)

อ่านทีละกลุ่ม:

• Enqueued … ActionBroadcastJob อยู่หลัง COMMIT — Enqueued = "ฝากงาน (job) ประกาศไว้ในคิว" · เกิดหลังตู้เซ็นรับแล้วเท่านั้น (เพราะเป็น after_*_commit) · มี 2 บรรทัด = งานรายการคอมเมนต์ (append) กับงานตัวนับ (update)
• Async(default) — ในเครื่องเรา job ทำใน server ตัวเดิมเลย ไม่ต้องเปิดโปรแกรมอื่น · บรรทัดที่ขึ้นต้น [ActiveJob] [Turbo::Streams::ActionBroadcastJob] คือตัว job กำลังทำงาน
• Rendered comments/_comment.html.erb — job ทำ HTML ของคอมเมนต์จาก partial ตัวเดียวกับที่หน้า show ใช้ → หน้าตาตรงกันทุกที่
• Broadcasting to Z2lk… = ครัวประกาศ 1 ครั้ง ในช่องของบทความ 23 (ต่องาน — งานตัวนับก็มีบรรทัดนี้ของตัวเองด้านล่าง)
• transmitting 2 บรรทัด = ส่งถึงลำโพง 2 ตัว (แท็บ A และ B) · ยิ่งเปิดหลายแท็บ บรรทัดนี้ยิ่งมากตาม
• ลำดับบรรทัดอาจสลับกันได้ในเครื่องคุณ (job ทำงานคู่ขนานกับคำขอ) ไม่ใช่ปัญหา

เบื้องหลังที่ Rails ทำให้ — เทียบกับการเขียนเองใน Go

สไลด์หน้า 45 เทียบว่าถ้าทำเรื่องเดียวกันใน Go ต้องเขียนเองหลายชิ้น (คอร์ส Go ของเราไม่ได้ทำ WebSocket — เล่าเป็นภาษาคนพอให้เห็นขนาดงาน):

แถวสุดท้ายสำคัญ: ถ้าแอปรันบน server สองเครื่อง แท็บ A ต่อสายกับเครื่อง 1 แท็บ B ต่อกับเครื่อง 2 · ประกาศที่เกิดในเครื่อง 1 ต้องมีสถานีกลางส่งต่อให้เครื่อง 2 ด้วย · สถานีกลางนี้เรียกว่า pub/sub (publish = ประกาศ · subscribe = ขอฟัง) · ใน Go นิยมใช้ Redis (บท 32 ใช้ Redis ทำ cache — คนละงานแต่ตัวเดียวกัน)

Rails เรียกสถานีกลางนี้ว่า adapter และตั้งไว้ใน config/cable.yml · เปิดไฟล์จริงในโปรเจกต์ (ไม่ต้องแก้):

# Async adapter only works within the same process, so for manually triggering cable updates from a console,
# and seeing results in the browser, you must do so from the web console (running inside the dev process),
# not a terminal started via bin/rails console! Add "console" to any action or any ERB template view
# to make the web console appear.
development:
  adapter: async

test:
  adapter: test

production:
  adapter: solid_cable
  connects_to:
    database:
      writing: cable
  polling_interval: 0.1.seconds
  …

• development: adapter: async — ในเครื่องเรา สถานีกลางคือหน่วยความจำของ server ตัวที่รันอยู่ · ไม่มี Redis ไม่ใช้ฐานข้อมูล · พอ เพราะมี server ตัวเดียว
• production: adapter: solid_cable — ตอนขึ้นเครื่องจริง ใช้ Solid Cable: ประกาศถูกเขียนลงตารางในฐานข้อมูล แล้วทุก server คอยเปิดดูตารางนั้นถี่ ๆ (polling_interval: 0.1.seconds = ดูทุก 0.1 วินาที) · ได้สถานีกลางโดยไม่ต้องดูแล Redis เพิ่มอีกตัว
• คอมเมนต์ภาษาอังกฤษบนสุดเตือนเรื่องสำคัญ: async ใช้ได้เฉพาะใน process เดียวกัน · process = โปรแกรมหนึ่งตัวที่กำลังรันอยู่ · server Rails (ที่ bin/dev เปิดให้) คือหนึ่งตัว · bin/rails console ที่เปิดอีกหน้าต่างคืออีกตัว ความจำไม่ได้แชร์กัน

ผลจริง: เปิดแท็บดูบทความ 26 ไว้ แล้วสร้างคอมเมนต์จาก terminal อีกหน้าต่างด้วย bin/rails runner '…' (คำสั่งที่รันโค้ด Ruby ในแอปครั้งเดียวแล้วจบ เหมือนพิมพ์ใน console หนึ่งบรรทัด = อีก process หนึ่ง แยกจาก server):

B before {"count":"0","n":0}
saved
B after 3s {"count":"0","n":0}       ← ไม่เด้ง
B after reload {"count":"1","n":1}   ← คอมเมนต์อยู่ในฐานข้อมูลจริง กด refresh ถึงเห็น

ราคาของบรรทัดเดียว — ข้อควรระวัง

สไลด์หน้า 46 เตือนว่า broadcasts_to คือ callback ใน model ที่ไปทำเรื่องของคนอื่น · ทวนบท 112: callback ที่ทำเรื่องของตัวเอง (เช่นสร้าง slug) ใช้สบาย · แต่ callback ที่แตะของนอกตัว (ส่งอีเมล · ประกาศ) เริ่มมีผลข้างเคียง · บรรทัดนี้ทำ 2 เรื่องที่ไม่ใช่งานของคนดูแลสต็อก: จัดจาน (render partial ของ view) และประกาศ

ราคาที่ 1 — สร้างข้อมูลเยอะ ๆ = ประกาศเยอะ ๆ

callback ทำงานทุกครั้งที่สร้างคอมเมนต์ ไม่ว่าจะมาจากหน้าเว็บ · seed · หรือสคริปต์นำเข้าข้อมูล · เราลองสร้างคอมเมนต์ 100 อันด้วย bin/rails runner แล้วนับจาก log: มีงานประกาศถูกฝากไว้ 200 ชิ้น (2 ชิ้นต่อคอมเมนต์ — รายการ + ตัวนับ) · สไลด์ยกตัวอย่าง 10,000 แถว = ประกาศ 10,000 ครั้ง (คิดตามสัดส่วนที่วัดได้ ของเราจะเป็น 20,000 งาน เพราะมีบรรทัดตัวนับด้วย)

ทางแก้ตอน seed/import คือห่อด้วย suppressing_turbo_broadcasts = "ช่วงนี้ห้ามประกาศ" · ลองใน bin/rails console (ผลจริง ตัดบางส่วนเป็น …):

wongnok-blog-all-in-one(dev):001> Comment.suppressing_turbo_broadcasts { Post.find(25).comments.create!(author_name: "seed", body: "เงียบ") }; nil
  Post Load (2.0ms)  SELECT "posts".* FROM "posts" WHERE "posts"."id" = 25 LIMIT 1
  TRANSACTION (0.7ms)  BEGIN
  Comment Create (1.4ms)  INSERT INTO "comments" (…) VALUES ('เงียบ', 'seed', 25, …) RETURNING "id"
  TRANSACTION (0.5ms)  COMMIT
  Comment Count (0.4ms)  SELECT COUNT(*) FROM "comments" WHERE "comments"."post_id" = 25
=> nil
wongnok-blog-all-in-one(dev):002> Post.find(25).comments.create!(author_name: "ปกติ", body: "ดัง"); nil
  Post Load (3.0ms)  SELECT "posts".* FROM "posts" WHERE "posts"."id" = 25 LIMIT 1
  TRANSACTION (1.4ms)  BEGIN
  Comment Create (3.6ms)  INSERT INTO "comments" (…) VALUES ('ดัง', 'ปกติ', 25, …) RETURNING "id"
  TRANSACTION (1.7ms)  COMMIT
Enqueued Turbo::Streams::ActionBroadcastJob (Job ID: b1ac1546-…) to Async(default) with arguments: "Z2lk…UG9zdC8yNQ", {action: :append, target: "comments", …
↳ (wongnok-blog-all-in-one):2:in '<main>'
  Comment Count (1.1ms)  SELECT COUNT(*) FROM "comments" WHERE "comments"."post_id" = 25
Enqueued Turbo::Streams::ActionBroadcastJob (Job ID: b1b59b6c-…) to Async(default) with arguments: "Z2lk…UG9zdC8yNQ", {action: :update, target: "comment_count", …, html: 2, …
↳ app/models/comment.rb:7:in 'block in <class:Comment>'
=> nil
…

• Comment.suppressing_turbo_broadcasts { … } — ทุกอย่างในปีกกา Comment จะไม่ประกาศ · ออกจากปีกกาแล้วกลับมาประกาศตามปกติเอง
• ; nil ท้ายคำสั่ง — แค่ให้ console ไม่พิมพ์คอมเมนต์ทั้งก้อนออกมา (อ่านง่ายขึ้น)
• บรรทัด 001: ไม่มี Enqueued เลย ทั้งรายการและตัวนับ · บรรทัด 002 (นอกปีกกา): Enqueued 2 ชิ้นตามปกติ
• สังเกตว่าในปีกกายังมี Comment Count — Ruby นับ post.comments.count ก่อนแล้วค่อยเช็คว่า "ห้ามประกาศ" · ข้อมูลไม่ผิด แค่เสีย query เปล่าหนึ่งครั้งต่อแถว (100 แถวที่ลองใน runner = Comment Count 100 ครั้ง · งานประกาศ 0 ชิ้น)
• console เป็นอีก process หนึ่ง (เหมือน runner) — ต่อให้ประกาศ เบราว์เซอร์ก็ไม่ได้ยินอยู่ดี เพราะ adapter async · แต่งานยังถูกสร้างและทำจริง (บรรทัดที่ตัดเป็น … ท้ายสุดคือ job ที่ทำงานใน console เองจนถึง Broadcasting to — ประกาศออกไปโดยไม่มีใครฟัง เปลืองแรงเปล่า) จึงควรห่อเสมอ
• seeds ของเรา (บท 120) ไม่ได้สร้างคอมเมนต์ จึงยังไม่ต้องห่อ · ถ้าวันหลังเพิ่มคอมเมนต์ใน seeds ให้ห่อด้วยบล็อกนี้

ราคาที่ 2 — model รู้จัก view

ปกติคนดูแลสต็อก (model) ไม่ยุ่งกับการจัดจาน (view) · แต่ broadcasts_to ทำให้ model ไปเรียก partial comments/_comment เอง · ผลที่สไลด์เตือน: เปลี่ยนชื่อ partial แล้ว model พังโดยไม่รู้ตัว · test ของ model ต้อง render HTML ด้วยจึงช้าลง (เรื่อง test อยู่ Day 4)

ทางเลือกที่สไลด์เสนอ: ไม่ใส่ใน model แต่ให้ controller เป็นคนสั่งประกาศ หลังบันทึกสำเร็จ — seed/console ไม่โดนลูกหลง เพราะไม่ได้ผ่าน controller · หน้าตาประมาณนี้ (เราลองเรียกคำสั่งนี้จาก runner แล้วได้ Broadcasting to จริง · บทเรียนไม่ได้เปลี่ยนไปใช้แบบนี้ ไม่ต้องพิมพ์ตาม · สไลด์เขียน broadcast_append_to ซึ่งทำ HTML และประกาศทันทีในคำขอ · ตรงนี้ใช้รุ่น _later_ ให้ส่งต่อให้ job ตามหลักเดียวกับ broadcasts_to):

# ใน CommentsController#create หลัง @comment.save สำเร็จ (ตัวอย่างเท่านั้น)
Turbo::StreamsChannel.broadcast_append_later_to(
  @post, target: "comments", partial: "comments/comment", locals: { comment: @comment }
)

• Turbo::StreamsChannel — "ตัวประกาศ" ตัวเดียวกับที่ broadcasts_to ใช้อยู่เบื้องหลัง แต่คราวนี้เราเรียกเองตรง ๆ
• broadcast_append_later_to(@post, …) — ประกาศ append ในช่องของ @post · later = ฝากเป็นงาน · บอก target · partial · locals เองทั้งหมด (ไม่มีการเดาให้)

ข้อดี: อ่าน controller แล้วรู้เลยว่าใครสั่งประกาศ · ข้อเสีย: ทุกที่ที่สร้างคอมเมนต์ (เช่นหน้า admin ในอนาคต) ต้องจำใส่เอง · ไม่มีคำตอบเดียว — สไลด์สรุปว่า "ความสะดวกบรรทัดเดียวมีราคาเสมอ แค่ต้องรู้ว่าราคาคืออะไร"

ทำไมต้องหลัง commit — และ later: true ในสไลด์

broadcasts_to และบรรทัดตัวนับของเราใช้ after_*_commit ทั้งหมด · ทวนบท 112: ถ้าประกาศตอน after_save (ก่อน COMMIT) แล้ว transaction ถูกยกเลิก ทุกแท็บจะเห็นคอมเมนต์ที่ไม่มีอยู่จริง — เหมือนส่งไลน์บอกลูกค้าก่อนตู้เซ็นรับ · เราลองสร้างคอมเมนต์ใน transaction แล้วสั่ง raise ActiveRecord::Rollback (คำสั่ง "ยกเลิกทั้งกล่อง" ของ transaction): log มี BEGIN → ROLLBACK และไม่มี Enqueued สักบรรทัด = ไม่ประกาศของที่ถูกยกเลิก ✅

morphing และ data-turbo-permanent — refresh ทั้งหน้าแบบไม่สะดุด

สไลด์หน้า 47 พูดถึงอีกความสามารถหนึ่งของ Turbo 8 (รุ่นที่เราใช้) ซึ่งไม่ได้อยู่ในโค้ดของบทเรียน แต่ควรรู้จัก · ก่อนอื่นต้องรู้จัก page refresh = Turbo โหลดหน้าเดิมซ้ำ · เกิดบ่อยตอนส่งฟอร์มแล้ว server พากลับมาหน้าเดิม (redirect) หรือตอน server ประกาศว่า "ทุกคนโหลดหน้านี้ใหม่" (คำสั่ง broadcasts_refreshes_to — อีกทางเลือกแทน broadcasts_to ไม่ได้ใช้ในบทนี้)

ปกติ Turbo เปลี่ยนทั้ง <body> (บท 130) → หน้าเลื่อนกลับไปบนสุด ช่องที่กำลังพิมพ์หลุด · ถ้าใส่ 2 บรรทัดนี้ใน <head> ของ layout Turbo จะเทียบหน้าเก่ากับหน้าใหม่ทีละชิ้น แล้วแก้เฉพาะจุดที่ต่าง (เรียกว่า morphing):

<meta name="turbo-refresh-method" content="morph">     <%# refresh แบบเทียบแล้วแก้เฉพาะที่ต่าง %>
<meta name="turbo-refresh-scroll" content="preserve">  <%# refresh แล้วไม่เลื่อนกลับบนสุด %>

และถ้ามีชิ้นไหนที่ห้ามแตะเด็ดขาด (เช่นเครื่องเล่นเพลงที่กำลังเล่น) ให้ติด data-turbo-permanent พร้อม id:

<div id="player" data-turbo-permanent>
  <audio controls src="…"></audio>
</div>

ลองเองได้ (ไม่บังคับ): ใส่ 2 บรรทัด <meta> ข้างบนไว้ใต้ <%= yield :head %> ใน app/views/layouts/application.html.erb · พิมพ์ในช่องความคิดเห็น เลื่อนจอลง เปิด DevTools แท็บ Console แล้วพิมพ์ Turbo.session.refresh(location.href) (JavaScript หนึ่งบรรทัด: "Turbo ช่วย refresh หน้านี้" · location.href = URL ของหน้าที่เปิดอยู่) · ดูเสร็จแล้ว git restore app/views/layouts/application.html.erb — โค้ดของบทเรียนไม่ได้ใช้ morph

Turbo เหมาะกับงานแบบไหน

หลักง่าย ๆ: Turbo เก่งเมื่อ server เป็นคนตัดสินว่าหน้าจอควรเป็นแบบไหน และการรอ server ตอบสักครู่ไม่เป็นปัญหา · ทุกอย่างที่เราทำมาตั้งแต่บท 130 อยู่ในหลักนี้ — ข้อมูลชุดเดียวอยู่ที่ครัว (ประโยคหลักข้อ 1 ของวัน: ไม่มีสมุดจดเล่มที่สองบนโต๊ะ ก็ไม่มีบั๊ก sync)

งานแบบตารางที่สอง ถ้าเป็นชิ้นเล็ก ๆ ในหน้า (เช่นตัวนับอักษร · ปุ่มคัดลอก) ใช้ Stimulus = JavaScript ชิ้นเล็กที่ HTML เป็นคนเรียก (บท 134) · ถ้าทั้งแอปเป็นแบบนั้น (เช่นโปรแกรมวาดรูป) เครื่องมืออย่าง React ที่เรียนในฝั่ง FRONT จะเหมาะกว่า

ให้ AI ทำ แล้วตรวจยังไง

ตอนนี้คุณทำเองเป็นแล้ว · ถ้าจะสั่ง AI ทำ real-time ให้ส่วนอื่น ใช้ prompt 4 ส่วน (บท 89 · 121) แบบนี้ — อย่าก็อป later: true จากสไลด์ไปด้วย:

## เป้าหมาย
คอมเมนต์ใหม่เด้งขึ้นทุกแท็บที่เปิดหน้าบทความเดียวกัน · ตัวนับเปลี่ยนตาม

## ข้อกำหนด
- ใช้ broadcasts_to :post ใน app/models/comment.rb
- ใส่ turbo_stream_from @post ใน app/views/posts/show.html.erb
- partial comments/_comment ต้องมี id="<%= dom_id comment %>"

## ห้าม
- ใช้ after_save (ต้องเป็น after_commit)
- ส่งข้อความที่ผู้ใช้พิมพ์ผ่าน html:
- เขียน JavaScript เอง

## เกณฑ์ตรวจรับ
- [ ] เปิดสองหน้าต่างวางข้างกัน พิมพ์หน้าซ้าย หน้าขวาขึ้นเองทั้งคอมเมนต์และตัวนับ
- [ ] หน้าที่กดส่งเองไม่มีคอมเมนต์ซ้ำ

Checklist ตรวจงาน AI (ทำเองได้ทุกข้อ ไม่ต้องเชื่อคำบอกของ AI):

• grep -n "turbo_stream_from" app/views/posts/show.html.erb — ต้องเจอ 1 บรรทัด (ลืม = พังเงียบ)
• grep -n "after_save" app/models/comment.rb — ต้องไม่เจอ
• grep -n "dom_id" app/views/comments/_comment.html.erb — ต้องเจอ
• เปิดสองหน้าต่างแล้วลองจริง + ดู log ว่ามี transmitting เท่าจำนวนแท็บ — สไลด์หน้า 52 บอกว่าเกณฑ์แบบนี้ "AI โกงไม่ได้" เพราะพิสูจน์ด้วยการรัน

$ git diff --stat
 app/models/comment.rb         | 5 +++++
 app/views/posts/show.html.erb | 2 ++
 2 files changed, 7 insertions(+)

Quiz

ถ้าเปิดสไลด์ดูประกอบ

อ้างอิง

• Turbo Handbook — Come Alive with Turbo Streams — อ่านหัวข้อ Integration with Server-Side Frameworks (ส่ง Stream ผ่าน WebSocket)
• Turbo Reference — Streams — อ่านใต้ Append: ประโยคเรื่อง id ซ้ำแล้ว "replaced instead of appended" (เหตุผลที่แท็บซ้ายไม่ซ้ำ)
• turbo-rails 2.0.23 — broadcastable.rb — ดู def broadcasts_to (ไม่มี later:) และ def suppressing_turbo_broadcasts · คอมเมนต์ต้นไฟล์อธิบายว่าทำไมควรใช้ _later
• Rails Guides — Action Cable Overview — หัวข้อ Subscription Adapter (async · Solid Cable · Redis) และ Terminology (pub/sub · broadcastings)
• rails/solid_cable — README อธิบายว่าใช้ตารางในฐานข้อมูลแทน Redis และ polling_interval
• Rails Guides — Active Record Callbacks — หัวข้อ Transaction Callbacks (after_commit · after_create_commit)
• Turbo Handbook — Smooth page refreshes with morphing — หัวข้อ Morphing · Scroll preservation · Exclude sections from morphing (data-turbo-permanent)
• MDN — The WebSocket API — ย่อหน้าแรก: WebSocket คืออะไร ต่างจากการถาม-ตอบปกติยังไง