Skip to content
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

Feat: support managing predefined prompts with editing and replacement" #454

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

qcgm1978
Copy link
Contributor

@qcgm1978 qcgm1978 commented Jul 22, 2023

… after editing, it will replace the original prompt. Otherwise, it will create a new prompt.

截屏2023-07-22 20 29 41

Summary by CodeRabbit

  • New Features

    • The edit button is now always visible, enhancing user accessibility.
    • Introduced a new computed property to filter and display prompts based on user selections.
  • Bug Fixes

    • Improved logic for adding prompts, allowing new prompts to be added at the end if no specific index is provided.

… after editing, it will replace the original prompt. Otherwise, it will create a new prompt.
@vercel
Copy link

vercel bot commented Jul 22, 2023

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
chatall ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jul 22, 2023 0:31am

@sunner
Copy link
Member

sunner commented Jul 22, 2023

@tanchekwei Could you give a review? I believe you must have some reason to prevent editing the predefined prompts.

@tanchekwei
Copy link
Contributor

@tanchekwei Could you give a review? I believe you must have some reason to prevent editing the predefined prompts.

Added comment.

If a user wants to edit a predefined prompt, currently they can pin a prompt (which will add it to local storage) and then edit it.

@tanchekwei
Copy link
Contributor

@sunner, do you think we need to add another button, Duplicate button, for users to duplicate a predefined prompt and let them click the Edit button to modify it? Or, should we go with @qcgm1978’s approach and simply use the current Edit button for both duplicate and edit actions?

If we choose to add a Duplicate button, users will need to click two buttons to edit a predefined prompt: first, they click the Duplicate button, and then they click the Edit button. This approach is clearer.

if we use the Edit button for both actions, users will only need to click it once to edit the prompt. However, the existing edit button already use to edit the current user's prompt, same button with different behaviors may lead to confusion. What do you think?

@sunner
Copy link
Member

sunner commented Jul 23, 2023

Frankly speaking, I prefer an empty customized prompt library. The owner can choose to insert/edit/delete prompts, and import bulk prompts from other sources.

<v-btn
flat
size="x-small"
icon="mdi-delete-outline"
@click="deletePrompt(item.raw)"
v-if="item.raw.index >= 0"
></v-btn>
></v-btn>
Copy link
Collaborator

Choose a reason for hiding this comment

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

This change is not related to the topic.

Copy link
Collaborator

@PeterDaveHello PeterDaveHello left a comment

Choose a reason for hiding this comment

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

Adding a "Duplicate" button could help make the process of copying and editing prompts clearer. It would avoid any mix-ups with the current "Edit" button. Also, a fully customizable prompt library could be a cool addition for more user flexibility.

@PeterDaveHello
Copy link
Collaborator

@coderabbitai review

Copy link
Contributor

coderabbitai bot commented Sep 29, 2024

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

Copy link
Contributor

coderabbitai bot commented Sep 29, 2024

Walkthrough

The changes involve updates to the rendering logic and state management within the application. In PromptModal.vue, the edit button is now always rendered, while the delete button retains its conditional display. Additionally, a new computed property filters prompts based on user-defined titles. In the Vuex store, the editPrompt mutation has been modified to allow adding new prompts at the end of the list if no specific index is provided.

Changes

File Change Summary
src/components/PromptModal.vue The edit button is always rendered; a new computed property userPromptsTitles is added to filter prompts based on user-defined titles.
src/store/index.js The editPrompt mutation now sets index to the length of the state.prompts array if values.index is undefined, allowing for new prompt additions.

Poem

In the meadow where prompts play,
A button shines bright, come what may.
With titles that dance and twirl,
New prompts join the happy swirl.
Hopping along, we cheer and say,
"Let's edit and create, hip-hip-hooray!" 🐇✨


Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 1

🧹 Outside diff range and nitpick comments (4)
src/components/PromptModal.vue (2)

187-189: LGTM: Effective duplicate prevention logic.

The introduction of userPromptsTitles and the modified defaultPrompts computation effectively prevent duplicate prompts from being displayed. This aligns well with the PR objective of allowing users to edit predefined prompts while maintaining a clean prompt list.

A minor optimization suggestion:

Consider using a Set for userPromptsTitles to improve lookup performance:

const userPromptsTitles = new Set(userPrompts.value.map(d => d.title));
const valid = prompts[language.value].filter(d => !userPromptsTitles.has(d.act));

This change would slightly improve the performance of the filtering operation, especially for larger lists of prompts.


80-80: Consider UX implications of edit/duplicate functionality.

The current implementation allows editing of predefined prompts without an explicit "Duplicate" button. This approach simplifies the UI but may lead to some user confusion, as discussed in the PR comments.

Consider the following suggestions to improve user experience:

  1. Add a tooltip to the edit button explaining that editing a predefined prompt will create a new user prompt if the title is changed.
  2. Implement a confirmation dialog when editing a predefined prompt, asking the user if they want to create a new prompt or edit the existing one.
  3. Add visual differentiation between user prompts and predefined prompts in the list to make it clear which prompts are editable and which will create new prompts when edited.

These changes could help clarify the behavior for users without adding complexity to the UI.

src/store/index.js (2)

320-323: Enhance editPrompt mutation with a more precise default index condition.

