Motivation
I should be able to fork my conversation with a chatbot. – Adam Rankin
using next.js and node server perhaps?
questions
what are react server components?
server components are components that will be rendered server-side: meaning the component will not be able to reflect client side changes.
- if we want to let a component handle client-side input-related changes, we have to use
"use client"at the very top. This changes the entire component into a client component, that does not have some benefits of RSC. - if we want to send outbound requests, those sent from a client-side components are often not banned from the api host; to handle this, next js projects can use /api routers to create an API route, call the external API there, and then can directly use the
const response = await fetch('/api/xxxx', { ...within the client component to do this.- I’m did not look into how nextjs handles the routing search, I imagine it being very burdensome heavy lifting.
Specifications
The entire idea of treechat is to display forked chats in clear tree visulas on a canvas that the user can drag around and scale, pretty much how Figma is. When the user opens a new window, we consider it default to show them a box that prompts them to start typing to chat. From here, the user can either do that (type something and hit send), or they can choose from the list of all the conversations on the left side. The conversations menu is on the left, and only shown if the user clicks the top left button. All the above is done. So if the user actually hits send on the “start conversation box”, then I envision that the window will transition to a new box that is actually the conversation message node that we will reuse as a component for each message in a conversation. This is a good time to outline the data design: because we ultimately want to fork any point of the conversation regardless of who said that turn (be it the bot or the user), I am imagining that a conversation, or a “chat”, is a list of levels or turns, whether i want to consolidate into either one of the two terms hasn’t been decided, but let’s go with turns. each turn belongs to one role (user or bot) and can contain one to many messages. each message in a turn has a parent id that points a message id to another message strictly one level above it. each message also has a children_ids that is a list of message ids that are strictly one level under it. Now there comes the choice of storing and fetching these levels. my idea is we have two ways: each chat only stores the root level (or root turn), and then we can recursively retrieve the rest of the turns and the messages in them from there; or, we can store the association between all nodes and messages, and all nodes and chats. the difference will be whether we iteratively construct the client side chat view (progressively load nodes within a chat) or if we want to fetch all nodes from a chat). This is as far as my thoughts stretched. let’s brainstorm and aim for the goal of determining the database schema and the apis we can expose to the front-end. we are using nextjs and supabase.