docs: add TypeScript and Python state guides - #2979
docs: add TypeScript and Python state guides#2979Mehak Bindra (MehakBindra) wants to merge 1 commit into
Conversation
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
🟡 Changes recommended
The new Python documentation includes code/text that can raise at runtime (unhandled None for ctx.activity.text / ctx.state.user) and should be corrected before merge.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Pull request overview
Expands the “State Management” in-depth guide to include TypeScript and Python alongside C#, using the LanguageInclude template system so the same page renders per-language content.
Changes:
- Removes TypeScript/Python from the missing-pages manifest for the state guide.
- Refactors
state.mdxinto a shared template with common lifecycle notes + language includes. - Adds new language include fragments for TypeScript, Python, and C# state setup/usage/clearing/distributed storage.
File summaries
| File | Description |
|---|---|
| teams.md/static/missing-pages.json | Marks the state guide as no longer missing for TypeScript/Python. |
| teams.md/src/pages/templates/in-depth-guides/state.mdx | Converts state guide to shared template + per-language include sections. |
| teams.md/src/components/include/in-depth-guides/state/typescript.incl.md | Adds TypeScript-specific state guidance and examples. |
| teams.md/src/components/include/in-depth-guides/state/python.incl.md | Adds Python-specific state guidance and examples. |
| teams.md/src/components/include/in-depth-guides/state/csharp.incl.md | Moves the existing C# guidance into an include fragment. |
Review details
- Files reviewed: 5/5 changed files
- Comments generated: 2
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| if ctx.state.user is not None and ctx.activity.text.startswith("my name is "): | ||
| ctx.state.user["name"] = ctx.activity.text[len("my name is "):].strip() |
|
|
||
| <!-- clearing --> | ||
|
|
||
| Remove a value with `del scope[key]` or clear one scope with `ctx.state.conversation.clear()` or `ctx.state.user.clear()`. To remove both scopes from the backing store: |
|
|
||
| <!-- setup --> | ||
|
|
||
| Set the `App` option `state` to `true`. With no storage provider configured, state uses process-local `LocalStorage` and is lost when the process restarts. |
There was a problem hiding this comment.
| Set the `App` option `state` to `true`. With no storage provider configured, state uses process-local `LocalStorage` and is lost when the process restarts. | |
| Set the `App` option `state` to `true`. With no storage provider configured, state uses an in-memory `Map<string, T>` and is lost when the process restarts. |
I suggest something like this (and similar for Python), this reads like LocalStorage is a standard-library feature when that's not the case.
| // Read | ||
| string? last = context.State.ConversationState.Get<string>("lastMessage"); | ||
| int count = context.State.UserState.Get<int>("messageCount"); | ||
| Only changed scopes are persisted. After the handler chain finishes, the SDK saves state and seals both scopes. Do not retain turn state for background work; accessing a sealed scope throws an error. |
There was a problem hiding this comment.
Are these concepts that only apply to .NET? I'm not sure what they mean or how they would work in what I see provided in Python and TypeScript.
|
|
||
| <!-- distributed-state --> | ||
|
|
||
| Process-local storage is intended for development only. For production or multi-instance deployments, pass a shared `Storage[str, Any]` implementation through `StateOptions`. The state API used by handlers does not change: |
There was a problem hiding this comment.
Similar sentiment here as the comment about LocalStorage; this reads like it's something the user is expected to know about from a standard library. You don't necessarily need to document the whole interface, but at least call out that it's something they'll need to implement.
Summary
Validation