The addition of a default index enhances the flexibility of the editPrompt function, allowing new prompts to be added at the end of the array when no specific index is provided. However, there are a few points to consider:

  1. The condition index || state.prompts.length might have unintended consequences if index is explicitly set to 0. Consider using a more precise condition like index === undefined ? state.prompts.length : index.

  2. The indentation of the new line is inconsistent with the rest of the code. Please adjust it to match the surrounding code style.

  3. It would be helpful to add a comment explaining this default index behavior for future maintainers.

Here's a suggested improvement:

 editPrompt(state, values) {
   let { index } = values;
-  index=index || state.prompts.length
+  // If index is undefined, add the new prompt at the end of the array
+  index = index === undefined ? state.prompts.length : index;
   state.prompts[index] = { ...state.prompts[index], ...values };
 },

320-323: Clarify the roles of editPrompt and addPrompt mutations.

The enhancement to editPrompt allows it to add new prompts, which may overlap with the functionality of the existing addPrompt mutation. To maintain clear separation of concerns and prevent potential confusion:

  1. Consider clarifying the distinction between editPrompt and addPrompt in the codebase. You might want to rename editPrompt to something like upsertPrompt to better reflect its dual functionality.

  2. Update any components or actions that use editPrompt to ensure they handle the new behavior correctly, especially when dealing with indices.

  3. Add appropriate error handling for invalid indices to prevent unintended modifications to the prompts array.

Here's a suggestion for error handling:

editPrompt(state, values) {
  let { index } = values;
  // If index is undefined, add the new prompt at the end of the array
  index = index === undefined ? state.prompts.length : index;
  
  // Ensure index is within bounds
  if (index < 0 || index > state.prompts.length) {
    console.error(`Invalid prompt index: ${index}`);
    return;
  }
  
  state.prompts[index] = { ...state.prompts[index], ...values };
},

Also, consider updating the related components to handle this new behavior appropriately.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 5555467 and 2b7094d.

📒 Files selected for processing (2)
  • src/components/PromptModal.vue (2 hunks)
  • src/store/index.js (1 hunks)
🔇 Additional comments (1)
src/components/PromptModal.vue (1)

80-80: LGTM: Edit button visibility change aligns with PR objectives.

The removal of the v-if directive from the edit button (line 80) allows it to be always visible, which aligns with the PR objective of enabling users to edit predefined prompts. The delete button (line 87) retains its conditional visibility, which is appropriate to prevent users from deleting predefined prompts.

Also applies to: 87-87

Comment on lines +320 to 323
let { index } = values;
index=index || state.prompts.length
state.prompts[index] = { ...state.prompts[index], ...values };
},
Copy link
Contributor

Choose a reason for hiding this comment

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

⚠️ Potential issue

Implement title comparison logic to align with PR objectives

There's a discrepancy between the PR objectives and the current implementation of the editPrompt mutation. The PR states that editing a prompt with the same title should replace the original, while a different title should create a new prompt. However, the current implementation doesn't reflect this behavior. To address this:

  1. Implement the title comparison logic as described in the PR objectives. This might involve searching for an existing prompt with the same title before deciding whether to edit or create a new one.

  2. Add safeguards to prevent unintended data loss or duplication. For example, you could add a confirmation step when overwriting an existing prompt.

  3. Consider updating the mutation to handle both editing and creating new prompts based on the title comparison, or split this functionality into separate mutations for clarity.

Here's a suggested implementation that aligns with the PR objectives:

editPrompt(state, values) {
  const { title, ...otherValues } = values;
  const existingIndex = state.prompts.findIndex(prompt => prompt.title === title);

  if (existingIndex !== -1) {
    // If a prompt with the same title exists, update it
    state.prompts[existingIndex] = { ...state.prompts[existingIndex], ...otherValues };
  } else {
    // If no prompt with the same title exists, create a new one
    state.prompts.push({ title, ...otherValues });
  }
},

This implementation ensures that the behavior matches the PR objectives and prevents unintended overwrites or duplications.

@PeterDaveHello PeterDaveHello changed the title Feat:Supports editing of predefined prompts. If the title is the same… Feat: support managing predefined prompts with editing and replacement" Sep 29, 2024
@PeterDaveHello
Copy link
Collaborator

@qcgm1978 Hi! Just checking if you still want to continue with this project. Let me know if you have other thoughts! 😊

@qcgm1978
Copy link
Contributor Author

@qcgm1978 Hi! Just checking if you still want to continue with this project. Let me know if you have other thoughts! 😊

I haven't been following the project for a while now, so I don't recall well what the changes here are about, and it's possible the approach back then was inadequate. You should feel more confident to refine it.

Choose a reason for hiding this comment

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

Copilot reviewed 2 out of 2 changed files in this pull request and generated no suggestions.

Comments skipped due to low confidence (2)

src/store/index.js:321

  • The assignment index = index || state.prompts.length can lead to unintended behavior if index is 0, as 0 is a falsy value in JavaScript. Consider using a more explicit check for undefined or null values.
index=index || state.prompts.length

src/components/PromptModal.vue:188

  • [nitpick] The variable name 'valid' is ambiguous. It should be renamed to 'filteredPrompts' for better clarity.
const valid = prompts[language.value].filter(d => !userPromptsTitles.includes(d.act));
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants