-
Notifications
You must be signed in to change notification settings - Fork 75
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[editor] Add 'Metadata' Section Under Settings Tab #1205
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ugh, sorry, just ignore this build stuff here and below. I had run yarn build accidentally and forgot to undo. It's ok to land the build changes since it needs to be done before publishing the aiconfig package anyway
callbacks: { | ||
onSuccess?: (aiconfigRes: AIConfig) => void; | ||
onError?: (err: unknown) => void; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what's the rationale to make this an object vs keep the callbacks defined?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using onSuccess
and onError
is a very common frontend pattern. I think Ryan is just following conventions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ya, for js usually it's common to use an object when props can be undefined rather than having literal 'undefined' prop before a defined one
...action.metadata, | ||
// Keep existing model and parameters metadata (managed by separate actions) | ||
model: prompt.metadata?.model, | ||
parameters: prompt.metadata?.parameters, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could this just be
metadata: {
action.metadata?
...prompt.metadata
}
instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Following up discussion offline w. Ankush so that others are aware.
He's ensuring that whatever is defined in action.metadata
(ex: "test": "Test value here") gets properly set through the action and not overridden by what was previously in the prompt.metadata
field. We also can't just do
metadata: { ...prompt.metadata action.metadata? }
Because action is a generic JSONObject
and Ryan is safe-guarding to ensure we can't possibly override the model
and parameters
unsafely through this UPDATE_PROMPT_METADATA
action
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, I had 2 questions
[UX] cc @zakariassoul Why not make other stuff like |
| UpdatePromptMetadataAction | ||
| UpdatePromptModelAction | ||
| UpdatePromptModelSettingsAction | ||
| UpdatePromptNameAction |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, alphabetical!
() => | ||
debounce( | ||
(newMetadata: JSONObject) => onUpdatePromptMetadata(newMetadata), | ||
250 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't we have a constant val for this in utils?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whoops, yep
const onError = (err: unknown) => { | ||
const message = (err as RequestCallbackError).message ?? null; | ||
showNotification({ | ||
title: "Error updating prompt name", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typo: should be metadata instead of name
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, good catch
// Just no-op if no callback specified. We could technically perform | ||
// client-side updates but that might be confusing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could technically perform client-side updates but that might be confusing
Nah this is a good call
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
K yo next time pls split this into small er diffs, would've been much easier to review. Ex:
- UI for showing tabs + JSON editor (no callback implementations)
- Implementation (getting model settings + schema renderer)
- Implementation (writing model settings, updating the reducer, etc)
- Other refactoring work (ex:
onSuccess
+onError
into singlecallbacks
object
@rossdanlm my overall feedback: 1- Displaying information/Actions needs to be contextual. Settings is global tab that enables a user to pick a model, and tweak it's behavior in one go. 2- Let's preserve the integrity of the UI. Simplicity is critical for adoption, and we need to say no to adding everything as a button or a tab even if we strongly feel it's useful. |
|
@rossdanlm, @rholinshead, & @Ankush-lastmile i suggest the following: 1- Put remember context back in the settings tab |
Ya, sorry. I had crunched through this last night and meant to spend some time cleaning it up this morning but kinda decided to put it up as-is and move to other priorities. Will be sure to do that next time |
@zakariassoul remember_chat_context wasn't in settings. It's a top-level metadata (i.e. prompt.metadata.remember_chat_context) for the prompt in the config. Settings tab is specifically prompt.metadata.model.settings in the config. The UI needs to dynamically render based on the metadata of the config (you can add any metadata in the prompt and it will show in this tab, previously we never showed it in the config), IMO we don't want to make our UI be coupled to these generic keys right now because we have nothing at the SDK level that currently dictates what these keys are. In the future we CAN update the sdk spec so that remember_chat_context is an explicit key in the prompt metadata type somewhere (e.g. X parser implements ChatModelParser) and then we can leverage that for the UI, but we need to update the config types to ensure all supported chat models do it that way |
Synced with @zakariassoul offline. Instead of its own tab, we can have the metadata below model settings (starting with remember_chat_context). Long-term, we can integrate an accordian-type UX for different "categories", e.g model metadata, lower-pri settings separate from hi-pri ones (will need schema changes). Caveat is we would want remember_chat_context to be part of the hi-pri settings section and not nested under metadata section |
# [editor] Add 'Metadata' Tab to Prompt Side Pane Currently the editor does not provide a way to modify general prompt metadata, outside of model settings and parameters. For some of our chat parsers, this means the user cannot modify the 'remember_chat_context' setting. This PR implements the UX for modifying this metadata, adding it as a tab in the side panel and associated with prompt_metadata in the prompt schema: https://github.com/lastmile-ai/aiconfig/assets/5060851/353e2e47-2210-4351-96ef-81eea03c2aab ![Screenshot 2024-02-09 at 11 03 06 AM](https://github.com/lastmile-ai/aiconfig/assets/5060851/cd371457-9fd1-45d4-996e-df470e048196) ![Screenshot 2024-02-09 at 11 03 11 AM](https://github.com/lastmile-ai/aiconfig/assets/5060851/82d646e5-e96a-427c-902e-319f16580b71) Make sure generic metadata can be set as well: <img width="437" alt="Screenshot 2024-02-09 at 11 22 55 AM" src="https://github.com/lastmile-ai/aiconfig/assets/5060851/6e4fbe08-280c-4fa2-9610-4ee86e1cfc2d">
Ok, updated per discussion with @zakariassoul. Moved the metadata below the settings (if schema exists, for now). The only new change since last PR is this placement (see change in PromptActionBar component) -- cc @rossdanlm for re-review when you have a minute |
[editor] Fix Model Parsers prompt_metadata remember_chat_context # [editor] Fix Model Parsers prompt_metadata remember_chat_context Update the relevant model parsers to have default and description for remember_chat_context. Also, remove it from the ones that don't actually support it in their parser --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/lastmile-ai/aiconfig/pull/1209). * __->__ #1209 * #1208 * #1205
[editor] Add 'Metadata' Section Under Settings Tab
Currently the editor does not provide a way to modify general prompt metadata, outside of model settings and parameters. For some of our chat parsers, this means the user cannot modify the 'remember_chat_context' setting. This PR implements the UX for modifying this metadata, adding it below the model settings in the settings tab. For now, only doing so if the prompt schema specifies
prompt_metadata
since I have some concerns about this UX for general metadata (without prompt schema it just renders as JSON editor below the settings and that's kind of confusing; it may be improved by having metadata under an accordion fold but still not sure just yet how we can have some metadata above that fold and some not).Screen.Recording.2024-02-15.at.11.56.55.AM.mov
Stack created with Sapling. Best reviewed with ReviewStack.