docs: chat app recipe with streaming patterns

[amsraman]

Adds a chat-app recipe under docs/recipes/others/: a basic message-bubble chat UI plus the streaming-append patterns (append the assistant message on the first token, not before) that keep the loading experience clean.

Draft — from the AI-builder memory corpus. Draft pending a news fragment / skip-changelog label and a sidebar/recipe-index entry if needed.

🤖 Generated with Claude Code

[codspeed-hq]

Merging this PR will not alter performance

✅ 26 untouched benchmarks
⏩ 8 skipped benchmarks¹

---

_{Comparing docs/chat-app-recipe (189e783) with main (f79d011)²}

Footnotes

1. 8 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

2. No successful run was found on main (e54bc83) during the generation of this report, so f79d011 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[greptile-apps]

Greptile Summary

This PR adds a new "Chat App" recipe under docs/recipes/others/chat.md and registers it in the sidebar. The recipe demonstrates a basic message-bubble UI and the correct streaming-append pattern for LLM responses in Reflex.

• Basic chat UI: showcases rx.foreach over a list[dict[str, str]] state var with Tailwind-styled bubbles and a form that resets on submit.
• Streaming pattern: correct implementation guards against overlapping submits with is_generating, appends the assistant bubble only on the first token, uses a captured index instead of self.messages[-1], and wraps the stream in try/finally; all previously raised review issues have been resolved.
• Sidebar: recipes.others.chat is added to the "Other" section so the recipe is discoverable in the left nav.

Confidence Score: 5/5

Safe to merge — two documentation files with no runtime code paths in the main application.

The changes are purely additive documentation. The correct streaming example is well-constructed: all state vars are declared, mutations stay inside async with self: blocks, the stream is wrapped in try/finally, and the is_generating guard with captured index prevents overlapping-stream races. Every issue raised in prior review rounds has been addressed.

No files require special attention.

Important Files Changed

Filename	Overview
docs/recipes/others/chat.md	New recipe covering basic chat UI and streaming patterns; all previously raised issues (is_streaming declaration, import openai, try/finally, yield-under-lock, sidebar registration) are resolved in the current revision.
docs/app/reflex_docs/templates/docpage/sidebar/sidebar_items/recipes.py	One-line addition registering recipes.others.chat in the sidebar's Other section; straightforward and correct.

_{Reviews (6): Last reviewed commit: "Update docs/recipes/others/chat.md" | Re-trigger Greptile}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 722007582a

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[amsraman]

Addressed in the latest commit ("Keep streamed tokens tied to their own assistant message"), taking the second remedy you suggested (per-turn index rather than self.messages[-1]).

The streaming handler now captures the assistant bubble's index when it's first appended (assistant_index = len(self.messages) - 1) and writes every subsequent delta to self.messages[assistant_index]. Because messages are only ever appended, a captured index never shifts, so two overlapping background streams each write to their own bubble — a later handler can no longer land tokens on an earlier message. The stream is wrapped in try/finally so is_streaming resets even if the API call raises.

On the loading flag: is_streaming is a plain indicator that's cleared on the first token (and again in finally), so under true overlap it's cosmetic (the dots) rather than a correctness issue — the message data itself is kept consistent by the captured index. A real app that wants to forbid overlap entirely would disable the input while is_streaming, which I've called out in the notes.

I traced the state mutations rather than driving a live token stream (the example uses a placeholder LLM client).