Best chat blocks 2026: 6 verified sections

A chat block is a drawn conversation without message transport. The catalogue has 6 from 4 registries, measured on 1 November 2026 on /api/blocks/category/chat; one reaches seven files and deserves a look first.

The problem no demo shows

In the preview the thread holds four messages and stays still. In production it holds four hundred and moves. The first failure is scrolling: if the component calls a scroll to the bottom on every render, anyone reading an old message is dragged down the moment a notification arrives and loses their place. The second is the keyboard: Enter sends, Shift plus Enter breaks the line, and a block that does not separate the two produces truncated messages.

The third failure is duplication. With an optimistic send the message appears immediately, then the server answers with the same text and the component appends it again. The fourth is accessibility: a new message appearing at the bottom without a live region is never announced, and someone who cannot see the screen does not know a reply arrived.

The signals to check in the code

• Where scrolling happens: in an effect on every message, or only when the user is already at the bottom.
• Whether the composer is a separate file, so you can replace it without touching the message list.
• Whether the textarea grows with the text and stops at a maximum height instead of pushing past the viewport.
• Whether every message carries a datetime time and a stable identifier, both required for reconciliation.
• The publisher licence, because the four registries do not declare the same terms.

Block size changes the kind of work. With a single file you build the conversation list, the switch between threads and the typing state yourself. With seven files the structure is there, but you also inherit choices you did not make: where the send button sits on mobile, how much room the header takes, how the list behaves on a tablet.

The stated limitation

None of the 6 blocks carries transport: there is no WebSocket, no polling, no retry queue. A message state machine, meaning sending, sent, failed, retried, is yours to write, and it decides whether the interface lies to the user. The second limitation is the publisher licence, which covers the block and not the libraries it imports.

The rule that saves the thread

If the thread stays under two hundred messages and has no attachments, take the single-file block and write the composer separately. If attachments, retries and several conversations are needed, start from the seven-file block and delete what you do not use: removing is faster than adding, but only when the code is readable. Either way, list virtualisation is your decision, not the block's.

The alternative is a headless component for the message log with your transport on top. It costs more lines upfront and leaves you in control of scrolling, announcements and retries, which are exactly the three places where a copied block breaks. The block stays handy for the bubble, the timestamps and the spacing, which are the boring and most visible parts.

One last detail covers attachments and images. A text-only block has neither a placeholder for an uploading file nor a way to state a maximum size, and in production people upload twenty-megabyte files. Before choosing, check whether the composer has an attachment button and whether the message bubble reserves space for an image: two cheap details that nobody adds later. A block with neither will be rebuilt, not extended.

curl "https://ui.eneawork.it/api/blocks/category/chat?limit=10"

Ready threads are in /blocks/category/chat, text fields in /components/cat/form and avatars in /icons. For accessibility read the React component checklist and for motion transitions in React; the comparison between a ready block and a headless component is in copy-paste or headless.