Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Comments

docs(plans): add react-sdk primitives subpath plan#1927

Merged
lachieh merged 4 commits intomainfrom
lachieh/tam-1010-build-from-scratch-list-of-components-for-component-library
Jan 28, 2026
Merged

docs(plans): add react-sdk primitives subpath plan#1927
lachieh merged 4 commits intomainfrom
lachieh/tam-1010-build-from-scratch-list-of-components-for-component-library

Conversation

@lachieh
Copy link
Contributor

@lachieh lachieh commented Jan 26, 2026

TL;DR

  1. Extract business logic and break down UI components into smaller components that are either; dumb/style-only display components; or statueful business logic components/hooks
  2. Add a tree-shakeable @tambo-ai/react/primitives subpath export containing hooks, utilities, and unstyled primitive components extracted from ui-registry

Summary

  • Adds plan for extracting business logic from large UI components (message-input.tsx, message.tsx) into reusable primitives
  • Primitives live in react-sdk as a subpath export (not a separate package)
  • Incremental approach: refactor components in-place first, then move to shared location
  • Tree-shakeable so users only bundle what they import

Plan for extracting business logic from UI components into reusable
hooks, utilities, and unstyled primitive components via a tree-shakeable
subpath export at @tambo-ai/react/primitives.

Co-Authored-By: Claude Opus 4.5 <[email protected]>
@charliecreates charliecreates bot requested a review from CharlieHelps January 26, 2026 23:22
@vercel
Copy link

vercel bot commented Jan 26, 2026

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Review Updated (UTC)
cloud Ready Ready Preview, Comment Jan 27, 2026 4:59pm
showcase Ready Ready Preview, Comment Jan 27, 2026 4:59pm
tambo-docs Ready Ready Preview, Comment Jan 27, 2026 4:59pm

@github-actions github-actions bot added area: documentation Improvements or additions to documentation change: docs Documentation changes contributor: tambo-team Created by a Tambo team member status: triage Needs to be triaged by a maintainer labels Jan 26, 2026
Copy link
Contributor

@charliecreates charliecreates bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The plan has internal inconsistencies that will block clean implementation: it alternates between primitives living in react-sdk/src/primitives and in a separate packages/primitives-ui, despite explicitly choosing “no new package”. It also presents conflicting package.json#exports examples (source TS vs built artifacts), leaving the shipping contract ambiguous. Finally, some hook sketches embed UI/icon elements, which undermines the stated goal of unstyled, tree-shakeable primitives.

Summary of changes

Added a new plan document

  • Introduced plans/2026-01-26-feat-react-sdk-primitives-plan.md describing a tree-shakeable subpath export: @tambo-ai/react/primitives.
  • Documented:
    • Proposed architecture and module layout (hooks/, utils/) for primitives.
    • Example consumer usage imports (e.g. useTamboAutoScroll, useMessageInputState, formatToolResult).
    • Proposed interfaces for key hooks/utilities.
    • A 10-step migration plan starting with in-place refactors in ui-registry, then adding package.json exports, then extracting/moving hooks and utilities.
    • Testing strategy, acceptance criteria, backwards compatibility requirements, and out-of-scope items.
  • Included two package.json export examples: a simplified TS-source export snippet and a build-artifacts export snippet for ESM/CJS/types.

@charliecreates charliecreates bot removed the request for review from CharlieHelps January 26, 2026 23:25
Copy link
Contributor

@alecf alecf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really glad to see this shared code actually shared!

My high-level notes:

  • I personally feel like putting this in a separate library feels cleaner - I have found it hard/frustrating to have a separate "mcp" subpackage - it's very hard to maintain strict dependency boundaries especially with the AI tools - they're all to happy to import across library boundaries and just drag everything into the main package
  • I personally like "core" more than "primitives" - its a pretty common "base' package name for a lot of projects (you often see it when you have a project that consists of multiple npm libraries, you might not even know that "core" was in there because you're pulling in some higher-level library
  • I don't think you need two sub packages (primitives and primitives/utils) - it seems like "primitives" is mostly just types anyway
  • It kind of feels like these functions are all kind of extract as-is from the components (I'm sure that's because that's exactly what they are!) but that makes them feel like a kind of random hodge-podge of random association of items, even within the library. Personally I hate directories called "hooks" because hooks are the impelmentation detail, and really they should be organized semantically, e.g.
input/use-message-input-state.ts
input/draft-persistence.ts
input/keyboard-shortcuts.ts
suggestions/use-suggestion-merge.ts
tools/use-tool-response.ts
tools/tool-status.ts
content/use-message-content.ts
content/content-transforms.ts
content/content-??.ts
  • I think of "utils" as a kind of "misc stuff until we figure out where this goes" - so personally I'd avoid starting a library with utils.ts files - make every filename count

@charliecreates charliecreates bot requested a review from CharlieHelps January 26, 2026 23:48
@github-actions github-actions bot added contributor: ai AI-assisted contribution and removed contributor: tambo-team Created by a Tambo team member labels Jan 26, 2026
Copy link
Contributor

@charliecreates charliecreates bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The plan has several internal inconsistencies that will block clean implementation: it mixes TS-source vs build-artifact exports, and it contradicts “no new package” by targeting packages/primitives-ui in Steps 3–8. It also violates its own UI-agnostic/tree-shaking stance by returning JSX icons in a primitives hook example. Finally, SSR behavior around document/sessionStorage should be made explicit and enforced in the steps/examples, and the backwards-compat deprecation strategy needs a clearer, non-noisy policy.

Summary of changes

Added a new plan document for @tambo-ai/react/primitives

  • Introduced plans/2026-01-26-feat-react-sdk-primitives-plan.md describing a tree-shakeable subpath export: @tambo-ai/react/primitives.
  • Documented:
    • Design goals: extracting business logic from ui-registry components into hooks/utilities/unstyled primitives.
    • A dedicated Tree-shaking Requirements section (e.g., avoid module side effects, consider "sideEffects": false, caution with barrel exports).
    • Proposed module layout under react-sdk/src/primitives/{hooks,utils} plus consumer usage examples.
    • Sketches of hook/util interfaces (useTamboAutoScroll, useMessageInputState, formatToolResult, etc.).
    • A 10-step migration plan starting with in-place refactors, adding package.json#exports, extracting utilities/hooks, and validating via tests.
    • Testing strategy, backwards compatibility requirements, and acceptance criteria.

@charliecreates charliecreates bot removed the request for review from CharlieHelps January 26, 2026 23:54
@lachieh
Copy link
Contributor Author

lachieh commented Jan 27, 2026

@alecf lots here, inline responses:

  • I personally feel like putting this in a separate library feels cleaner - I have found it hard/frustrating to have a separate "mcp" subpackage - it's very hard to maintain strict dependency boundaries especially with the AI tools - they're all to happy to import across library boundaries and just drag everything into the main package

Happy to make that switch. I initially had it as a separate library, but everything from the new package is so dependent on @tambo-ai/react that I decided to merged them. After thinking about it and seeing some things confirmed by Charlie's comments, I'm thinking I agree on separating it. The package boundary makes tree-shaking much easier—if the package isn't installed, there's nothing to shake!

  • I personally like "core" more than "primitives" - its a pretty common "base' package name for a lot of projects (you often see it when you have a project that consists of multiple npm libraries, you might not even know that "core" was in there because you're pulling in some higher-level library

Here's my thinking:

  • We're currently using packages/core as @tambo-ai-cloud/core.
  • The */core naming convention on the client-side is usually reserved for framework-agnostic code, this would be react-specific
  • The same problem goes for @tambo-ai/primitives, actually. There isn't anything react specific in the name but there probably should be.
  • Radix established the term primitives but it has been picked up by a couple of other projects and some UX blogs.

Originally, I think I had it called @tambo-ai/react-primitives or maybe @tambo-ai/ui-primitives-react.

  • I don't think you need two sub packages (primitives and primitives/utils) - it seems like "primitives" is mostly just types anyway

  • It kind of feels like these functions are all kind of extract as-is from the components (I'm sure that's because that's exactly what they are!) but that makes them feel like a kind of random hodge-podge of random association of items, even within the library. Personally I hate directories called "hooks" because hooks are the impelmentation detail, and really they should be organized semantically, e.g.

input/use-message-input-state.ts
input/draft-persistence.ts
input/keyboard-shortcuts.ts
suggestions/use-suggestion-merge.ts
tools/use-tool-response.ts
tools/tool-status.ts
content/use-message-content.ts
content/content-transforms.ts
content/content-??.ts
  • I think of "utils" as a kind of "misc stuff until we figure out where this goes" - so personally I'd avoid starting a library with utils.ts files - make every filename count

Agreed. I much prefer fractal-style "feature" folders so I'll probably follow something similar to that here.

@alecf
Copy link
Contributor

alecf commented Jan 27, 2026

@lachieh all sounds good - I think I personally feel like "primitives" works in radix because a "button" is a primitive UI element even outside of radix... but I wouldn't say that a content hook is primitive hook? or that a transformer function is a "primitive" function? I dunno.. not a hill I need to die on but it just feels a little off. I'd also be fine with changing our internal package to core-internal or just internal or maybe cloud or cloud-core if that somehow made core available.

@lachieh
Copy link
Contributor Author

lachieh commented Jan 27, 2026

Mm yeah that's a good point. The other name I threw around was headless.

Edit: Ended up going with @tambo-ai/react-ui-base

- Rename package from primitives to @tambo-ai/react-ui-base
- Replace hooks/utils folders with feature folders:
  - message-input/, message/, thread/, resources/, scroll/
- Update subpath exports to match feature structure
- Colocate hooks and utilities by domain

Co-Authored-By: Claude Opus 4.5 <[email protected]>
@github-actions github-actions bot added contributor: tambo-team Created by a Tambo team member and removed contributor: ai AI-assisted contribution labels Jan 27, 2026
Copy link
Contributor

@alecf alecf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice, I like "base"

@lachieh lachieh merged commit a8466ce into main Jan 28, 2026
20 checks passed
@lachieh lachieh deleted the lachieh/tam-1010-build-from-scratch-list-of-components-for-component-library branch January 28, 2026 03:21
nicolasmondain pushed a commit to nicolasmondain/tambo that referenced this pull request Feb 14, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area: documentation Improvements or additions to documentation change: docs Documentation changes contributor: tambo-team Created by a Tambo team member status: triage Needs to be triaged by a maintainer

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants