chore: Moving action settings from editor form to toolbar #36894
Conversation
WalkthroughThe pull request introduces several modifications across various components related to plugin action settings. Key changes include consolidating conditional rendering logic in the Changes
Assessment against linked issues
Possibly related PRs
Suggested labels
Suggested reviewers
📜 Recent review detailsConfiguration used: .coderabbit.yaml 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
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? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
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)
Other keywords and placeholders
Documentation and Community
|
ankitakinger
requested review from
albinAppsmith and
hetunandu
and removed request for
ayushpahwa
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (8)
app/client/src/PluginActionEditor/components/PluginActionSettings/ApiSettings.tsx (1)
1-5: Well done on your imports, class! Let's make a small improvement.Your imports are looking good, and I'm pleased to see you're using type imports. However, let's tidy up a bit:
Consider grouping your imports by their origin:
import { reduxForm } from "redux-form"; import { API_EDITOR_FORM_NAME } from "ee/constants/forms"; import PluginActionSettingsPopover, { type SettingsProps, } from "./SettingsPopover";This organization makes it easier to distinguish between external libraries, internal modules, and local imports. Remember, a tidy codebase is a happy codebase!
app/client/src/PluginActionEditor/components/PluginActionSettings/QuerySettings.tsx (1)
7-10: Excellent work on your component export, students!Let's break down what we're seeing here:
- We're using the reduxForm higher-order component to wrap our PluginActionSettingsPopover. This is like giving our component a special Redux Form backpack!
- We've set the form name using our constant. Remember, consistency is key in coding!
- We've enabled reinitialization. This means our form can update when its initial values change - very useful!
However, there's always room for improvement. Can anyone tell me what we could do better?
Consider replacing
unknownwith a more specific type for your form values. It's like labeling your lunchbox - the more specific, the better!-export default reduxForm<unknown, SettingsProps>({ +export default reduxForm<YourFormValuesType, SettingsProps>({Remember, class, specific types help us catch errors early and make our code easier to understand!
app/client/src/PluginActionEditor/components/PluginActionForm/PluginActionForm.tsx (1)
22-25: Well done, class! This code consolidation deserves a gold star!You've successfully simplified the conditional rendering of the
UQIEditorForm. This change reduces code duplication and improves readability. Excellent work!However, to make it even better, we could use the logical OR operator (
||) instead of the current syntax. Here's a small homework assignment for you:Try refactoring the condition like this:
- {(plugin.uiComponent === UIComponentTypes.DbEditorForm || - plugin.uiComponent === UIComponentTypes.UQIDbEditorForm) && ( + {[UIComponentTypes.DbEditorForm, UIComponentTypes.UQIDbEditorForm].includes(plugin.uiComponent) && ( <UQIEditorForm /> )}This approach is more concise and easier to extend if more
UIComponentTypesneed to be added in the future. Keep up the good work!app/client/src/PluginActionEditor/store/pluginActionEditorActions.ts (1)
22-22: Here's a small homework assignment to make our code even better!While your implementation is spot-on, we can always strive for excellence in documentation. Consider adding a brief comment above the function to explain its purpose. This will help your fellow students (I mean, developers) understand the function's role at a glance. Here's an example:
// Opens or closes the plugin action settings popup in the toolbar export const openPluginActionSettings = (payload: boolean) => ({ // ... rest of the function });Remember, clear documentation is like showing your work in math class - it helps others follow your thinking!
app/client/src/PluginActionEditor/store/pluginActionEditorSelectors.ts (1)
63-64: Well done, class! Let's review this new addition.Good job on adding the
isPluginActionSettingsOpenselector function. It follows the established pattern in our codebase and is placed appropriately at the end of the file. The function name clearly describes its purpose, which is excellent for readability.For consistency with other selector functions in this file, consider using
createSelectorfrom thereselectlibrary. This approach can help with memoization and potentially improve performance.Here's a small homework assignment to improve your code:
-export const isPluginActionSettingsOpen = (state: AppState) => - state.ui.pluginActionEditor.settingsOpen; +export const isPluginActionSettingsOpen = createSelector( + (state: AppState) => state.ui.pluginActionEditor.settingsOpen, + (settingsOpen) => settingsOpen +);This change aligns your new function with the style of other selectors in this file. Keep up the good work!
app/client/src/PluginActionEditor/components/PluginActionToolbar.tsx (1)
55-55: A gold star for implementing the new settings component!You've successfully integrated the
PluginActionSettingscomponent into our toolbar, which is precisely what we aimed for in our lesson plan. This change effectively moves the action settings from the editor form to the toolbar, as outlined in our project objectives.To make your work even more exemplary, consider adding a brief comment above this line explaining the purpose of the
PluginActionSettingscomponent. This will help your classmates understand its role in the toolbar.Here's a suggested comment to add above the component:
// Render the action settings component in the toolbar <PluginActionSettings />app/client/src/PluginActionEditor/store/pluginEditorReducer.ts (1)
175-182: Attention, class! We have a new action handler to discuss.This new handler for
OPEN_PLUGIN_ACTION_SETTINGSis like adding a new rule to our classroom. When this action is dispatched, it's as if a student has raised their hand to open or close the settings.The implementation is correct and follows our established patterns. However, to make it even clearer for future students (I mean, developers), we could add a small comment explaining the purpose of this handler.
Here's a suggested improvement:
[ReduxActionTypes.OPEN_PLUGIN_ACTION_SETTINGS]: ( state: PluginActionEditorState, action: ReduxAction<{ settingsOpen: boolean }>, ) => { // Update the visibility state of the plugin action settings const { settingsOpen } = action.payload; state.settingsOpen = settingsOpen; },Remember, clear code is like a well-explained lesson - it helps everyone understand and learn!
app/client/src/PluginActionEditor/components/PluginActionSettings/SettingsPopover.tsx (1)
25-25: Remember to Address the TODO Comment Regarding Custom WidthPlease ensure to remove the
SettingsWrappercomponent after the custom width issue is resolved on the server side, as noted in the TODO comment. It's important to keep the codebase clean and up-to-date to maintain readability and maintainability.If you need assistance with this task or would like me to open a new GitHub issue to track it, please let me know.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (15)
- app/client/src/PluginActionEditor/components/PluginActionForm/PluginActionForm.tsx (1 hunks)
- app/client/src/PluginActionEditor/components/PluginActionForm/components/APIEditorForm.tsx (2 hunks)
- app/client/src/PluginActionEditor/components/PluginActionForm/components/GraphQLEditor/GraphQLEditorForm.tsx (2 hunks)
- app/client/src/PluginActionEditor/components/PluginActionSettings/ApiSettings.tsx (1 hunks)
- app/client/src/PluginActionEditor/components/PluginActionSettings/QuerySettings.tsx (1 hunks)
- app/client/src/PluginActionEditor/components/PluginActionSettings/SettingsPopover.tsx (1 hunks)
- app/client/src/PluginActionEditor/components/PluginActionSettings/index.tsx (1 hunks)
- app/client/src/PluginActionEditor/components/PluginActionToolbar.tsx (2 hunks)
- app/client/src/PluginActionEditor/store/pluginActionEditorActions.ts (1 hunks)
- app/client/src/PluginActionEditor/store/pluginActionEditorSelectors.ts (1 hunks)
- app/client/src/PluginActionEditor/store/pluginEditorReducer.ts (3 hunks)
- app/client/src/ce/constants/ReduxActionConstants.tsx (1 hunks)
- app/client/src/pages/Editor/APIEditor/GraphQL/GraphQLEditorForm.tsx (3 hunks)
- app/client/src/pages/Editor/APIEditor/RestAPIForm.tsx (3 hunks)
- app/client/src/pages/Editor/QueryEditor/QueryResponseTab.tsx (2 hunks)
🧰 Additional context used
🔇 Additional comments (30)
app/client/src/PluginActionEditor/components/PluginActionSettings/ApiSettings.tsx (1)
7-10: Excellent work on your Redux form configuration! Let's refine it further.Your use of reduxForm is spot on, and I'm thrilled to see you're using the constant for the form name. The enableReinitialize option is a smart choice too!
However, let's make your code even more robust:
export default reduxForm<FormData, SettingsProps>({ form: API_EDITOR_FORM_NAME, enableReinitialize: true, })(PluginActionSettingsPopover);Replace
unknownwithFormData, whereFormDatais an interface representing the structure of your form data. This will provide better type safety and make your code more self-documenting. Remember, clear types are like clear handwriting - they make everything easier to understand!Let's check if
FormDatais already defined:If
FormDataisn't defined yet, consider adding it to improve your type definitions. Keep up the good work!✅ Verification successful
Great job identifying the issue with the previous search attempt! Let's refine our approach to successfully locate the
FormDatainterface.This script adjusts the
--typeflag tots, which is the correct identifier for TypeScript files inripgrep. Execute this script to verify whether theFormDatainterface is defined within your codebase.
Great effort in enhancing the type safety of your Redux form configuration!
However, it appears that the
FormDatainterface isn't defined in your codebase. Instead, there's an existingFormDataStateinterface that you can utilize for better type safety.
Update the generic type parameter from
unknowntoFormDataState:export default reduxForm<FormDataState, SettingsProps>({ form: API_EDITOR_FORM_NAME, enableReinitialize: true, })(PluginActionSettingsPopover);This change will provide clearer type definitions and improve the maintainability of your code.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for FormData interface definition # Test: Search for FormData interface. Expect: Definition of FormData interface. rg --type typescript 'interface FormData'Length of output: 78
Script:
#!/bin/bash # Description: Check for FormData interface definition using the correct TypeScript file type # Test: Search for FormData interface in TypeScript files. Expect: Definition of FormData interface. rg 'interface FormData' --type tsLength of output: 128
app/client/src/PluginActionEditor/components/PluginActionSettings/QuerySettings.tsx (1)
1-5: Well done on your imports, class!Let's review what we've learned here:
- We're using a constant for our form name. This is excellent practice, children!
- We're importing the reduxForm higher-order component. This will be crucial for our form management.
- We're bringing in our PluginActionSettingsPopover and its props type. Remember, types are our friends in TypeScript!
These imports set us up nicely for the rest of our code. Good job!
app/client/src/PluginActionEditor/components/PluginActionSettings/index.tsx (2)
1-9: Well done on your import statements, class!You've done a splendid job importing all the necessary modules and components. It's like you've packed your backpack with all the right books for the day's lessons!
24-24: Excellent job on your export statement!You've correctly exported your
PluginActionSettingscomponent as the default export. It's like putting your name at the top of your homework - it lets everyone know exactly what to expect from this file. Keep up the good work!app/client/src/PluginActionEditor/components/PluginActionForm/PluginActionForm.tsx (1)
Line range hint
1-30: Class, let's discuss how this change relates to our project goals!While this code improvement is commendable, I noticed it doesn't directly address our main objective of moving action settings from the editor form to the toolbar. Let's have a quick pop quiz:
- How does this change contribute to our overall goal?
- Are there any other files where we're implementing the toolbar changes?
Remember, it's important to keep our eyes on the prize! Let's make sure all our changes are working towards our main objective.
To help us understand the bigger picture, let's do a little research:
This will help us see if there are other files where the main changes are being implemented. Let's review the results together in our next class!
✅ Verification successful
Toolbar Implementation Verified
Great job! The toolbar changes are successfully implemented in the
PluginActionToolbar.tsxfile, ensuring that our main objective of moving action settings to the toolbar is achieved.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Search for files that might be implementing the toolbar changes echo "Files potentially related to toolbar implementation:" rg --type typescript --type tsx -l 'toolbar|PluginActionToolbar' echo "\nFiles with recent changes related to plugin actions:" git diff --name-only HEAD~5 | grep -i 'pluginaction'Length of output: 1271
app/client/src/PluginActionEditor/store/pluginActionEditorActions.ts (3)
22-27: Excellent work, class! This new function is a fine addition to our Redux action creators.The
openPluginActionSettingsfunction is well-implemented and aligns perfectly with our lesson on moving action settings to a popup in the toolbar. It follows the standard Redux action creator pattern, which we've been studying all semester. The naming is clear, and the implementation is concise. Well done!
22-28: A gold star for maintaining consistency and organization!Class, take note of how well this new function integrates with our existing code. It's placed logically after the imports and before other action creators, maintaining our file's neat structure. The implementation style matches our other action creators perfectly, showing excellent adherence to our coding standards. This is a textbook example of how to add new functionality while preserving code consistency.
22-28: Class dismissed with high marks!Overall, this addition to our codebase is exemplary. The new
openPluginActionSettingsfunction is well-implemented, properly integrated, and aligns perfectly with our lesson plan (PR objectives). You've demonstrated a strong grasp of Redux concepts and maintained excellent code quality. With just a small touch-up on documentation, this will be a model example for future lessons. Keep up the great work!app/client/src/PluginActionEditor/components/PluginActionForm/components/GraphQLEditor/GraphQLEditorForm.tsx (3)
31-31: Well done, class! Let's discuss this change.Children, notice how we've replaced
FORM_NAMEwithAPI_EDITOR_FORM_NAME. This is an excellent example of reducing redundancy in our code. By using the imported constant directly, we've made our code cleaner and more maintainable. Remember, in programming, as in life, it's important to keep things simple and avoid unnecessary repetition.
37-37: Excellent consistency, students!Just like we saw earlier, we've updated the
formNameprop here as well. This is a prime example of maintaining consistency throughout our code. Remember, class, consistency is key in programming. It makes our code easier to understand and maintain. Keep up the good work!
47-50: Pay attention, class! This is an important change.In this final modification, we've updated our Redux form configuration. By changing
form: FORM_NAMEtoform: API_EDITOR_FORM_NAME, we ensure that our form is correctly registered with Redux. This is crucial for proper state management in our application.Think of it like assigning the correct name to your homework. If it's not labeled properly, it might get lost or mixed up with someone else's work. Similarly, in Redux, the correct form name ensures that our form data is stored and retrieved correctly.
Excellent job on maintaining consistency throughout the component!
app/client/src/PluginActionEditor/components/PluginActionForm/components/APIEditorForm.tsx (2)
44-44: Excellent work on updating the formName prop, class!I'm pleased to see you've updated the
formNameprop to use theAPI_EDITOR_FORM_NAMEconstant. This change enhances code consistency and makes it easier for your classmates to understand the purpose of this form. Keep up the good work!
59-62: Well done on updating the reduxForm configuration!I'm impressed by your attention to detail in updating the
reduxFormconfiguration. By using theAPI_EDITOR_FORM_NAMEconstant here as well, you've ensured consistency throughout the component. This change will help prevent confusion and potential bugs in the future. Remember, class, consistency is key in programming!app/client/src/PluginActionEditor/components/PluginActionToolbar.tsx (1)
14-14: Excellent addition of the new import, class!The import of
PluginActionSettingsis a step in the right direction for our lesson on moving action settings to the toolbar. Well done on following the proper import syntax!app/client/src/pages/Editor/APIEditor/RestAPIForm.tsx (3)
35-35: Well done, class! This change gets an A+.You've successfully simplified the code by directly using the
API_EDITOR_FORM_NAMEconstant. This promotes consistency and reduces unnecessary variables. Keep up the good work!
49-49: Excellent work on maintaining consistency!You've shown great attention to detail by updating the
formValueSelectorto useAPI_EDITOR_FORM_NAMEdirectly. This change aligns perfectly with the previous modification. Your code is becoming more coherent and easier to understand. Keep up this level of consistency!
107-107: Outstanding job on completing the refactoring!You've successfully updated the
formproperty in thereduxFormfunction to useAPI_EDITOR_FORM_NAMEdirectly. This change completes the consistent use of the imported constant throughout the file. Let's recap the lesson:
- You've removed the unnecessary
FORM_NAMEconstant.- You've directly used
API_EDITOR_FORM_NAMEin all relevant places.- These changes have made the code more consistent and easier to maintain.
Your refactoring skills are improving! Remember, clean and consistent code is easier to read and maintain. Keep up the excellent work!
app/client/src/pages/Editor/APIEditor/GraphQL/GraphQLEditorForm.tsx (4)
37-37: Good job, class! Let's review this change.Children, notice how we've replaced
FORM_NAMEwithAPI_EDITOR_FORM_NAME. This is like when we change the label on our pencil box to make it clearer what's inside. It helps us keep our code organized and easy to understand.
42-42: Well done! Let's examine this change together.Class, do you see how we've made the same change here in the
Paginationcomponent? It's like when we use the same color crayon to underline all the important words in our notebook. This consistency helps us avoid confusion and keeps our code neat and tidy.
102-102: Excellent work! Let's discuss this final change.Now, children, this last change is very important. It's like writing our name on the front of our assignment before we hand it in. By using
API_EDITOR_FORM_NAMEhere, we're telling Redux (our helper in managing data) exactly which form we're talking about. This ensures that all our form data stays organized and easy to find.
Line range hint
37-102: Class, let's summarize what we've learned today!We've seen three important changes in our code:
- In the
GraphQLEditorFormcomponent- In the
Paginationcomponent- In the Redux form configuration
By consistently using
API_EDITOR_FORM_NAME, we've made our code clearer and easier to understand. It's like using the same label for all the boxes that belong together in our classroom. This helps us keep everything organized and makes it easier for other developers (or your classmates) to understand our code.Remember, consistency is key in coding, just like in handwriting practice!
app/client/src/PluginActionEditor/store/pluginEditorReducer.ts (2)
31-31: Class, let's examine this new addition to our interface!The
settingsOpenproperty is a welcome addition to ourPluginActionEditorStateinterface. It's like adding a new chapter to our book of state management. This boolean flag will help us keep track of whether the settings are open or closed, which is crucial for our new toolbar design.Remember, students, optional properties (denoted by the
?) are like extra credit questions on a test - they're there if you need them, but not required for everyone.
46-46: Now, class, let's turn our attention to the initial state!Just as we start each school day with a clean chalkboard, our
initialStatenow includessettingsOpen: false. This is like setting the default position of our classroom door - closed until someone decides to open it.This initialization is crucial, as it ensures that our application starts with a consistent state. Remember, in the world of state management, a well-defined initial state is like a strong foundation for a building - it supports everything that comes after.
app/client/src/pages/Editor/QueryEditor/QueryResponseTab.tsx (3)
41-41: Class, let's examine this import statement change.Good job on updating the import statement! This change reflects our move towards a more intuitive user interface. By replacing
setPluginActionEditorDebuggerStatewithopenPluginActionSettings, we're shifting from manipulating a debugger state to directly opening settings. This aligns perfectly with our lesson plan of relocating action settings to the toolbar.Remember, children, in programming as in life, clear and direct actions often lead to better user experiences!
221-221: Now, class, let's turn our attention to this function call.Excellent work on updating the function call! By replacing
setPluginActionEditorDebuggerStatewithopenPluginActionSettings(true), we've simplified our code and improved user accessibility. This change means that when a user interacts with this part of the interface, they'll be taken directly to the plugin action settings.Think of it like this: instead of giving directions to the library (setting a state), we're now opening the library door for our users (directly opening settings). This is a prime example of how small changes can greatly enhance user experience.
Keep up the good work, and remember: in coding as in the classroom, clarity and directness are key to success!
Line range hint
1-368: Class, let's summarize today's lesson on code changes.Well done on these modifications! You've successfully updated both the import statement and the corresponding function call. These changes are like updating our classroom layout - they make it easier for our "students" (the users) to access important "learning materials" (the plugin action settings).
These alterations, while small, significantly contribute to our goal of moving action settings from the editor form to the toolbar. This new approach will provide a more intuitive and accessible interface for our users.
Remember, class, sometimes the most impactful changes are the simplest ones. Keep up this attention to detail and user-focused thinking in your future code "assignments"!
app/client/src/ce/constants/ReduxActionConstants.tsx (2)
502-502: Well done, class! This addition looks splendid!I'm pleased to see you've added a new action type
OPEN_PLUGIN_ACTION_SETTINGSto ourIDEActionTypesobject. This is a fine example of expanding our application's capabilities. Remember, children, every new action type we add is like a new tool in our coding toolbox. It allows us to create more interactive and feature-rich experiences for our users.Keep up the good work, and don't forget to update any relevant documentation to reflect this new action type!
Line range hint
1-1134: Class, let's recap our lesson for today!We've made a small but significant addition to our Redux action types. The new
OPEN_PLUGIN_ACTION_SETTINGSaction type in theIDEActionTypesobject is like adding a new vocabulary word to our coding language. It will help us communicate more effectively with our application, specifically when dealing with plugin action settings in the IDE.Remember, every line of code we write has a purpose. This new action type will likely be used to trigger the opening of plugin action settings, enhancing the functionality of our IDE.
As we move forward, keep in mind that maintaining clear and organized constants like these is crucial for a well-structured application. It's like keeping your desk tidy – it helps you find what you need when you need it!
Great job on this addition. Keep up the excellent work, and don't forget to use this new action type appropriately in your future assignments!
app/client/src/PluginActionEditor/components/PluginActionSettings/SettingsPopover.tsx (2)
42-47: Verify Popover Closing BehaviorIn your
useEffecthook, you open the popover wheneveropenSettingsistrue. However, whenopenSettingsbecomesfalse, the popover remains open unless manually closed. Ensure this behavior aligns with the desired user experience.To confirm, please check if the popover should automatically close when
openSettingschanges tofalse.
59-90: Excellent Component Structure and LogicYour
PluginActionSettingsPopovercomponent is well-structured and follows best practices. The handling of state, effects, and event callbacks is clear and effective. Great job integrating the various UI components to achieve the desired functionality.
app/client/src/PluginActionEditor/components/PluginActionSettings/index.tsx
Outdated
Show resolved
Hide resolved
app/client/src/PluginActionEditor/components/PluginActionSettings/SettingsPopover.tsx
Outdated
Show resolved
Hide resolved
…o chore/move-action-settings
|
/build-deploy-preview skip-tests=true |
github-actions
bot
added
IDE Navigation
|
Deploying Your Preview: https://github.com/appsmithorg/appsmith/actions/runs/11358959512. |
|
This PR has increased the number of cyclic dependencies by 1, when compared with the release branch. Refer this document to identify the cyclic dependencies introduced by this PR. |
github-actions
bot
added
the
skip-changelog
|
Deploy-Preview-URL: https://ce-36894.dp.appsmith.com |
|
This PR has increased the number of cyclic dependencies by 1, when compared with the release branch. Refer this document to identify the cyclic dependencies introduced by this PR. |
…o chore/move-action-settings
|
This PR has increased the number of cyclic dependencies by 1, when compared with the release branch. Refer this document to identify the cyclic dependencies introduced by this PR. |
|
/build-deploy-preview skip-tests=true |
|
Deploy-Preview-URL: https://ce-36894.dp.appsmith.com |
|
This PR has increased the number of cyclic dependencies by 2, when compared with the release branch. Refer this document to identify the cyclic dependencies introduced by this PR. |
|
/build-deploy-preview skip-tests=true |
|
Deploying Your Preview: https://github.com/appsmithorg/appsmith/actions/runs/11384354695. |
|
/build-deploy-preview skip-tests=true |
|
Deploying Your Preview: https://github.com/appsmithorg/appsmith/actions/runs/11384454351. |
|
This PR has increased the number of cyclic dependencies by 2, when compared with the release branch. Refer this document to identify the cyclic dependencies introduced by this PR. |
|
Deploy-Preview-URL: https://ce-36894.dp.appsmith.com |
…g#36894) ## Description Moving action settings from editor form to toolbar to follow the new designs under action redesign project. Fixes [appsmithorg#35512](appsmithorg#35512) [appsmithorg#34670](appsmithorg#34670) [appsmithorg#35535](appsmithorg#35535) ## Automation /ok-to-test tags="@tag.Sanity" ### 🔍 Cypress test results <!-- This is an auto-generated comment: Cypress test results --> > [!TIP] > 🟢 🟢 🟢 All cypress tests have passed! 🎉 🎉 🎉 > Workflow run: <https://github.com/appsmithorg/appsmith/actions/runs/11384449381> > Commit: 027e2a3 > <a href="https://internal.appsmith.com/app/cypress-dashboard/rundetails-65890b3c81d7400d08fa9ee5?branch=master&workflowId=11384449381&attempt=1" target="_blank">Cypress dashboard</a>. > Tags: `@tag.Sanity` > Spec: > <hr>Thu, 17 Oct 2024 12:40:29 UTC <!-- end of auto-generated comment: Cypress test results --> ## Communication Should the DevRel and Marketing teams inform users about this change? - [ ] Yes - [ ] No <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Summary by CodeRabbit ## Release Notes - **New Features** - Introduced new components for managing API and query settings in the Plugin Action Settings. - Added functionality to open plugin action settings directly from the toolbar. - Implemented a settings popover interface for improved user interaction. - Added documentation links for QUERY_SETTINGS to enhance user guidance. - **Improvements** - Simplified rendering logic in the Plugin Action Form for better performance. - Updated form naming conventions for consistency across API and GraphQL editors. - Streamlined configuration settings by replacing `subtitle` with `tooltipText` for clarity. - Enhanced styling in Action Settings for better layout and user experience. - **Bug Fixes** - Corrected the navigation logic to open plugin action settings instead of debugger state. These enhancements aim to improve user experience and streamline plugin action management. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
…g#36894) ## Description Moving action settings from editor form to toolbar to follow the new designs under action redesign project. Fixes [appsmithorg#35512](appsmithorg#35512) [appsmithorg#34670](appsmithorg#34670) [appsmithorg#35535](appsmithorg#35535) ## Automation /ok-to-test tags="@tag.Sanity" ### 🔍 Cypress test results <!-- This is an auto-generated comment: Cypress test results --> > [!TIP] > 🟢 🟢 🟢 All cypress tests have passed! 🎉 🎉 🎉 > Workflow run: <https://github.com/appsmithorg/appsmith/actions/runs/11384449381> > Commit: 027e2a3 > <a href="https://internal.appsmith.com/app/cypress-dashboard/rundetails-65890b3c81d7400d08fa9ee5?branch=master&workflowId=11384449381&attempt=1" target="_blank">Cypress dashboard</a>. > Tags: `@tag.Sanity` > Spec: > <hr>Thu, 17 Oct 2024 12:40:29 UTC <!-- end of auto-generated comment: Cypress test results --> ## Communication Should the DevRel and Marketing teams inform users about this change? - [ ] Yes - [ ] No <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Summary by CodeRabbit ## Release Notes - **New Features** - Introduced new components for managing API and query settings in the Plugin Action Settings. - Added functionality to open plugin action settings directly from the toolbar. - Implemented a settings popover interface for improved user interaction. - Added documentation links for QUERY_SETTINGS to enhance user guidance. - **Improvements** - Simplified rendering logic in the Plugin Action Form for better performance. - Updated form naming conventions for consistency across API and GraphQL editors. - Streamlined configuration settings by replacing `subtitle` with `tooltipText` for clarity. - Enhanced styling in Action Settings for better layout and user experience. - **Bug Fixes** - Corrected the navigation logic to open plugin action settings instead of debugger state. These enhancements aim to improve user experience and streamline plugin action management. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
Description
Moving action settings from editor form to toolbar to follow the new designs under action redesign project.
Fixes #35512 #34670 #35535
Automation
/ok-to-test tags="@tag.Sanity"
🔍 Cypress test results
Tip
🟢 🟢 🟢 All cypress tests have passed! 🎉 🎉 🎉
Workflow run: https://github.com/appsmithorg/appsmith/actions/runs/11384449381
Commit: 027e2a3
Cypress dashboard.
Tags:
@tag.SanitySpec:
Thu, 17 Oct 2024 12:40:29 UTC
Communication
Should the DevRel and Marketing teams inform users about this change?
Summary by CodeRabbit
Summary by CodeRabbit
Release Notes
New Features
Improvements
subtitlewithtooltipTextfor clarity.Bug Fixes
These enhancements aim to improve user experience and streamline plugin action management.