React UI Kit V7 - All the chat components you need. None of the complexity
by•
Build chat, voice, and video experiences in React faster with CometChat React UI Kit V7. Get production-ready messaging components, calling, AI features, theming, localization, and customization out of the box. New in V7: a more flexible component architecture, plugin-based extensibility, improved customization, and support for React, Next.js, React Router, and Astro. Ship a fully featured chat experience effortlessy.
Replies
CometChat
Hey 👋 Product Hunt!
Pourav here, PM at CometChat.
We kept hearing the same thing from React teams: the chat backend is the easy part. Then they hit the UI. Message lists that scroll the right way, typing indicators, read receipts, threads, retries, real-time listeners that don't leak on unmount — that's weeks of frontend work that has nothing to do with their actual product. And every team rebuilds it from scratch.
So we rebuilt our React UI Kit V7 around one idea: every component handles its own data, its own real-time listeners, and its own state. You drop it into your layout. It works.
A few highlights:
Compound components — compose only what you need (Root, View, EmptyState, and friends). No monolithic widget to fight.
Plugin system — custom message rendering through one interface, so your polls, payments, or whatever render the way you want.
Theming with CSS variables — light and dark out of the box, every token overridable.
SSR-safe — no browser APIs at module scope, so the Next.js App Router doesn't fight you.
19 languages built in, plus optional voice and video when you need them.
There's a live CodeSandbox in the docs if you want to fork it and poke at it.
Try it out for yourselves and let us know what you think. I'm in the comments all day.
Pourav
@pouravraj98 the "each component owns its own state" approach is exactly the part teams underestimate. I build voice/chat AI agents, so my question is about token streaming: when the assistant reply arrives as a stream of partial tokens, does the message component re-render on every chunk or do you batch/diff it so a long streamed answer doesn't thrash the list? That's the detail that usually breaks chat UIs once you plug an LLM in.
CometChat
Hi @david_marko
Each streamed token does not cause the entire message list to re-render. The live AI response is isolated within its own streaming bubble, so even long responses do not cause the message list to be re-rendered continuously.
Additionally, there is a small throttling mechanism in place. Instead of rendering every token immediately, streamed chunks are accumulated for a short period and then rendered together. This helps reduce the number of updates while still maintaining a smooth streaming experience.
So, the message list itself remains unaffected and is safe from excessive re-renders. The updates are limited to the streaming bubble that is currently receiving the AI response.
@pouravraj98 "No browser APIs at module scope so the App Router doesn't fight you" is the kind of sentence that has personally cost me weekends. Glad someone finally treated SSR as a feature and not an afterthought.
Chat UI is one of those things that looks simple until you start dealing with threads, retries, read receipts, and all the little edge cases. I like that this gives teams a cleaner starting point instead of making everyone rebuild the same pieces again.
Mailwarm
How do you handle presence and reconnection, like does it speedily recover when someone’s network drops?
V7's compound component model sounds cleaner - each component owning its own state and real-time listeners is a genuine improvement over the monolithic widget approach. The honest question: when every component manages "its own data," that data is wired to CometChat's backend. What does migration look like if a team later wants to swap to Stream Chat, Sendbird, or a self-hosted solution? "None of the complexity" is only true if the CometChat lock-in is a tradeoff teams understand clearly upfront.