langflow/docs/docs/components/inputs-and-outputs.mdx
anovazzi1 4236d22098
Refactor SettingsPage component and add Messages page (#2084)
* Feat: Create the first version of the eraser tool

* feat: Add Messages page to SettingsPage

Refactor the SettingsPage component to include a new "Messages" page. This page will be accessible through the "/settings/messages" route and will display messages related to user settings. The necessary changes have been made to the index.tsx file of the SettingsPage component and the routes.tsx file.

* refactor(tableComponent): update column definitions to include checkbox selection logic for first column

feat(API): add support for excluding specific columns in getMessagesTable function

fix(flowLogsModal): pass excludedFields parameter to getMessagesTable function

refactor(GlobalVariablesPage): remove unnecessary checkbox selection properties from column definitions

fix(messagesPage): pass excludedFields parameter to getMessagesTable function

refactor(utils): add support for excluding specific columns in extractColumnsFromRows function

* feat: Add API endpoints for managing messages

This commit adds new API endpoints for managing messages. It includes the ability to delete messages by their IDs, update a specific message, and delete all messages associated with a session. These changes are implemented in the `monitor.py`, `schema.py`, and `service.py` files.

*  (monitor.py): add MessageIds schema for structured message deletion
♻️ (monitor.py): change delete_messages endpoint to POST for better semantics
♻️ (monitor.py): update delete_messages to use MessageIds schema
 (schemas.py): add MessageIds schema for structured message deletion
🐛 (service.py): fix SQL query in delete_messages to use correct column name
 (index.tsx): add toTitleCase utility to format column headers
 (API/index.ts): add deleteMessagesFn to handle message deletion via API
 (headerMessages): add HeaderMessagesComponent for message management UI
 (use-messages-table): add useMessagesTable hook to fetch and manage messages
 (use-remove-messages): add useRemoveMessages hook to handle message deletion

♻️ (messagesPage): refactor messages page to use new messages store
 (messagesStore): create zustand store for managing messages state
 (types): add types for messages and zustand messages store

* 💡 (schemas.py): add newline at end of file to follow PEP 8 guidelines

* refactor(headerMessages): update text content in HeaderMessagesComponent

* move editable attribute to table Component

* refactor: Move editable attribute to TableComponent
add update function, need to fix backend

* ♻️ (monitor.py): change POST to DELETE for delete_messages endpoint
♻️ (schemas.py): remove unused MessageIds schema
♻️ (api.tsx): add missing commas in ApiInterceptor function
🐛 (api.tsx): fix duplicate request check to include method "get"
♻️ (index.ts): change deleteMessagesFn to use DELETE method instead of POST
♻️ (use-remove-messages.tsx): clean up comments and improve error handling

* start history in playgroundModal

* ♻️ (monitor.py): refactor update_message to return MessageModelResponse
♻️ (service.py): update SQL query to use index instead of id
♻️ (api.tsx): refactor duplicate request check logic
 (check-duplicate-requests.ts): add helper to check and store duplicate requests
🐛 (messagesStore.ts): fix message update logic to use index instead of id

* ♻️ (monitor.py, service.py): remove trailing whitespace to improve code cleanliness

* refactor: Add getSessions function to fetch available sessions in IOModal

* 🐛 (service.py): add missing 'id' column in SQL query to fix data retrieval issue
💡 (service.py): add print statement for debugging SQL query
♻️ (index.tsx): reorder imports for better readability and maintainability

♻️ (flowStore.ts): remove trailing commas to improve code consistency and readability

💡 (index.ts, storeUtils.ts): format type definitions for better readability

* update editable fields

* Feat: Make the table last column non-resizable and add a restore columns button

* Remove unnused imports

* Refactor: Remove “Page size” from table pagination

* Refactor: remove page size directly in css file

* chore: Update description text in SettingsPage

* Refactor: Add ResetColumns component to improve table functionality

* Refactor: Make Reset Column button reset columns order

* Refactor: Remove select from delete session button

* Refactor: Remove commented code for chat history tab in IOModal

* update route

* fix selection bug on Messages Table

* fix libs

---------

Co-authored-by: igorrCarvalho <igorsilvabhz6@gmail.com>
Co-authored-by: ogabrielluiz <gabriel@langflow.org>
Co-authored-by: cristhianzl <cristhian.lousa@gmail.com>
Co-authored-by: italojohnny <italojohnnydosanjos@gmail.com>
2024-06-05 20:37:38 -03:00

161 lines
6.6 KiB
Text

import Admonition from "@theme/Admonition";
import ZoomableImage from "/src/theme/ZoomableImage.js";
# Inputs and Outputs
TL;DR: Inputs and Outputs are a category of components that are used to define where data comes in and out of your flow.
They also dynamically change the Playground and can be renamed to facilitate building and maintaining your flows.
## Inputs
Inputs are components used to define where data enters your flow. They can receive data from the user, a database, or any other source that can be converted to Text or Record.
The difference between Chat Input and other Input components is the output format, the number of configurable fields, and the way they are displayed in the Playground.
Chat Input components can output `Text` or `Record`. When you want to pass the sender name or sender to the next component, use the `Record` output. To pass only the message, use the `Text` output, useful when saving the message to a database or memory system like Zep.
You can find out more about Chat Input and other Inputs [here](#chat-input).
### Chat Input
This component collects user input from the chat.
**Parameters**
- **Sender Type:** Specifies the sender type. Defaults to `User`. Options are `Machine` and `User`.
- **Sender Name:** Specifies the name of the sender. Defaults to `User`.
- **Message:** Specifies the message text. It is a multiline text input.
- **Session ID:** Specifies the session ID of the chat history. If provided, the message will be saved in the Message History.
<Admonition type="note" title="Note">
<p>
If `As Record` is `true` and the `Message` is a `Record`, the data of the
`Record` will be updated with the `Sender`, `Sender Name`, and `Session ID`.
</p>
</Admonition>
<ZoomableImage
alt="Docusaurus themed image"
sources={{
light: "img/chat-input-expanded.png",
dark: "img/chat-input-expanded.png",
}}
style={{ width: "40%", margin: "20px auto" }}
/>
One significant capability of the Chat Input component is its ability to transform the Playground into a chat window. This feature is particularly valuable for scenarios requiring user input to initiate or influence the flow.
<ZoomableImage
alt="Docusaurus themed image"
sources={{
light: "img/interaction-panel-with-chat-input.png",
dark: "img/interaction-panel-with-chat-input.png",
}}
style={{ width: "50%", margin: "20px auto" }}
/>
### Text Input
The **Text Input** component adds an **Input** field on the Playground. This enables you to define parameters while running and testing your flow.
**Parameters**
- **Value:** Specifies the text input value. This is where the user inputs text data that will be passed to the next component in the sequence. If no value is provided, it defaults to an empty string.
- **Record Template:** Specifies how a `Record` should be converted into `Text`.
The **Record Template** field is used to specify how a `Record` should be converted into `Text`. This is particularly useful when you want to extract specific information from a `Record` and pass it as text to the next component in the sequence.
For example, if you have a `Record` with the following structure:
```json
{
"name": "John Doe",
"age": 30,
"email": "johndoe@email.com"
}
```
A template with `Name: {name}, Age: {age}` will convert the `Record` into a text string of `Name: John Doe, Age: 30`.
If you pass more than one `Record`, the text will be concatenated with a new line separator.
<ZoomableImage
alt="Docusaurus themed image"
sources={{
light: "img/text-input-expanded.png",
dark: "img/text-input-expanded.png",
}}
style={{ width: "50%", margin: "20px auto" }}
/>
## Outputs
Outputs are components that are used to define where data comes out of your flow. They can be used to send data to the user, to the Playground, or to define how the data will be displayed in the Playground.
The Chat Output works similarly to the Chat Input but does not have a field that allows for written input. It is used as an Output definition and can be used to send data to the user.
You can find out more about it and the other Outputs [here](#chat-output).
### Chat Output
This component sends a message to the chat.
**Parameters**
- **Sender Type:** Specifies the sender type. Default is `"Machine"`. Options are `"Machine"` and `"User"`.
- **Sender Name:** Specifies the sender's name. Default is `"AI"`.
- **Session ID:** Specifies the session ID of the chat history. If provided, messages are saved in the Message History.
- **Message:** Specifies the text of the message.
<Admonition type="note" title="Note">
<p>
If `As Record` is `true` and the `Message` is a `Record`, the data in the
`Record` is updated with the `Sender`, `Sender Name`, and `Session ID`.
</p>
</Admonition>
### Text Output
This component displays text data to the user. It is useful when you want to show text without sending it to the chat.
**Parameters**
- **Value:** Specifies the text data to be displayed. Defaults to an empty string.
The `TextOutput` component provides a simple way to display text data. It allows textual data to be visible in the chat window during your interaction flow.
## Prompts
A prompt is the input provided to a language model, consisting of multiple components and can be parameterized using prompt templates. A prompt template offers a reproducible method for generating prompts, enabling easy customization through input variables.
### Prompt
This component creates a prompt template with dynamic variables. This is useful for structuring prompts and passing dynamic data to a language model.
**Parameters**
- **Template:** The template for the prompt. This field allows you to create other fields dynamically by using curly brackets `{}`. For example, if you have a template like `Hello {name}, how are you?`, a new field called `name` will be created. Prompt variables can be created with any name inside curly brackets, e.g. `{variable_name}`.
<ZoomableImage
alt="Docusaurus themed image"
sources={{
light: "img/prompt-with-template.png",
dark: "img/prompt-with-template.png",
}}
style={{ width: "50%", margin: "20px auto" }}
/>
### PromptTemplate
The `PromptTemplate` component enables users to create prompts and define variables that control how the model is instructed. Users can input a set of variables which the template uses to generate the prompt when a conversation starts.
<Admonition type="info">
After defining a variable in the prompt template, it acts as its own component
input. See [Prompt Customization](../administration/prompt-customization) for
more details.
</Admonition>
- **template:** The template used to format an individual request.