Chore/replace entities in entity explorer #38750
Conversation
…oups list templates
…o chore/replace-entities-in-entity-explorer
WalkthroughThis pull request introduces a comprehensive refactoring of the codebase's editor type management, transitioning from a generic "editor type" to a more specific "IDE type" concept. The changes span multiple files, replacing the Changes
Possibly related issues
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
📜 Recent review detailsConfiguration used: .coderabbit.yaml 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms (5)
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
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (14)
app/client/src/ce/pages/Editor/IDE/EditorPane/Query/ActionEntity/index.tsx (1)
5-10: LGTM! Consider adding JSDoc documentation.Clean pass-through component with proper typing. Adding JSDoc would help document the component's purpose and props.
+/** + * ActionEntity serves as a wrapper for QueryEntity, providing type-safe prop forwarding + * @param props.parentEntityId - ID of the parent entity + * @param props.item - Entity item details + */ export const ActionEntity = (props: {app/client/src/ce/pages/Editor/IDE/EditorPane/Query/ListItem.tsx (1)
Line range hint
12-23: Consider making searchKeyword prop configurable.The searchKeyword prop is hardcoded to an empty string. If search functionality is needed, this should be made configurable through props.
export interface QueryListItemProps { item: EntityItem; isActive: boolean; parentEntityId: string; + searchKeyword?: string; } export const QueryListItem = (props: QueryListItemProps) => { - const { isActive, item, parentEntityId } = props; + const { isActive, item, parentEntityId, searchKeyword = "" } = props;app/client/src/ce/IDE/hooks/useParentEntityInfo.ts (1)
14-19: Consider making parentEntityType dynamic.The parentEntityType is hardcoded to PAGE. Consider deriving it from ideType parameter for more flexibility.
return { editorId: appId || "", parentEntityId: basePageId || "", - parentEntityType: ActionParentEntityType.PAGE, + parentEntityType: getParentEntityTypeFromIDE(ideType), };app/client/src/ce/entities/IDE/utils.ts (1)
81-88: Simplify redundant switch statement.The switch statement can be simplified since both cases return the same items.
-export const getMenuItemsForActionEntityByIdeType = (ideType: IDEType) => { - switch (ideType) { - case IDE_TYPE.App: - return defaultActionMenuItems; - default: - return defaultActionMenuItems; - } -}; +export const getMenuItemsForActionEntityByIdeType = (ideType: IDEType) => { + return defaultActionMenuItems; +};app/client/src/ce/pages/Editor/IDE/EditorPane/Query/utils.ts (1)
60-78: Simplify redundant switch statement and consider future extensibility.The switch statement can be simplified as it returns the same items for all cases. However, if this is a placeholder for future differentiation between parent types, consider adding a TODO comment.
export const getMenuItemsForActionEntityByParentType = ( parentEntityType: ActionParentEntityTypeInterface, ) => { const defaultMenuItems = [ ActionEntityContextMenuItemsEnum.RENAME, ActionEntityContextMenuItemsEnum.DELETE, ActionEntityContextMenuItemsEnum.SHOW_BINDING, ActionEntityContextMenuItemsEnum.COPY, ActionEntityContextMenuItemsEnum.MOVE, ActionEntityContextMenuItemsEnum.CONVERT_QUERY_MODULE_INSTANCE, ]; - - switch (parentEntityType) { - case "PAGE": - return defaultMenuItems; - default: - return defaultMenuItems; - } + // TODO: Add specific menu items for different parent types if needed + return defaultMenuItems; };app/client/src/ce/entities/IDE/constants.ts (2)
143-150: LGTM! Consider using const enum for better performance.The enum values are well-defined and descriptive.
-export enum ActionEntityContextMenuItemsEnum { +export const enum ActionEntityContextMenuItemsEnum {
152-159: LGTM! Consider adding type annotation for better maintainability.The array correctly uses all enum values.
-export const defaultActionMenuItems = [ +export const defaultActionMenuItems: ActionEntityContextMenuItemsEnum[] = [app/client/src/pages/Editor/Explorer/Actions/ActionEntity.tsx (1)
50-50: Consider memoizing ideType to prevent unnecessary recalculations.The IDE type is derived from the location pathname on every render.
- const ideType = getIDETypeByUrl(location.pathname); + const ideType = useMemo(() => getIDETypeByUrl(location.pathname), [location.pathname]);app/client/src/ce/hooks/datasourceEditorHooks.tsx (1)
Line range hint
75-134: Consider extracting the nested logic into separate functions.The useHeaderActions hook contains deeply nested logic that could be simplified for better maintainability.
Consider splitting into:
- useGeneratePageButton
- useNewActionButton
- useHeaderPermissions
app/client/src/pages/Editor/IDE/EditorPane/Query/ActionEntity/QueryEntity.tsx (2)
54-54: Consider memoizing validateName hook dependencies.The validateName hook is created with empty dependencies on every render.
- const validateName = useValidateEntityName({}); + const validateNameOptions = useMemo(() => ({}), []); + const validateName = useValidateEntityName(validateNameOptions);
79-94: Consider extracting analytics logic into a custom hook.The switchToAction callback handles both navigation and analytics tracking. These concerns could be separated for better maintainability.
Consider creating a custom hook like
useActionAnalyticsto handle all analytics events.app/client/src/pages/Editor/CustomWidgetBuilder/useCustomBuilder.tsx (1)
Line range hint
166-167: Consider addressing the TODO comment.The event type could be properly typed instead of using
any. This would improve type safety.- window.addEventListener("message", (event: any) => { + window.addEventListener("message", (event: MessageEvent<{ + type: string; + name?: string; + widgetId?: string; + srcDoc?: string; + uncompiledSrcDoc?: string; + model?: unknown; + events?: unknown; + theme?: unknown; + }>) => {app/client/src/pages/Editor/IDE/EditorPane/Query/ActionEntity/QueryEntityContextMenu.tsx (1)
115-198: Consider extracting menu options configuration.The optionsTree array is quite large and contains complex logic. Consider extracting it into a separate configuration function for better maintainability.
app/client/src/pages/Editor/IntegrationEditor/APIOrSaasPlugins.tsx (1)
Line range hint
117-125: Consider extracting plugin type determination logic.The inline ternary for determining plugin type could be extracted into a helper function for better readability.
+ const getPluginType = (source: string) => + source === API_ACTION.CREATE_NEW_GRAPHQL_API + ? PluginPackageName.GRAPHQL + : PluginPackageName.REST_API; props.createNewApiActionBasedOnIdeType( ideType, editorId, parentEntityId || (isOnboardingScreen && pageId) || "", parentEntityType, - source === API_ACTION.CREATE_NEW_GRAPHQL_API - ? PluginPackageName.GRAPHQL - : PluginPackageName.REST_API, + getPluginType(source), );
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (37)
app/client/src/PluginActionEditor/components/PluginActionResponse/components/DatasourceTab/DatasourceInfo.tsx(2 hunks)app/client/src/PluginActionEditor/components/PluginActionResponse/components/DatasourceTab/DatasourceTab.tsx(3 hunks)app/client/src/ce/IDE/hooks/useParentEntityInfo.ts(1 hunks)app/client/src/ce/actions/helpers.ts(3 hunks)app/client/src/ce/entities/IDE/constants.ts(1 hunks)app/client/src/ce/entities/IDE/utils.ts(2 hunks)app/client/src/ce/hooks/datasourceEditorHooks.tsx(3 hunks)app/client/src/ce/hooks/hooks.test.ts(0 hunks)app/client/src/ce/hooks/index.ts(0 hunks)app/client/src/ce/pages/Editor/IDE/EditorPane/Query/ActionEntity/index.tsx(1 hunks)app/client/src/ce/pages/Editor/IDE/EditorPane/Query/ListItem.tsx(1 hunks)app/client/src/ce/pages/Editor/IDE/EditorPane/Query/utils.ts(2 hunks)app/client/src/ce/pages/Editor/gitSync/useReconnectModalData.ts(2 hunks)app/client/src/ce/utils/BusinessFeatures/permissionPageHelpers.tsx(2 hunks)app/client/src/ce/utils/lintRulesHelpers.ts(1 hunks)app/client/src/ee/IDE/hooks/useParentEntityInfo.ts(1 hunks)app/client/src/ee/pages/Editor/IDE/EditorPane/Query/ActionEntity/index.tsx(1 hunks)app/client/src/pages/Editor/CustomWidgetBuilder/useCustomBuilder.tsx(2 hunks)app/client/src/pages/Editor/DataSourceEditor/DSFormHeader.tsx(3 hunks)app/client/src/pages/Editor/DataSourceEditor/hooks.ts(3 hunks)app/client/src/pages/Editor/DatasourceInfo/DatasourceStructure.tsx(2 hunks)app/client/src/pages/Editor/DatasourceInfo/DatasourceViewModeSchema.tsx(3 hunks)app/client/src/pages/Editor/DatasourceInfo/GoogleSheetSchema.tsx(3 hunks)app/client/src/pages/Editor/Explorer/Actions/ActionEntity.tsx(3 hunks)app/client/src/pages/Editor/Explorer/Files/index.tsx(0 hunks)app/client/src/pages/Editor/IDE/EditorPane/Query/ActionEntity/QueryEntity.tsx(1 hunks)app/client/src/pages/Editor/IDE/EditorPane/Query/ActionEntity/QueryEntityContextMenu.tsx(1 hunks)app/client/src/pages/Editor/IDE/EditorPane/Query/List.tsx(4 hunks)app/client/src/pages/Editor/IDE/LeftPane/DataSidePane.tsx(2 hunks)app/client/src/pages/Editor/IDE/hooks.ts(2 hunks)app/client/src/pages/Editor/IntegrationEditor/APIOrSaasPlugins.tsx(6 hunks)app/client/src/pages/Editor/IntegrationEditor/DBOrMostPopularPlugins.tsx(9 hunks)app/client/src/pages/Editor/IntegrationEditor/DatasourceCard.tsx(3 hunks)app/client/src/pages/Editor/gitSync/ReconnectDatasourceModal.tsx(2 hunks)app/client/src/plugins/Linting/constants.ts(3 hunks)app/client/src/plugins/Linting/tests/generateLintingGlobalData.test.ts(0 hunks)app/client/src/plugins/Linting/utils/getLintingErrors.ts(5 hunks)
💤 Files with no reviewable changes (4)
- app/client/src/ce/hooks/hooks.test.ts
- app/client/src/pages/Editor/Explorer/Files/index.tsx
- app/client/src/plugins/Linting/tests/generateLintingGlobalData.test.ts
- app/client/src/ce/hooks/index.ts
✅ Files skipped from review due to trivial changes (3)
- app/client/src/ee/pages/Editor/IDE/EditorPane/Query/ActionEntity/index.tsx
- app/client/src/ee/IDE/hooks/useParentEntityInfo.ts
- app/client/src/pages/Editor/gitSync/ReconnectDatasourceModal.tsx
⏰ Context from checks skipped due to timeout of 90000ms (5)
- GitHub Check: client-unit-tests / client-unit-tests
- GitHub Check: client-lint / client-lint
- GitHub Check: client-build / client-build
- GitHub Check: client-check-cyclic-deps / check-cyclic-dependencies
- GitHub Check: client-prettier / prettier-check
🔇 Additional comments (27)
app/client/src/ce/pages/Editor/gitSync/useReconnectModalData.ts (2)
1-1: LGTM! Clean import of IDE_TYPE constant.The import from the enterprise edition constants maintains good separation of concerns.
39-39: Verify the IDE_TYPE.App usage across the codebase.The change from EditorNames to IDE_TYPE is consistent with the PR's objective. Let's verify other usages to ensure consistency.
✅ Verification successful
Migration to IDE_TYPE.App is complete and consistent
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for any remaining EditorNames.APPLICATION usage that should be migrated rg "EditorNames.APPLICATION" # Verify consistent usage of IDE_TYPE.App rg "IDE_TYPE.App"Length of output: 1755
app/client/src/pages/Editor/IntegrationEditor/DBOrMostPopularPlugins.tsx (4)
30-30: LGTM! Clean import restructuring.The imports reflect a well-structured transition from editor-type to IDE-type based architecture.
Also applies to: 41-41, 53-54
189-198: LGTM! Consistent prop propagation.The IDE type changes are consistently propagated through the component hierarchy.
Also applies to: 287-287
Line range hint
348-363: LGTM! Consistent Redux integration.The dispatch mapping correctly implements the new action creator signature.
257-259: Verify hook usage and dependencies.The transition to
getIDETypeByUrlanduseParentEntityInfolooks good. Let's verify the hook's usage pattern.✅ Verification successful
✓ Hook usage verification completed successfully
The transition from
useEditorTypetouseParentEntityInfois complete and consistent across all components.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for any remaining useEditorType usage rg -g '*.{ts,tsx}' 'useEditorType' # Verify consistent useParentEntityInfo usage rg -g '*.{ts,tsx}' 'useParentEntityInfo.*ideType'Length of output: 1116
app/client/src/ce/utils/lintRulesHelpers.ts (1)
Line range hint
3-17: Verify the empty implementation of getLintRulesBasedOnContext.The function returns an empty object despite accepting a ContextType parameter. This might indicate incomplete implementation or missing logic after the type change.
✅ Verification successful
Empty implementation is correct as this is the CE (Community Edition) version
The empty implementation in the CE version is intentional, as the actual rules are defined in the Enterprise Edition (ee/utils/lintRulesHelpers). This follows the standard CE/EE split pattern.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for usages of getLintRulesBasedOnContext to understand expected behavior rg -A 3 "getLintRulesBasedOnContext"Length of output: 1293
app/client/src/PluginActionEditor/components/PluginActionResponse/components/DatasourceTab/DatasourceInfo.tsx (1)
28-29: LGTM! The transition to IDE-type looks good.The change from
useEditorTypetogetIDETypeByUrlaligns with the PR's objective of standardizing IDE-type usage.app/client/src/ce/actions/helpers.ts (1)
Line range hint
67-85: Address TODO comment and improve type safety.The function has a TODO comment and returns
anytype. Consider addressing both issues.export const createNewApiActionBasedOnIdeType = ( ideType: IDEType, editorId: string, parentEntityId: string, parentEntityType: ActionParentEntityTypeInterface, apiType: string, - // TODO: Fix this the next time the file is edited - // eslint-disable-next-line @typescript-eslint/no-explicit-any -): any => { +): ReturnType<typeof createNewAPIBasedOnParentEntity> => { if (parentEntityId) { return createNewAPIBasedOnParentEntity( parentEntityId, "API_PANE", apiType, parentEntityType, ); } + return undefined; };app/client/src/pages/Editor/IDE/EditorPane/Query/List.tsx (2)
55-57: LGTM! Feature flag implementation follows best practices.The feature flag is appropriately used to control the rollout of the new EntityGroupsList component.
78-93: Well-structured component composition with proper type safety.The EntityGroupsList implementation provides better type safety and cleaner separation of concerns.
app/client/src/pages/Editor/DataSourceEditor/hooks.ts (1)
Line range hint
144-154: Verify permission checks with new IDE type system.The switch from editorType to ideType affects permission checks. Please ensure all permission scenarios are tested.
✅ Verification successful
Permission checks with IDE type system verified successfully
The permission system correctly handles different IDE types with appropriate permission checks for each context.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for all permission check usages with the new IDE type rg -A 3 "hasCreateDSActionPermissionInApp.*ideType"Length of output: 53
Script:
#!/bin/bash # Find the function definition ast-grep --pattern 'export function hasCreateDSActionPermissionInApp($_) { $$$ }' # Search for IDE type related code rg -A 2 "getIDETypeByUrl|ideType.*=.*getIDEType" # Broader search for the permission function rg "hasCreateDSActionPermissionInApp"Length of output: 18916
Script:
#!/bin/bash # Get the implementation of hasCreateDSActionPermissionInApp ast-grep --pattern 'export const hasCreateDSActionPermissionInApp = $_' # Also check for any IDE type constants that might be used in the implementation rg -A 5 "IDE_TYPE.*=.*{"Length of output: 78325
app/client/src/pages/Editor/IDE/LeftPane/DataSidePane.tsx (1)
62-63: LGTM! Consistent usage of IDE type system.The dsUsageSelector update maintains consistency with the new IDE type pattern.
app/client/src/pages/Editor/CustomWidgetBuilder/useCustomBuilder.tsx (1)
32-33: LGTM! Clean hook implementation with IDE type.The useParentEntityInfo hook is correctly updated to use the new IDE type system.
app/client/src/pages/Editor/DataSourceEditor/DSFormHeader.tsx (2)
30-30: LGTM! Clean transition from editor type to IDE type.The refactoring from
useEditorTypetogetIDETypeByUrlmaintains the component's functionality while improving type safety.Also applies to: 120-120
168-168: LGTM! Updated hook usage.The
useHeaderActionshook is correctly updated to use the newideTypeparameter.app/client/src/PluginActionEditor/components/PluginActionResponse/components/DatasourceTab/DatasourceTab.tsx (1)
26-26: LGTM! Consistent refactoring to IDE types.The changes align with the codebase-wide transition from editor types to IDE types, improving type safety without affecting functionality.
Also applies to: 36-36, 61-62
app/client/src/plugins/Linting/constants.ts (2)
46-46: LGTM! Updated context parameter.The
getLintRulesBasedOnContextcall correctly uses the newideTypeparameter.
6-6: Verify the impact of the type change.The parameter type change from
stringtoIDETypeimproves type safety but may affect existing callers oflintOptions.Also applies to: 16-16
✅ Verification successful
Type change verification completed - No issues found.
The change from
stringtoIDETypeis safe as the only caller ingetLintingErrors.tsalready uses the correct type throughgetIDETypeByUrlandIDE_TYPE.App.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for all calls to lintOptions to verify they pass the correct type rg -A 2 "lintOptions\("Length of output: 277
Script:
#!/bin/bash # Find lintOptions implementation ast-grep --pattern 'const lintOptions = $_' # Find IDEType definition ast-grep --pattern 'type IDEType = $_' # Check the file where lintOptions is used cat app/client/src/plugins/Linting/utils/getLintingErrors.tsLength of output: 82735
Script:
#!/bin/bash # Find IDEType definition and usages rg "IDEType" -A 3 # Find getLintRulesBasedOnContext implementation rg "getLintRulesBasedOnContext" -A 3Length of output: 33527
app/client/src/pages/Editor/IDE/hooks.ts (1)
30-30: LGTM! Consistent IDE type usage.The changes in
useSegmentNavigationmaintain the same functionality while adopting the new IDE type system.Also applies to: 34-34, 66-67
app/client/src/ce/utils/BusinessFeatures/permissionPageHelpers.tsx (1)
46-46: LGTM! Type safety improvement.The transition from string-based editorType to strongly-typed IDEType enhances type safety and maintainability.
Also applies to: 96-96
app/client/src/pages/Editor/DatasourceInfo/DatasourceViewModeSchema.tsx (1)
Line range hint
85-96: LGTM! Clean transition to IDE-type.The change from editorType to ideType is clean and maintains the existing functionality.
app/client/src/pages/Editor/IntegrationEditor/APIOrSaasPlugins.tsx (1)
Line range hint
65-71: LGTM! Well-typed function signature.The createNewApiActionBasedOnIdeType function signature is well-defined with proper typing.
app/client/src/pages/Editor/IntegrationEditor/DatasourceCard.tsx (1)
63-63: LGTM! Clean transition from editor-type to IDE-type.The changes correctly implement the new IDE-type based approach while maintaining the component's functionality.
Also applies to: 182-182, 193-193
app/client/src/pages/Editor/DatasourceInfo/GoogleSheetSchema.tsx (1)
Line range hint
24-24: LGTM! Consistent implementation of IDE-type transition.The changes align with the codebase-wide refactoring from editor-type to IDE-type.
Also applies to: 69-69, 75-75
app/client/src/plugins/Linting/utils/getLintingErrors.ts (1)
48-49: LGTM! Proper integration of IDE-type in linting context.The changes correctly integrate the IDE-type concept into the linting process while maintaining the existing error handling functionality.
Also applies to: 84-84, 143-143, 160-160, 376-376, 381-381
app/client/src/pages/Editor/DatasourceInfo/DatasourceStructure.tsx (1)
24-24: LGTM! Consistent implementation of IDE-type transition.The changes follow the established pattern of transitioning from editor-type to IDE-type.
Also applies to: 69-69, 75-75
app/client/src/pages/Editor/IntegrationEditor/DBOrMostPopularPlugins.tsx
Show resolved
Hide resolved
app/client/src/pages/Editor/IDE/EditorPane/Query/ActionEntity/QueryEntityContextMenu.tsx
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (5)
app/client/src/pages/Editor/IDE/EditorPane/Query/ListItem/QueryEntityItem.tsx (2)
39-46: Consider memoizing selector results.Multiple useSelector calls could benefit from memoization to prevent unnecessary re-renders.
+const selectAction = useCallback( + (state: AppState) => getActionByBaseId(state, item.key), + [item.key] +); +const action = useSelector(selectAction) as Action; +const selectDatasource = useCallback( + (state) => getDatasource(state, action?.datasource?.id), + [action?.datasource?.id] +); +const datasource = useSelector(selectDatasource) as Datasource;
79-94: Consider extracting analytics logic.The switchToAction callback handles both navigation and analytics. Consider separating these concerns for better maintainability.
+const logAnalytics = useCallback((url: string) => { + AnalyticsUtil.logEvent("ENTITY_EXPLORER_CLICK", { + type: "QUERIES/APIs", + fromUrl: location.pathname, + toUrl: url, + name: action.name, + }); + AnalyticsUtil.logEvent("EDIT_ACTION_CLICK", { + actionId: action?.id, + datasourceId: datasource?.id, + pluginName: pluginGroups[action?.pluginId]?.name, + actionType: action?.pluginType === PluginType.DB ? "Query" : "API", + isMock: !!datasource?.isMock, + }); +}, [location.pathname, action, datasource, pluginGroups]); const switchToAction = useCallback(() => { url && history.push(url, { invokedBy: NavigationMethod.EntityExplorer }); - AnalyticsUtil.logEvent... + logAnalytics(url); }, [url, logAnalytics]);app/client/src/pages/Editor/IDE/EditorPane/Query/List.tsx (2)
78-129: Consider extracting the group rendering logic.The conditional rendering creates duplicate group structure logic. Consider extracting this into a separate component.
+const GroupRenderer = ({ group, items, isNewTemplate, parentEntityId }) => { + if (isNewTemplate) { + return ( + <ActionEntityItem + item={items} + parentEntityId={parentEntityId} + /> + ); + } + return ( + <QueryListItem + isActive={items.key === activeActionBaseId} + item={items} + parentEntityId={parentEntityId} + /> + ); +};
55-57: Document the feature flag's purpose.Add a comment explaining what this feature flag controls and its implications.
+// Controls the rollout of new ADS templates for entity rendering +// When enabled, uses EntityGroupsList for improved list organization const isNewADSTemplatesEnabled = useFeatureFlag( FEATURE_FLAG.release_ads_entity_item_enabled, );app/client/src/pages/Editor/IDE/EditorPane/Query/ListItem/QueryEntityContextMenu.tsx (1)
132-153: Document IDE-specific copy behavior.The copy functionality differs between App and other IDE types. Consider adding a comment explaining this distinction for better maintainability.
+ // In App IDE, copy shows a submenu of pages + // In other IDE types, it performs an immediate duplicate action menuItems.includes(ActionEntityContextMenuItemsEnum.COPY) &&
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (8)
app/client/src/ce/pages/Editor/IDE/EditorPane/Query/ListItem/index.tsx(1 hunks)app/client/src/ce/pages/Editor/IDE/EditorPane/Query/ListItem/old/ListItem.tsx(1 hunks)app/client/src/ce/selectors/entitiesSelector.ts(2 hunks)app/client/src/ee/pages/Editor/IDE/EditorPane/Query/ListItem/old/ListItem.tsx(1 hunks)app/client/src/pages/Editor/IDE/EditorPane/Query/List.tsx(3 hunks)app/client/src/pages/Editor/IDE/EditorPane/Query/ListItem/QueryEntityContextMenu.tsx(1 hunks)app/client/src/pages/Editor/IDE/EditorPane/Query/ListItem/QueryEntityItem.tsx(1 hunks)app/client/src/pages/Editor/IDE/LeftPane/DataSidePane.tsx(2 hunks)
✅ Files skipped from review due to trivial changes (1)
- app/client/src/ee/pages/Editor/IDE/EditorPane/Query/ListItem/old/ListItem.tsx
⏰ Context from checks skipped due to timeout of 90000ms (5)
- GitHub Check: client-unit-tests / client-unit-tests
- GitHub Check: client-lint / client-lint
- GitHub Check: client-check-cyclic-deps / check-cyclic-dependencies
- GitHub Check: client-build / client-build
- GitHub Check: client-prettier / prettier-check
🔇 Additional comments (10)
app/client/src/pages/Editor/IDE/LeftPane/DataSidePane.tsx (2)
33-33: LGTM! Clean import addition.The import of
getIDETypeByUrlaligns with the PR's objective of transitioning from editor type to IDE type.
62-64: LGTM! Clean transition to IDE type.The changes maintain proper React hooks usage order and successfully transition from editor type to IDE type.
Let's verify that all usages of
useEditorTypehave been replaced:✅ Verification successful
Verified: Clean transition to IDE type completed
The codebase shows no remaining instances of
useEditorTypeand demonstrates consistent usage ofgetIDETypeByUrlacross all relevant components. The implementation in DataSidePane.tsx follows the established pattern.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for any remaining instances of useEditorType rg "useEditorType" --type ts --type tsx # Verify consistent usage of getIDETypeByUrl rg "getIDETypeByUrl" --type ts --type tsxLength of output: 137
Script:
#!/bin/bash # Search for any remaining instances of useEditorType echo "=== Searching for useEditorType ===" rg "useEditorType" -g "*.{ts,tsx}" # Search for imports of useEditorType echo -e "\n=== Searching for useEditorType imports ===" rg "import.*useEditorType" -g "*.{ts,tsx}" # Verify consistent usage of getIDETypeByUrl echo -e "\n=== Searching for getIDETypeByUrl ===" rg "getIDETypeByUrl" -g "*.{ts,tsx}" # Search for imports of getIDETypeByUrl echo -e "\n=== Searching for getIDETypeByUrl imports ===" rg "import.*getIDETypeByUrl" -g "*.{ts,tsx}"Length of output: 10326
app/client/src/ce/pages/Editor/IDE/EditorPane/Query/ListItem/index.tsx (1)
5-10: Clean implementation of the adapter pattern!The
ActionEntityItemcomponent provides a good abstraction layer overQueryEntityItem, making future modifications easier to manage.app/client/src/ce/pages/Editor/IDE/EditorPane/Query/ListItem/old/ListItem.tsx (1)
12-12: Verify the impact of removing parentEntityType.The removal of parentEntityType from props destructuring aligns with the IDE type refactoring. However, let's verify all usages are updated.
✅ Verification successful
Removal of parentEntityType is verified as safe.
The prop removal is part of an intentional refactoring where the old implementation has been replaced with new versions in both CE and EE that explicitly exclude this prop.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for any remaining references to parentEntityType in action-related components rg -l 'parentEntityType.*ExplorerActionEntity' app/client/src/Length of output: 64
Script:
#!/bin/bash # Search for ListItem component usage rg -l "ListItem" app/client/src/ # Search for parentEntityType in broader context rg "parentEntityType" app/client/src/ # Find ExplorerActionEntity component definition ast-grep --pattern 'interface ExplorerActionEntityProps { $$$ }'Length of output: 9301
Script:
#!/bin/bash # Check new ListItem implementations cat app/client/src/ce/pages/Editor/IDE/EditorPane/Query/ListItem/index.tsx cat app/client/src/ee/pages/Editor/IDE/EditorPane/Query/ListItem/index.tsxLength of output: 539
app/client/src/ce/selectors/entitiesSelector.ts (2)
67-67: LGTM!The
IDETypetype import is correctly placed with other IDE-related type imports.
1705-1714: LGTM! Verify all call sites are updated.The changes improve type safety by replacing the generic string type with the specific
IDETypetype.Let's verify that all call sites have been updated to use the new type:
✅ Verification successful
Changes verified - parameter type change is properly implemented
The change from
editorType: stringtoideType: IDETypeis correctly implemented and all usages have been updated. The type is properly defined in the constants file and imported where needed.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for any remaining usage of the old parameter name rg -l "getDatasourceUsageCountForApp.*editorType" # Search for all current usages to verify they use the new parameter rg -l "getDatasourceUsageCountForApp.*ideType"Length of output: 100
Script:
#!/bin/bash # Search for any usage of the selector rg "getDatasourceUsageCountForApp" -A 2 # Search for any remaining editorType references in the same directory fd ".*\.ts$" app/client/src/ce/selectors -x rg "editorType" # Use AST to find selector usage ast-grep --pattern 'getDatasourceUsageCountForApp($$$)'Length of output: 67108
Script:
#!/bin/bash # Search for IDEType definition rg "type IDEType" -A 2 # Search for any remaining editorType in DataSidePane rg "editorType" app/client/src/pages/Editor/IDE/LeftPane/DataSidePane.tsx -A 2 # Get context of the selector usage in DataSidePane rg "dsUsageSelector" app/client/src/pages/Editor/IDE/LeftPane/DataSidePane.tsx -A 5Length of output: 2374
app/client/src/pages/Editor/IDE/EditorPane/Query/ListItem/QueryEntityContextMenu.tsx (4)
1-50: Clean and well-structured imports and interface definition!The imports are logically organized and the EntityContextMenuProps interface is well-defined with clear typing.
51-60: Well-implemented component setup with proper state management!The component correctly uses the new IDE type utilities and maintains clean state management.
200-207: Clean and efficient rendering logic!The conditional rendering and type handling are well-implemented.
84-89: Consider handling deletion failures.The delete action callback doesn't handle potential failures. Consider adding error handling to prevent navigation on failed deletions.
Description
Tip
Add a TL;DR when the description is longer than 500 words or extremely technical (helps the content, marketing, and DevRel team).
Please also include relevant motivation and context. List any dependencies that are required for this change. Add links to Notion, Figma or any other documents that might be relevant to the PR.
Fixes #
Issue Numberor
Fixes
Issue URLWarning
If no issue exists, please create an issue first, and check with the maintainers if the issue is valid.
Automation
/ok-to-test tags="@tag.All"
🔍 Cypress test results
Tip
🟢 🟢 🟢 All cypress tests have passed! 🎉 🎉 🎉
Workflow run: https://github.com/appsmithorg/appsmith/actions/runs/12833456820
Commit: 3f86ad9
Cypress dashboard.
Tags:
@tag.AllSpec:
Fri, 17 Jan 2025 19:10:08 UTC
Communication
Should the DevRel and Marketing teams inform users about this change?
Summary by CodeRabbit
Release Notes
New Features
ActionEntityItemcomponent for improved entity item rendering.QueryEntityContextMenucomponent for managing query entities.Improvements
Bug Fixes
Chores