refactor: editor code splitting #6102
Conversation
WalkthroughThe changes in this pull request primarily focus on enhancing the editor's functionality by introducing a new property, Changes
Possibly related PRs
Suggested reviewers
Warning Rate limit exceeded@aaryan610 has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 12 minutes and 13 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 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
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 14
🧹 Outside diff range and nitpick comments (24)
packages/editor/src/core/types/extensions.ts (1)
1-1: Consider adding JSDoc documentation for the callout extension.To maintain code clarity, consider adding documentation describing the purpose and behavior of the new callout extension.
Add documentation like this:
+/** + * Available editor extensions. + * - ai: AI-powered assistance features + * - collaboration-cursor: Real-time collaboration cursors + * - issue-embed: GitHub issue embedding + * - slash-commands: Slash command palette + * - enter-key: Custom enter key behavior + * - callout: Callout blocks for highlighting content + */ export type TExtensions = "ai" | "collaboration-cursor" | "issue-embed" | "slash-commands" | "enter-key" | "callout";packages/editor/src/ce/extensions/core/extensions.ts (1)
5-7: Consider using a more specific type nameThe type name
Propsis quite generic. Consider renaming it to something more specific likeCoreEditorExtensionPropsorExtensionConfigPropsto better indicate its purpose and scope.-type Props = { +type CoreEditorExtensionProps = { disabledExtensions: TExtensions[]; };packages/editor/src/ce/extensions/slash-commands.tsx (2)
6-8: Add JSDoc documentation for the Props type.Consider adding documentation to explain the purpose and usage of this type, especially how the
disabledExtensionsarray affects the slash commands.+/** + * Props for configuring slash command options + * @property disabledExtensions - Array of extensions to be disabled in the editor + */ type Props = { disabledExtensions: TExtensions[]; };
1-14: Consider documenting the code splitting strategy.This file introduces a new extension point for slash commands as part of the editor code splitting effort. To maintain clarity and help future contributors:
- Consider adding a README.md in the extensions directory explaining:
- The overall code splitting strategy
- How to properly implement and register new slash commands
- The relationship between disabled extensions and available commands
Would you like me to help create this documentation?
🧰 Tools
🪛 Biome (1.9.4)
[error] 11-11: Unexpected empty object pattern.
(lint/correctness/noEmptyPattern)
packages/editor/src/ce/extensions/document-extensions.tsx (1)
18-24: Consider a more scalable approach for extension initialization.The current implementation handles slash commands well, but as more extensions are added in the future, the pattern of checking each extension individually might become harder to maintain.
Consider refactoring to a more maintainable pattern:
- const extensions: Extensions = disabledExtensions?.includes("slash-commands") - ? [] - : [ - SlashCommands({ - disabledExtensions, - }), - ]; + const availableExtensions = { + "slash-commands": () => + SlashCommands({ + disabledExtensions, + }), + // future extensions can be added here + }; + + const extensions: Extensions = Object.entries(availableExtensions) + .filter(([name]) => !disabledExtensions?.includes(name)) + .map(([_, init]) => init());This approach:
- Makes it easier to add new extensions
- Keeps the disabled extensions logic consistent
- Improves code maintainability
packages/editor/src/core/components/editors/read-only-editor-wrapper.tsx (1)
15-15: Consider adding validation and documentation for disabledExtensions.Since this property affects editor functionality, it would be helpful to:
- Add JSDoc comments explaining which extensions can be disabled and their impact
- Consider adding runtime validation to prevent disabling critical extensions
+ /** Properties for the read-only editor wrapper + * @property {string[]} disabledExtensions - List of extension names to disable. + * Valid values include: [list the valid extension names here] + */ export const ReadOnlyEditorWrapper = (props: IReadOnlyEditorProps) => { const { containerClassName, disabledExtensions,packages/editor/src/core/components/editors/rich-text/editor.tsx (1)
22-26: Consider improving extension configuration maintainabilityA few suggestions to enhance maintainability and type safety:
- Consider extracting "slash-commands" into a constant or enum to prevent typos and enable better refactoring.
- Consider creating a dedicated type for the extension configuration instead of passing the full
disabledExtensionsarray.Example refactor:
+ const EXTENSION_NAMES = { + SLASH_COMMANDS: 'slash-commands' + } as const; + + type SlashCommandsConfig = { + // Add only the specific extension flags needed by SlashCommands + disabledSubFeatures?: string[]; + }; if (!disabledExtensions?.includes(EXTENSION_NAMES.SLASH_COMMANDS)) { extensions.push( SlashCommands({ - disabledExtensions, + disabledSubFeatures: disabledExtensions, }) ); }web/core/components/editor/rich-text-editor/rich-text-read-only-editor.tsx (1)
23-24: Consider adding error handling for undefined workspace slug.While the implementation is correct, consider adding error handling or default values for cases where
workspaceSlugmight be undefined.- const { richTextEditor: disabledExtensions } = useEditorFlagging(workspaceSlug?.toString()); + const { richTextEditor: disabledExtensions } = useEditorFlagging(workspaceSlug?.toString() ?? '');web/core/components/editor/rich-text-editor/rich-text-editor.tsx (2)
31-32: Consider adding error handling for undefined workspaceSlugThe hook usage looks good, but there's a potential edge case with
workspaceSlug?.toString(). While the optional chaining prevents runtime errors, we should ensure the component handles undefined workspace scenarios gracefully.- const { richTextEditor: disabledExtensions } = useEditorFlagging(workspaceSlug?.toString()); + const { richTextEditor: disabledExtensions } = useEditorFlagging(workspaceSlug?.toString() ?? '');
Line range hint
1-63: Consider documenting the disabledExtensions functionalityWhile the implementation is solid, adding JSDoc comments explaining the purpose and behavior of the
disabledExtensionsfeature would improve maintainability.+/** + * RichTextEditor wrapper component that handles workspace-specific editor configurations + * including extension flagging, file handling, and mention suggestions. + * @property {string[]} disabledExtensions - List of extensions to be disabled based on workspace settings + */ export const RichTextEditor = forwardRef<EditorRefApi, RichTextEditorWrapperProps>((props, ref) => {packages/editor/src/core/components/editors/document/read-only-editor.tsx (2)
16-16: Add JSDoc documentation for the new propertyConsider adding JSDoc documentation to explain the purpose and expected values of the
disabledExtensionsproperty. This would help other developers understand how to use this feature correctly.+ /** Array of extensions that should be disabled in the editor */ disabledExtensions: TExtensions[];
35-35: Consider memoization for performance optimizationSince changing
disabledExtensionscould trigger re-renders, consider usinguseMemofor the extensions array anduseCallbackfor any functions that depend ondisabledExtensions.const extensions = []; + const memoizedExtensions = useMemo(() => { if (embedHandler?.issue) { - extensions.push( + return [ IssueWidget({ widgetCallback: embedHandler.issue.widgetCallback, }) - ); + ]; } + return []; + }, [embedHandler?.issue]);Also applies to: 56-56
packages/editor/src/core/hooks/use-read-only-collaborative-editor.ts (1)
Line range hint
74-82: Document the extension order importanceConsider adding a comment to document the order of extensions and its significance, especially how
disabledExtensionsinteracts with the extension chain.extensions: [ + // Order of extensions: + // 1. User-provided extensions (can be disabled via disabledExtensions) + // 2. Core extensions (HeadingListExtension) + // 3. Collaboration extension (required for real-time collaboration) ...(extensions ?? []), HeadingListExtension, Collaboration.configure({ document: provider.document, }), ],web/core/components/global/product-updates/modal.tsx (2)
62-62: LGTM! Consider adding documentation.The addition of
disabledExtensionsprop aligns with the refactoring objectives. However, it would be helpful to document which extensions can be disabled in this context.Consider adding a comment above the editor component explaining:
- Available extensions that can be disabled
- Impact of disabling specific extensions
- Default behavior with empty array
62-62: Consider making extensions configurable.Instead of hardcoding an empty array, consider making it configurable through props or configuration, allowing different instances of the modal to disable different extensions as needed.
- disabledExtensions={[]} + disabledExtensions={props.disabledExtensions ?? []}And update the props interface:
export type ProductUpdatesModalProps = { isOpen: boolean; handleClose: () => void; disabledExtensions?: string[]; };packages/editor/src/core/hooks/use-collaborative-editor.ts (2)
Line range hint
29-43: Consider enhancing WebSocket error handling robustnessThe current implementation only handles code 1006 (abnormal closure), but other WebSocket close codes might also indicate connection issues that should be handled.
Consider expanding the error handling:
onClose: (data) => { - if (data.event.code === 1006) { + // Handle various WebSocket close scenarios + if ([1001, 1006, 1011, 1012, 1015].includes(data.event.code)) { serverHandler?.onServerError?.(); setHasServerConnectionFailed(true); } + // Log the specific error for debugging + console.error(`WebSocket closed with code: ${data.event.code}`); },
Line range hint
33-34: Review token security implementationUsing
JSON.stringify(user)as a token might expose sensitive user information. Consider using a more secure authentication method.Recommendations:
- Use a proper JWT or session token instead of the entire user object
- Ensure the token contains only necessary identification information
- Consider implementing token expiration and refresh mechanisms
packages/editor/src/core/extensions/read-only-extensions.tsx (1)
36-36: Consider adding JSDoc documentationIt would be helpful to add JSDoc documentation explaining the purpose and expected values of
disabledExtensions.+/** + * Array of extensions to disable in the editor. + * @type {TExtensions[]} + */ disabledExtensions: TExtensions[];web/core/components/editor/lite-text-editor/lite-text-editor.tsx (1)
Line range hint
20-79: Consider adding architectural documentation.This refactor moves extension control to a centralized hook, which is a good architectural decision. Consider adding a comment or documentation explaining the rationale behind this pattern, especially since it's part of a larger code splitting effort.
web/core/components/pages/version/editor.tsx (1)
Line range hint
15-107: Consider documenting extension configurationThe addition of editor extension configuration enhances modularity but would benefit from documentation. Consider:
- Adding JSDoc comments explaining the purpose and impact of disabled extensions
- Creating a README section about editor extension configuration
- Adding examples of common extension configurations
This will help maintain the code-splitting benefits while ensuring proper usage across the codebase.
packages/editor/src/core/extensions/extensions.tsx (1)
40-40: Add JSDoc documentation for the disabledExtensions propertyPlease add documentation explaining:
- Which extensions can be disabled
- The implications of disabling specific extensions
- Any dependencies between extensions that should be considered
Example:
type TArguments = { + /** + * Array of extensions to disable in the editor. + * @example ['bulletList', 'orderedList'] + * Note: Disabling certain extensions may affect dependent features. + */ disabledExtensions: TExtensions[];packages/editor/src/core/hooks/use-editor.ts (2)
32-32: Add JSDoc comment to document the disabledExtensions propertyConsider adding documentation to explain the purpose and expected values of this property. This will help other developers understand how to use it correctly.
Example:
+ /** Array of extension identifiers that should be disabled in the editor */ disabledExtensions: TExtensions[];
Line range hint
1-270: Consider documenting the code splitting strategyThe addition of
disabledExtensionsis a good step towards modular editor configuration. However, consider adding documentation (either in code or README) that explains:
- The overall code splitting strategy
- How to determine which extensions can be safely disabled
- The impact of disabling specific extensions on editor functionality
This will help maintainers understand the architectural decisions and trade-offs.
packages/editor/src/core/extensions/slash-commands/command-items-list.tsx (1)
281-286: Remove unnecessary optional chaining onforEachThe optional chaining operator
?.is unnecessary when callingforEachon an array that is guaranteed to be defined. Since the array is constructed and cannot benullorundefined, you can safely remove?.to simplify the code.Apply this diff to simplify the code:
[ ...(additionalOptions ?? []), ...coreEditorAdditionalSlashCommandOptions({ disabledExtensions, }), ] - ?.forEach((item) => { + .forEach((item) => { const sectionToPushTo = SLASH_COMMAND_SECTIONS.find((s) => s.key === item.section) ?? SLASH_COMMAND_SECTIONS[0]; const itemIndexToPushAfter = sectionToPushTo.items.findIndex((i) => i.commandKey === item.pushAfter); if (itemIndexToPushAfter !== undefined) { const resolvedIndex = itemIndexToPushAfter + 1 < sectionToPushTo.items.length ? itemIndexToPushAfter + 1 : sectionToPushTo.items.length - 1; sectionToPushTo.items.splice(resolvedIndex, 0, item); } else { sectionToPushTo.items.push(item); } });
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (33)
packages/editor/src/ce/extensions/core/extensions.ts(1 hunks)packages/editor/src/ce/extensions/core/read-only-extensions.ts(1 hunks)packages/editor/src/ce/extensions/document-extensions.tsx(1 hunks)packages/editor/src/ce/extensions/index.ts(1 hunks)packages/editor/src/ce/extensions/slash-commands.tsx(1 hunks)packages/editor/src/core/components/editors/document/collaborative-read-only-editor.tsx(2 hunks)packages/editor/src/core/components/editors/document/read-only-editor.tsx(3 hunks)packages/editor/src/core/components/editors/editor-wrapper.tsx(2 hunks)packages/editor/src/core/components/editors/read-only-editor-wrapper.tsx(2 hunks)packages/editor/src/core/components/editors/rich-text/editor.tsx(2 hunks)packages/editor/src/core/extensions/extensions.tsx(3 hunks)packages/editor/src/core/extensions/read-only-extensions.tsx(2 hunks)packages/editor/src/core/extensions/slash-commands/command-items-list.tsx(3 hunks)packages/editor/src/core/extensions/slash-commands/root.tsx(2 hunks)packages/editor/src/core/hooks/use-collaborative-editor.ts(1 hunks)packages/editor/src/core/hooks/use-editor.ts(3 hunks)packages/editor/src/core/hooks/use-read-only-collaborative-editor.ts(2 hunks)packages/editor/src/core/hooks/use-read-only-editor.ts(3 hunks)packages/editor/src/core/types/collaboration.ts(1 hunks)packages/editor/src/core/types/editor.ts(2 hunks)packages/editor/src/core/types/extensions.ts(1 hunks)space/core/components/editor/lite-text-editor.tsx(2 hunks)space/core/components/editor/lite-text-read-only-editor.tsx(2 hunks)space/core/components/editor/rich-text-editor.tsx(2 hunks)space/core/components/editor/rich-text-read-only-editor.tsx(2 hunks)web/ce/hooks/use-editor-flagging.ts(1 hunks)web/core/components/editor/lite-text-editor/lite-text-editor.tsx(3 hunks)web/core/components/editor/lite-text-editor/lite-text-read-only-editor.tsx(2 hunks)web/core/components/editor/rich-text-editor/rich-text-editor.tsx(3 hunks)web/core/components/editor/rich-text-editor/rich-text-read-only-editor.tsx(1 hunks)web/core/components/global/product-updates/modal.tsx(1 hunks)web/core/components/pages/editor/editor-body.tsx(3 hunks)web/core/components/pages/version/editor.tsx(3 hunks)
🧰 Additional context used
🪛 Biome (1.9.4)
packages/editor/src/ce/extensions/core/extensions.ts
[error] 10-10: Unexpected empty object pattern.
(lint/correctness/noEmptyPattern)
packages/editor/src/ce/extensions/core/read-only-extensions.ts
[error] 10-10: Unexpected empty object pattern.
(lint/correctness/noEmptyPattern)
packages/editor/src/ce/extensions/slash-commands.tsx
[error] 11-11: Unexpected empty object pattern.
(lint/correctness/noEmptyPattern)
🔇 Additional comments (64)
packages/editor/src/ce/extensions/index.ts (2)
3-3: LGTM! Clean barrel file export.
The new export follows the established pattern in the file and aligns with the code splitting objectives.
3-3: Verify downstream usage of slash commands.
Since this export makes slash commands functionality available at the package level, let's verify the impact on existing consumers.
✅ Verification successful
Let me gather more information to verify the impact of the export change.
Let me try one more search to verify the imports and exports.
Based on the previous results, I can generate the final response:
The slash commands export change appears safe to proceed.
The codebase analysis shows that the SlashCommands component is already being imported through the @/extensions path in multiple files:
- packages/editor/src/core/components/editors/rich-text/editor.tsx
- packages/editor/src/ce/extensions/document-extensions.tsx
This indicates that consumers are already using the barrel export pattern, making this export change in packages/editor/src/ce/extensions/index.ts a safe addition that aligns with existing usage.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for existing imports of slash-commands to ensure they're updated
# to use the new barrel export if needed
# Search for direct imports of slash-commands
echo "Checking for direct imports of slash-commands:"
rg -l "from ['\"].*\/slash-commands['\"]" --type ts --type tsx
# Search for usage of slash commands related symbols
echo -e "\nChecking for usage of slash commands functionality:"
ast-grep --pattern 'SlashCommands'
Length of output: 970
Script:
#!/bin/bash
# Check the actual content of the slash-commands directory and its exports
echo "Checking slash-commands directory content:"
fd . "packages/editor/src" -t f -e ts -e tsx | grep -i "slash.*command" | xargs cat
# Check if there are any other imports from the extensions directory
echo -e "\nChecking other imports from extensions directory:"
rg "from.*@/extensions" --type ts --type tsx -A 1
Length of output: 20904
Script:
#!/bin/bash
# Check the actual exports from the slash-commands directory
echo "Checking exports from slash-commands:"
rg "export.*from.*slash-commands" --type ts --type tsx
# Check the actual imports using the @/extensions path
echo -e "\nChecking imports using @/extensions:"
rg "import.*@/extensions" --type ts --type tsx
Length of output: 335
packages/editor/src/core/types/extensions.ts (1)
1-1: LGTM! Verify exhaustive handling of the new extension type.
The addition of "callout" to TExtensions follows the established pattern. However, we should ensure all consumers properly handle this new type.
Let's verify the usage and handling of extensions across the codebase:
✅ Verification successful
Let me gather more specific information about the callout extension and its handling.
Let me check one more aspect focusing on the extension handling and configuration.
Based on the gathered information, I can now provide the final response:
The addition of "callout" extension type is safe and properly handled.
The codebase follows a flexible pattern for handling extensions where:
- Extensions are managed through the
disabledExtensionsprop which is properly typed and passed down through component hierarchies - Extension handling is implemented through feature flags and conditional inclusion rather than exhaustive switches
- No hardcoded arrays of extensions were found that would need updates
The implementation allows for graceful addition of new extension types without requiring changes to existing switch statements or exhaustive checks.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for switch statements and extension handling that might need updates
# Find switch statements operating on TExtensions
ast-grep --pattern 'switch ($value) {
$$$
}'
# Find arrays or objects that might contain hardcoded extension lists
rg -A 2 "TExtensions\[\]|Array<TExtensions>|disabledExtensions"
# Look for potential documentation of extensions
fd -g "*.md" -X rg -l "extensions|callout"
Length of output: 21779
Script:
#!/bin/bash
# Check for callout-related code and configurations
rg -A 5 "callout" --type ts --type tsx
# Look for extension initialization or configuration
ast-grep --pattern 'const extensions = [
$$$
]'
# Check for any switch statements or conditionals specifically handling extensions
ast-grep --pattern 'if ($value?.includes($extension)) {
$$$
}'
Length of output: 1152
Script:
#!/bin/bash
# Search for extension configuration and initialization
rg -A 5 "TExtensions" --type ts --type tsx
# Look for any extension-related configuration or feature flags
ast-grep --pattern 'export const $config = {
$$$
}'
# Check for any extension-specific components or handlers
fd -e ts -e tsx -X rg -l "callout|extension"
Length of output: 3785
packages/editor/src/ce/extensions/core/extensions.ts (1)
9-12: Verify implementation completeness
The function accepts disabledExtensions but doesn't use it to filter any extensions. This seems incomplete given the PR's objective of supporting extension disabling.
Let's check if there are any extensions that should be filtered:
✅ Verification successful
Empty extension array is correct for this component
The implementation is correct as is. The CoreEditorAdditionalExtensions function is meant to be a hook point for optional extensions, and currently, it's designed to return an empty array. The disabledExtensions prop is properly passed through from the parent component (CoreEditorExtensions), but there are no additional extensions to filter at this level.
The available extensions that can be disabled (TExtensions) are: "ai", "collaboration-cursor", "issue-embed", "slash-commands", "enter-key", and "callout". These extensions are handled elsewhere in the codebase, not in this particular component.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for extension definitions in the codebase
ast-grep --pattern 'export const $_ = Extension.create({
$$$
})'
# Search for extension imports
rg -l "from '@tiptap/extension-"
Length of output: 9414
Script:
#!/bin/bash
# Let's check the imports and extensions in the specific file and its related files
rg -A 5 "CoreEditorAdditionalExtensions" packages/editor/
# Check for extension-related imports in the editor directory
rg "import.*from '@tiptap/extension-" packages/editor/
# Check for any other extension arrays or configurations
rg "Extensions\[\]" packages/editor/
Length of output: 3706
Script:
#!/bin/bash
# Let's check the implementation of the parent component that uses CoreEditorAdditionalExtensions
cat packages/editor/src/core/extensions/extensions.tsx
# Let's also check what extensions are available in the codebase
rg "TExtensions = " packages/editor/
Length of output: 5007
🧰 Tools
🪛 Biome (1.9.4)
[error] 10-10: Unexpected empty object pattern.
(lint/correctness/noEmptyPattern)
packages/editor/src/ce/extensions/core/read-only-extensions.ts (2)
1-3: LGTM!
Imports are well-organized and all are being used in the code.
5-7: LGTM!
The Props type is well-defined with a clear and descriptive property name.
packages/editor/src/ce/extensions/slash-commands.tsx (2)
1-4: LGTM! Clean and well-organized imports.
10-14: 🛠️ Refactor suggestion
Function implementation needs attention.
- The empty object destructuring is unnecessary
- The function doesn't utilize the
disabledExtensionsprop - Missing implementation for slash command options
Consider this implementation:
+/**
+ * Generates additional slash command options for the core editor
+ * @param props - Configuration props including disabled extensions
+ * @returns Array of additional slash command options
+ */
export const coreEditorAdditionalSlashCommandOptions = (props: Props): TSlashCommandAdditionalOption[] => {
- const {} = props;
+ const { disabledExtensions } = props;
const options: TSlashCommandAdditionalOption[] = [];
+
+ // Add slash command options based on enabled extensions
+ if (!disabledExtensions.includes("some-extension")) {
+ // Add relevant options
+ }
+
return options;
};Let's verify what extensions are available to implement:
🧰 Tools
🪛 Biome (1.9.4)
[error] 11-11: Unexpected empty object pattern.
(lint/correctness/noEmptyPattern)
web/ce/hooks/use-editor-flagging.ts (1)
7-9: Verify the usage of workspaceSlug parameter
The workspaceSlug parameter is added but not utilized in the implementation. This could indicate incomplete implementation or unnecessary parameter addition.
Let's verify the usage of this parameter in the codebase:
space/core/components/editor/rich-text-read-only-editor.tsx (2)
10-13: LGTM: Type definition properly updated for extension configuration
The type definition correctly includes "disabledExtensions" in the Omit type, allowing the component to properly type-check the extension configuration capability.
24-24:
Consider making disabledExtensions configurable instead of hardcoding
The hardcoded empty array disabledExtensions={[]} prevents parent components from configuring which extensions should be disabled. This seems to contradict the purpose of adding extension configuration support.
Consider this change:
- disabledExtensions={[]}
+ disabledExtensions={props.disabledExtensions}Let's verify if other components are expecting to configure this prop:
space/core/components/editor/lite-text-read-only-editor.tsx (1)
10-13: LGTM! Type definition changes look good.
The updated type definition correctly supports the new disabledExtensions property while maintaining type safety.
packages/editor/src/core/components/editors/read-only-editor-wrapper.tsx (1)
15-15: Implementation looks good, verify disabled extensions behavior.
The addition and forwarding of the disabledExtensions property is clean and follows the existing patterns. However, we should verify how the editor behaves when various extensions are disabled.
Also applies to: 26-26
✅ Verification successful
Let me try a different search strategy to understand the usage and behavior of disabledExtensions.
Let me check the implementation details of the extensions to understand how they're disabled.
Based on the implementation details, I can now provide a final response:
Implementation is safe and properly handles disabled extensions
The disabledExtensions property is correctly implemented and follows a well-defined pattern:
- It's properly typed as
TExtensions[]in the editor interfaces - It's forwarded to both core extensions and additional extensions through
CoreEditorExtensionsandCoreReadOnlyEditorExtensions - The extensions are configured with appropriate fallbacks and safety checks
- The property is consistently used across both editable and read-only editor variants
The implementation maintains editor stability by:
- Gracefully handling disabled extensions in both read-only and editable modes
- Preserving core editor functionality even when extensions are disabled
- Using a type-safe approach to extension management
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Find usage patterns of disabledExtensions to understand its impact
# Look for tests or documentation showing which extensions can be disabled
# Search for tests related to disabled extensions
echo "Searching for related test cases..."
rg -t typescript -t javascript "disabledExtensions.*test"
# Search for documentation or type definitions
echo "Searching for type definitions and documentation..."
ast-grep --pattern 'interface $interface {
$$$
disabledExtensions
$$$
}'
Length of output: 369
Script:
#!/bin/bash
# Search for disabledExtensions usage across the codebase
echo "Searching for disabledExtensions usage..."
rg "disabledExtensions" -l
# Search for editor extension related code
echo -e "\nSearching for editor extension patterns..."
rg "EditorExtension" -A 3
# Look for interface definitions containing disabledExtensions
echo -e "\nSearching for interface definitions..."
ast-grep --pattern 'interface $_ {
disabledExtensions?: $_
}'
Length of output: 5663
Script:
#!/bin/bash
# Check the core extensions implementation
echo "Checking core extensions implementation..."
cat packages/editor/src/core/extensions/extensions.tsx
# Check the read-only extensions implementation
echo -e "\nChecking read-only extensions implementation..."
cat packages/editor/src/core/extensions/read-only-extensions.tsx
# Check the editor types
echo -e "\nChecking editor types..."
cat packages/editor/src/core/types/editor.ts
Length of output: 14259
space/core/components/editor/rich-text-editor.tsx (1)
7-8: Verify the impact of interface changes on existing implementations
The interface modification to exclude disabledExtensions is a breaking change. Ensure all implementations of RichTextEditorWrapperProps are updated accordingly.
✅ Verification successful
Interface change is safe to proceed
The interface modification to exclude disabledExtensions is safe as verified through the codebase analysis:
- The
RichTextEditorWrapperPropsinterface is only used internally in the editor components - None of the existing implementations pass the
disabledExtensionsprop toRichTextEditor - All usages follow the correct prop pattern with only the required props: workspaceSlug, workspaceId, and other standard editor props
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Find all files that might be affected by the RichTextEditorWrapperProps interface change
# Search for files importing or using RichTextEditorWrapperProps
rg -l "RichTextEditorWrapperProps"
# Search for direct usage of RichTextEditor component
rg -l "<RichTextEditor"
Length of output: 545
Script:
#!/bin/bash
# Let's examine the actual usage of RichTextEditorWrapperProps and check if disabledExtensions prop is being used
# Check the content of files that might be affected
echo "=== Checking web/core/components/editor/rich-text-editor/rich-text-editor.tsx ==="
rg -A 5 -B 5 "RichTextEditorWrapperProps" "web/core/components/editor/rich-text-editor/rich-text-editor.tsx"
# Check if disabledExtensions prop is being passed to RichTextEditor
echo -e "\n=== Checking usage of disabledExtensions prop ==="
rg -A 2 -B 2 "<RichTextEditor.*disabledExtensions"
Length of output: 1207
Script:
#!/bin/bash
# Let's check how RichTextEditor is being used in the components we found earlier
echo "=== Checking description-input.tsx ==="
rg -A 5 -B 5 "<RichTextEditor" "web/core/components/issues/description-input.tsx"
echo -e "\n=== Checking description-editor.tsx ==="
rg -A 5 -B 5 "<RichTextEditor" "web/core/components/issues/issue-modal/components/description-editor.tsx"
echo -e "\n=== Checking issue-description.tsx ==="
rg -A 5 -B 5 "<RichTextEditor" "web/core/components/inbox/modals/create-modal/issue-description.tsx"
echo -e "\n=== Checking editor.tsx ==="
rg -A 5 -B 5 "<RichTextEditor" "packages/editor/src/core/components/editors/rich-text/editor.tsx"
Length of output: 2254
packages/editor/src/core/types/collaboration.ts (1)
23-23: Breaking Change: Verify all usages of TCollaborativeEditorHookProps
Making disabledExtensions required is a breaking change that affects all components using this type. Let's verify the impact and ensure all usages are updated.
Consider adding migration documentation in the PR description or README to guide users in updating their code with the required disabledExtensions property. This will help ensure a smooth transition for consumers of this type.
packages/editor/src/core/components/editors/rich-text/editor.tsx (1)
29-29: Verify performance impact of dependency changes
The addition of disabledExtensions to the useCallback dependency array could potentially cause unnecessary re-renders if this prop changes frequently. Consider memoizing the disabledExtensions array at a higher level if it's constructed dynamically.
web/core/components/editor/rich-text-editor/rich-text-read-only-editor.tsx (3)
9-10: LGTM! Clean import organization.
The new import for useEditorFlagging is well-organized under a dedicated section for plane web hooks.
29-29: LGTM! Clean prop passing implementation.
The disabledExtensions prop is correctly passed to the underlying editor component.
12-15: Verify the impact of type changes on dependent components.
The type changes look correct, but let's verify if omitting disabledExtensions from the props type affects any existing component implementations.
✅ Verification successful
Type changes are safe to proceed
Based on the verification results:
- None of the components using
<RichTextReadOnlyEditor>are passing thedisabledExtensionsprop in their implementations. - The base interface
IReadOnlyEditorPropsinpackages/editor/src/core/types/editor.tsstill includesdisabledExtensions, indicating this is handled at a lower level. - The omission in the wrapper type is intentional and doesn't break existing usage patterns.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Find components that might be affected by the type changes
# Search for components using RichTextReadOnlyEditor
rg -l "RichTextReadOnlyEditor" --type typescript --type typescriptreact
# Search for any direct usage of disabledExtensions prop
rg "disabledExtensions.*RichTextReadOnlyEditor" --type typescript --type typescriptreact
Length of output: 232
Script:
#!/bin/bash
# Search for components using RichTextReadOnlyEditor
rg -l "RichTextReadOnlyEditor"
# Search for any direct usage of disabledExtensions prop with RichTextReadOnlyEditor
rg -B2 -A2 "disabledExtensions.*RichTextReadOnlyEditor"
Length of output: 747
Script:
#!/bin/bash
# Check the actual usage of RichTextReadOnlyEditor in the found files
# Looking specifically for prop usage patterns
rg -B3 -A3 "<RichTextReadOnlyEditor" web/core/components/issues/description-input.tsx web/core/components/profile/activity/profile-activity-list.tsx web/core/components/profile/activity/activity-list.tsx web/core/components/core/modals/gpt-assistant-popover.tsx web/ce/components/pages/editor/ai/menu.tsx web/ce/components/pages/editor/ai/ask-pi-menu.tsx
# Also check the type definition file
cat packages/editor/src/core/types/editor.ts
Length of output: 10443
web/core/components/editor/lite-text-editor/lite-text-read-only-editor.tsx (4)
9-10: LGTM: Clean import organization
The new import follows the project's organization pattern and is properly grouped under a descriptive comment.
12-15: LGTM: Type definition properly updated
The type definition correctly omits disabledExtensions along with other internally handled properties, maintaining proper type safety.
33-33: LGTM: Proper prop passing implementation
The disabledExtensions prop is correctly placed before the spread operator, preventing accidental overwrites.
27-28: Verify handling of undefined workspaceSlug
The optional chaining suggests workspaceSlug could be undefined. Consider:
- Adding a default value or error handling for undefined case
- Keeping the original property name
documentEditorfor better context preservation
packages/editor/src/core/components/editors/editor-wrapper.tsx (3)
Line range hint 18-75: Implementation looks good!
The EditorWrapper component is well-structured and the integration of disabledExtensions follows React best practices. The changes align well with the code-splitting objectives.
22-22: Consider adding validation for conflicting extensions
While the type is correctly defined, there's no runtime validation to prevent an extension from being both enabled (in extensions) and disabled (in disabledExtensions) simultaneously.
Let's check if there are any existing validation mechanisms:
Consider adding a validation check:
const validateExtensions = (extensions: Extension[], disabledExtensions?: Extension[]) => {
if (!disabledExtensions?.length) return;
const conflicting = extensions.some(ext =>
disabledExtensions.some(disabled => disabled.name === ext.name)
);
if (conflicting) {
console.warn('Found extensions that are both enabled and disabled');
}
};41-41: Verify useEditor hook implementation
The disabledExtensions prop is passed to the useEditor hook, but we should verify its proper handling within the hook.
Let's check the hook implementation:
✅ Verification successful
Based on the examination of the useEditor hook implementation, I can now generate the final response:
The disabledExtensions prop is properly handled in the useEditor hook
The hook correctly passes the disabledExtensions prop to the CoreEditorExtensions function, which is used to configure the editor's extensions. The implementation shows that:
- The prop is properly typed as
TExtensions[] - It's passed through to the core extensions configuration
- It's used to control which extensions are enabled/disabled in the editor
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for useEditor hook implementation
ast-grep --pattern 'export const useEditor = ($params) => {
$$$
}'
# Search for any extension filtering logic
rg -A 10 "disabledExtensions.*filter" packages/editor/src/
Length of output: 131
Script:
#!/bin/bash
# Let's try different patterns to locate the useEditor hook implementation
ast-grep --pattern 'const useEditor = ($params) => {
$$$
}'
# Also search for function declaration
ast-grep --pattern 'function useEditor($params) {
$$$
}'
# Search for any usage of disabledExtensions
rg "disabledExtensions" packages/editor/src/ -A 5
# Look for files that might contain the hook
fd "editor" packages/editor/src
Length of output: 26729
Script:
#!/bin/bash
# Let's examine the useEditor hook implementation
cat packages/editor/src/core/hooks/use-editor.ts
Length of output: 11281
web/core/components/editor/rich-text-editor/rich-text-editor.tsx (3)
12-12: LGTM: Clean import addition
The new import for useEditorFlagging is properly placed with other hook imports, maintaining good code organization.
49-49: LGTM: Proper prop forwarding
The disabledExtensions prop is correctly passed to the underlying component, maintaining the component's contract.
15-16: Verify the impact of excluding disabledExtensions
The interface update correctly excludes disabledExtensions from the base interface, as it's now handled internally. However, let's verify this doesn't break any existing implementations.
✅ Verification successful
The interface change is safe and properly handled
The search results confirm that the exclusion of disabledExtensions from RichTextEditorWrapperProps is correct and safe because:
- The prop is now handled internally within the component using
useEditorFlagginghook:
const { richTextEditor: disabledExtensions } = useEditorFlagging(workspaceSlug?.toString());-
All implementations of
RichTextEditorin the codebase are already using the wrapper component and don't directly passdisabledExtensions, as they use the interface that already omits it. -
The base functionality is preserved as the component still passes the
disabledExtensionsprop internally toRichTextEditorWithRef.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for direct usage of disabledExtensions prop in other components
# that might be affected by this interface change
# Search for components using RichTextEditor with disabledExtensions prop
rg -l "RichTextEditor.*disabledExtensions" --type tsx
# Search for any other usage of IRichTextEditor interface
ast-grep --pattern 'interface $_ extends IRichTextEditor'
Length of output: 143
Script:
#!/bin/bash
# Let's try a more comprehensive search approach
# Search for any usage of disabledExtensions in tsx/ts files
rg "disabledExtensions" -t ts -t tsx
# Search for components extending or using IRichTextEditor
rg "IRichTextEditor" -t ts -t tsx
# Search for RichTextEditor component usage
rg "RichTextEditor" -t ts -t tsx
Length of output: 187
Script:
#!/bin/bash
# Let's try without file type specifications since they're not recognized
# Search for any usage of disabledExtensions
rg "disabledExtensions"
# Search for components extending or using IRichTextEditor
rg "IRichTextEditor"
# Search for RichTextEditor component usage
rg "RichTextEditor"
Length of output: 12655
packages/editor/src/core/components/editors/document/collaborative-read-only-editor.tsx (3)
Line range hint 1-77: Implementation looks clean and well-structured
The addition of disabledExtensions is implemented cleanly, maintaining the component's structure while adding the new functionality. The prop is properly threaded through to the necessary hooks and components.
18-18: Verify type definition for disabledExtensions
The new disabledExtensions prop has been added, but its type definition should be verified in the ICollaborativeDocumentReadOnlyEditor interface.
✅ Verification successful
Let me gather more information about the type inheritance chain since ICollaborativeDocumentReadOnlyEditor extends Omit<IReadOnlyEditorProps, "initialValue">.
Let me check the type definition of TExtensions to complete the verification.
Type definition for disabledExtensions is properly defined
The disabledExtensions prop is correctly typed in the inheritance chain:
- It's defined as
disabledExtensions: TExtensions[]inIReadOnlyEditorProps ICollaborativeDocumentReadOnlyEditorinherits it throughOmit<IReadOnlyEditorProps, "initialValue">TExtensionsis a union type of specific extension names:"ai" | "collaboration-cursor" | "issue-embed" | "slash-commands" | "enter-key" | "callout"
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check the type definition of disabledExtensions in the interface
# Expected: Should find the type definition in the interface file
# Search for the interface definition
ast-grep --pattern 'interface ICollaborativeDocumentReadOnlyEditor {
$$$
}'
# Backup: If interface is defined in a different way or location
rg -A 10 "ICollaborativeDocumentReadOnlyEditor"
Length of output: 3565
Script:
#!/bin/bash
# Check the IReadOnlyEditorProps interface definition
ast-grep --pattern 'interface IReadOnlyEditorProps {
$$$
}'
# Backup search for IReadOnlyEditorProps
rg -A 15 "interface IReadOnlyEditorProps"
Length of output: 2224
Script:
#!/bin/bash
# Check the TExtensions type definition
rg "type TExtensions =" -A 5
Length of output: 193
41-41: Verify hook implementation for disabledExtensions
The disabledExtensions prop is now passed to useReadOnlyCollaborativeEditor. Let's verify the hook's implementation to ensure proper handling of this new property.
✅ Verification successful
Based on the gathered information, I can now provide the final response:
disabledExtensions prop is properly handled in the hook implementation
The hook correctly:
- Accepts
disabledExtensionsthrough its props interface (TCollaborativeEditorHookProps) - Has proper type definition as
TExtensions[] - Passes it through to the underlying
useReadOnlyEditorhook
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check the hook implementation for handling disabledExtensions
# Expected: Should find the hook implementation and how it uses disabledExtensions
# Search for the hook implementation
ast-grep --pattern 'function useReadOnlyCollaborativeEditor($_) {
$$$
}'
# Backup: Search for the hook definition in any format
rg -A 10 "useReadOnlyCollaborativeEditor"
Length of output: 3806
Script:
#!/bin/bash
# Let's check how disabledExtensions is used within the hook implementation
rg -A 20 "disabledExtensions" packages/editor/src/core/hooks/use-read-only-collaborative-editor.ts
# Also check the type definition to ensure it's properly typed
ast-grep --pattern 'type TReadOnlyCollaborativeEditorProps = {
$$$
}'
# Backup: Search for the type definition
rg "TReadOnlyCollaborativeEditorProps" -A 20
Length of output: 3768
Script:
#!/bin/bash
# Let's check the base type TCollaborativeEditorHookProps to see if disabledExtensions is defined there
rg -A 20 "type TCollaborativeEditorHookProps = {"
# Also check where the editor is initialized to see how disabledExtensions is used
rg -B 5 -A 15 "useEditor\(" packages/editor/src/core/hooks/use-read-only-collaborative-editor.ts
Length of output: 290
Script:
#!/bin/bash
# Fix the regex syntax and try again
rg -A 20 "TCollaborativeEditorHookProps ="
# Search for useEditor without escaping parentheses
rg -B 5 -A 15 "useEditor" packages/editor/src/core/hooks/use-read-only-collaborative-editor.ts
# Also search for the editor initialization
rg -A 10 "const editor = " packages/editor/src/core/hooks/use-read-only-collaborative-editor.ts
Length of output: 2179
packages/editor/src/core/components/editors/document/read-only-editor.tsx (2)
13-13: LGTM: Type import added correctly
The TExtensions type import is appropriately added to support the new disabled extensions feature.
56-56: Verify useReadOnlyEditor hook implementation
Ensure that the useReadOnlyEditor hook properly handles the disabledExtensions property.
✅ Verification successful
Property is properly handled by the hook
The useReadOnlyEditor hook in packages/editor/src/core/hooks/use-read-only-editor.ts correctly accepts and processes the disabledExtensions property. The property is:
- Properly typed as part of the
CustomReadOnlyEditorPropsinterface - Destructured from the props in the hook implementation
- Passed down to the core extensions setup
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for the useReadOnlyEditor hook implementation
ast-grep --pattern 'export const useReadOnlyEditor = ($params) => {
$$$
}'
# Search for any tests related to disabled extensions
rg -l "disabledExtensions.*test"
Length of output: 113
Script:
#!/bin/bash
# Let's try different patterns to locate the hook implementation
ast-grep --pattern 'useReadOnlyEditor'
# Also search with ripgrep for more context
rg -A 10 "useReadOnlyEditor"
# Search for any usage of disabledExtensions
rg "disabledExtensions"
Length of output: 18456
packages/editor/src/core/hooks/use-read-only-collaborative-editor.ts (3)
Line range hint 1-89: Implementation looks solid!
The changes to introduce disabledExtensions are well-integrated into the existing hook. The implementation maintains proper cleanup, error handling, and backward compatibility.
Line range hint 70-82: Verify the handling of disabledExtensions in useReadOnlyEditor
Let's ensure that useReadOnlyEditor properly handles the disabledExtensions property and maintains the expected behavior.
✅ Verification successful
Based on the shell script results, I can now generate the final response since I have found the complete implementation showing how disabledExtensions is handled in useReadOnlyEditor:
disabledExtensions is properly handled in useReadOnlyEditor
The implementation shows that disabledExtensions is correctly:
- Passed to
CoreReadOnlyEditorExtensionswhich applies it to the core extensions - Used to conditionally enable/disable specific features like slash commands
- Propagated through the component hierarchy maintaining consistent behavior
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Find and verify the implementation of useReadOnlyEditor
# Search for the hook implementation
ast-grep --pattern 'const useReadOnlyEditor = ($_) => {
$$$
}'
# Search for disabledExtensions usage
rg -A 5 'disabledExtensions' --type ts
Length of output: 49741
14-14: Verify the type definition for disabledExtensions
The type definition for disabledExtensions in TReadOnlyCollaborativeEditorProps should be reviewed to ensure type safety and proper documentation.
✅ Verification successful
Type definition for disabledExtensions is properly defined and used correctly
The disabledExtensions property in TReadOnlyCollaborativeEditorProps is well-defined and type-safe. It is:
- Defined as
TExtensions[]in the base typeTCollaborativeEditorHookProps TExtensionsis a union type of specific editor extensions:"ai" | "collaboration-cursor" | "issue-embed" | "slash-commands" | "enter-key" | "callout"- Used consistently across the codebase for disabling specific editor features
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Find and verify the type definition for TReadOnlyCollaborativeEditorProps
# Search for the type definition
ast-grep --pattern 'type TReadOnlyCollaborativeEditorProps = {
$$$
disabledExtensions$_
$$$
}'
# Alternatively, search for the interface definition
ast-grep --pattern 'interface TReadOnlyCollaborativeEditorProps {
$$$
disabledExtensions$_
$$$
}'
Length of output: 208
Script:
#!/bin/bash
# Let's try a broader search to find the type definition
# Search for files containing TReadOnlyCollaborativeEditorProps
rg "TReadOnlyCollaborativeEditorProps" -A 10
# Also search for the file directly since it might be in the same directory
fd "use-read-only-collaborative-editor.ts" --type f --exec cat {}
Length of output: 4253
Script:
#!/bin/bash
# Let's find the TCollaborativeEditorHookProps type definition since TReadOnlyCollaborativeEditorProps extends it
rg "TCollaborativeEditorHookProps" -A 10
# Also search for any usage of disabledExtensions in the codebase
rg "disabledExtensions" -B 2 -A 2
Length of output: 36046
Script:
#!/bin/bash
# Let's find the TExtensions type definition to understand what extensions can be disabled
rg "type TExtensions =" -A 5
# Also search for any imports of TExtensions to find where it might be defined
rg "TExtensions.*from" -B 2 -A 2
Length of output: 5342
space/core/components/editor/lite-text-editor.tsx (1)
13-14: LGTM: Interface changes align with the code splitting objective.
The updated interface correctly handles the disabledExtensions property through the Omit utility type, maintaining proper type safety.
packages/editor/src/core/hooks/use-collaborative-editor.ts (1)
Line range hint 78-97: Verify consistent behavior of disabled extensions
The disabledExtensions property is used in multiple places to control feature availability. Let's ensure it's consistently applied across all extension points.
✅ Verification successful
Based on the results, I can now generate the final response as I have gathered sufficient information about how disabledExtensions is handled across the codebase.
Disabled extensions are consistently handled across all extension points
The verification shows that disabledExtensions is properly implemented with consistent behavior:
- All editor variants (rich text, lite text, collaborative, read-only) correctly consume and pass down the
disabledExtensionsprop - Extension initialization points consistently check
disabledExtensionsbefore adding optional features:- Slash commands are conditionally added based on
disabledExtensions?.includes("slash-commands") - AI features are toggled via
aiEnabled: !disabledExtensions?.includes("ai") - Enter key behavior is controlled through
disabledExtensions?.includes("enter-key")
- Slash commands are conditionally added based on
The implementation follows a consistent pattern where each optional feature checks the disabledExtensions array before being initialized, ensuring reliable feature toggling across the editor.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify consistent handling of disabledExtensions across the codebase
# Check all files that might handle disabledExtensions
echo "Checking disabledExtensions usage patterns:"
rg -A 3 "disabledExtensions"
# Look for potential extension initialization points
echo "Checking extension initialization patterns:"
ast-grep --pattern 'extensions: [
$$$
]'
Length of output: 28333
packages/editor/src/core/extensions/slash-commands/root.tsx (2)
6-6: LGTM: Import changes are well-organized
The addition of TExtensions to the imports is properly grouped with other type imports and aligns with the new type requirements.
115-120: Verify all SlashCommands callers are updated
The implementation changes look good, but we should verify that all callers of SlashCommands have been updated to provide the required props.
✅ Verification successful
All callers of SlashCommands are properly updated
Based on the verification results, all callers of SlashCommands are correctly providing the required props:
- In
packages/editor/src/core/components/editors/rich-text/editor.tsx: ProvidesdisabledExtensions - In
packages/editor/src/ce/extensions/document-extensions.tsx: ProvidesdisabledExtensions
The type TExtensionProps requires:
disabledExtensions: TExtensions[](required)additionalOptions?: TSlashCommandAdditionalOption[](optional)
All instances are passing the required props correctly.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for all SlashCommands function calls to verify they're updated with the new props structure
ast-grep --pattern 'SlashCommands($$$)'
# Also search for any direct string references
rg -l "SlashCommands"
Length of output: 832
Script:
#!/bin/bash
# Let's verify the type definition and see what props are required
ast-grep --pattern 'type TExtensionProps'
# Also check the implementation of getSlashCommandFilteredSections to understand required props
ast-grep --pattern 'function getSlashCommandFilteredSections'
Length of output: 107
Script:
#!/bin/bash
# Let's try a different pattern to find the type definition
rg "TExtensionProps" -A 3
# And try to find getSlashCommandFilteredSections with a different pattern
rg "getSlashCommandFilteredSections" -A 3
# Also check the content of the file to understand the context better
cat "packages/editor/src/core/extensions/slash-commands/root.tsx"
Length of output: 5485
packages/editor/src/core/extensions/read-only-extensions.tsx (2)
31-31: LGTM! Type definitions are well-structured
The addition of TExtensions type and the disabledExtensions property to the Props interface is clean and properly typed.
Also applies to: 36-40
44-44: LGTM! Clean props destructuring
The destructuring of props is clean and matches the Props interface definition.
web/core/components/editor/lite-text-editor/lite-text-editor.tsx (4)
17-17: LGTM!
The import is correctly placed in the hooks section and follows the established import structure.
79-79: LGTM!
The disabledExtensions prop is correctly passed to the underlying component.
20-21: LGTM! Verify interface changes across consumers.
The interface change correctly omits disabledExtensions as it's now handled internally via the hook.
✅ Verification successful
Let me gather more information to verify if there are any direct usages of disabledExtensions that might be affected.
Let me check the actual usage of LiteTextEditor in these files to verify if there are any potential issues with the interface change.
Interface changes are safe to proceed
The verification shows that none of the LiteTextEditor consumers are using the disabledExtensions prop, and they are all correctly using the interface with only the allowed props (workspaceId, projectId, workspaceSlug, anchor, etc.). The interface change is safe and won't cause any breaking changes in the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any direct usage of disabledExtensions prop in LiteTextEditor components
# that might be affected by this interface change
# Search for LiteTextEditor usage with disabledExtensions prop
rg -A 3 "LiteTextEditor.*disabledExtensions"
# Search for any type extensions of LiteTextEditorWrapperProps
ast-grep --pattern 'interface $_ extends LiteTextEditorWrapperProps'
Length of output: 898
Script:
#!/bin/bash
# Search for any imports or usage of LiteTextEditor component
rg -l "LiteTextEditor"
# Search for any direct usage of disabledExtensions prop in components
rg -A 2 "<LiteTextEditor.*disabledExtensions"
Length of output: 626
Script:
#!/bin/bash
# Check the content of files that use LiteTextEditor
rg -A 5 "<LiteTextEditor" space/core/components/issues/peek-overview/comment/comment-detail-card.tsx space/core/components/issues/peek-overview/comment/add-comment.tsx web/core/components/issues/issue-detail/issue-activity/comments/comment-create.tsx web/core/components/issues/issue-detail/issue-activity/comments/comment-card.tsx
Length of output: 3133
54-55: Review the workspace slug type handling.
The toString() call on workspaceSlug suggests it might be receiving a non-string type. Consider handling this at the prop level or adding type validation.
packages/editor/src/core/hooks/use-read-only-editor.ts (2)
14-14: LGTM: Type import follows conventions
The addition of TExtensions type import is well-organized and follows TypeScript naming conventions.
33-33: Verify handling of disabledExtensions in CoreReadOnlyEditorExtensions
The disabledExtensions property is correctly passed to CoreReadOnlyEditorExtensions, but we should verify how it handles undefined or empty arrays.
Also applies to: 59-59
✅ Verification successful
No issues with handling of disabledExtensions in CoreReadOnlyEditorExtensions
The implementation safely handles the disabledExtensions property through TypeScript's type system. The property is properly destructured from props and used in a type-safe manner. The component doesn't need explicit null/undefined checks because:
- The property is required by the Props type interface
- The extensions are configured independently of
disabledExtensions - Empty arrays are valid values and won't cause any issues
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for CoreReadOnlyEditorExtensions implementation
ast-grep --pattern 'export const CoreReadOnlyEditorExtensions = ({ $_ }) => {
$$$
}'
# Search for any default value assignments or null checks
rg -A 5 'disabledExtensions(\s+)?=' packages/editor/src/extensions
Length of output: 228
Script:
#!/bin/bash
# Search for CoreReadOnlyEditorExtensions implementation with broader pattern
ast-grep --pattern 'CoreReadOnlyEditorExtensions'
# Search for files containing CoreReadOnlyEditorExtensions
fd CoreReadOnlyEditorExtensions
# Search for disabledExtensions in the entire codebase
rg -A 5 'disabledExtensions'
Length of output: 40905
Script:
#!/bin/bash
# Search for CoreReadOnlyEditorExtensions implementation
ast-grep --pattern 'export const CoreReadOnlyEditorExtensions = ({ $_ }) => {
$$$
}' packages/editor/src/core/extensions/read-only-extensions.tsx
# Search for CoreReadOnlyEditorAdditionalExtensions implementation
ast-grep --pattern 'export const CoreReadOnlyEditorAdditionalExtensions = ({ $_ }) => {
$$$
}' packages/editor/src/ce/extensions/core/read-only-extensions.ts
Length of output: 311
Script:
#!/bin/bash
# Search for the implementation of read-only extensions
rg -A 20 "export const CoreReadOnlyEditorExtensions = \(" packages/editor/src/core/extensions/read-only-extensions.tsx
# Search for StarterKit configuration in read-only extensions
rg -A 10 "StarterKit.configure\(" packages/editor/src/core/extensions/read-only-extensions.tsx
Length of output: 1002
Script:
#!/bin/bash
# Get more context of the CoreReadOnlyEditorExtensions implementation
rg -A 50 "export const CoreReadOnlyEditorExtensions = \(" packages/editor/src/core/extensions/read-only-extensions.tsx
# Search for any null checks or default value assignments for disabledExtensions
rg "disabledExtensions(\s+)?(\?\?|\|\||=)" packages/editor/src/core/extensions/read-only-extensions.tsx
Length of output: 1617
web/core/components/pages/version/editor.tsx (3)
15-15: LGTM: Clean import statement
The import follows React conventions and maintains proper module organization.
35-36: Verify empty string fallback behavior
The empty string fallback for workspaceSlug should be verified to ensure it doesn't cause unintended behavior in the editor flagging system.
✅ Verification successful
Based on the search results, I can now generate the final response:
Empty string fallback is consistent with codebase patterns
The empty string fallback for workspaceSlug in useEditorFlagging is intentionally used throughout the codebase. The search results show:
- Other editor components use similar pattern with
useEditorFlagging(workspaceSlug?.toString()) - Empty string fallbacks (
?? "") are consistently used across the codebase for workspace slug handling in various contexts like:- Issue embeds
- Mention handling
- Activity components
- Analytics components
- Integration components
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for other usages of useEditorFlagging to verify consistent fallback behavior
ast-grep --pattern 'useEditorFlagging($$$)'
# Search for any error handling or validation related to workspace slug
rg -A 3 'workspaceSlug.*toString\(\).*??.*""'
Length of output: 12596
107-107: Verify DocumentReadOnlyEditorWithRef prop handling
Ensure that the DocumentReadOnlyEditorWithRef component properly handles the disabledExtensions prop and applies the extensions configuration correctly.
✅ Verification successful
Let me gather more information about the DocumentReadOnlyEditorWithRef implementation.
Let me check the implementation details of the read-only editor to verify how it handles the disabledExtensions prop.
The disabledExtensions prop is properly handled
The implementation shows that the disabledExtensions prop is:
- Correctly defined in the
IDocumentReadOnlyEditorinterface - Properly passed through the
DocumentReadOnlyEditorWithRefto the base editor - Utilized in the
useReadOnlyEditorhook - Effectively propagated to the core extensions through
CoreReadOnlyEditorExtensions
The prop is used to configure which extensions should be disabled in the read-only editor, maintaining a consistent pattern across the editor implementation.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for DocumentReadOnlyEditorWithRef implementation to verify prop handling
ast-grep --pattern 'DocumentReadOnlyEditorWithRef = $$$'
# Search for disabledExtensions prop usage in related components
rg -A 5 'disabledExtensions.*prop'
Length of output: 2452
Script:
#!/bin/bash
# Search for DocumentReadOnlyEditorWithRef definition and its usage of disabledExtensions
ast-grep --pattern 'const DocumentReadOnlyEditorWithRef = $$$'
# Search for files containing DocumentReadOnlyEditorWithRef
rg "DocumentReadOnlyEditorWithRef"
# Search for read-only editor implementations
fd "read-only" --type f --exec rg -l "disabledExtensions"
Length of output: 3096
Script:
#!/bin/bash
# Check the read-only editor implementation
cat packages/editor/src/core/components/editors/document/read-only-editor.tsx
# Check how read-only extensions are handled
cat packages/editor/src/core/extensions/read-only-extensions.tsx
Length of output: 6100
packages/editor/src/core/extensions/extensions.tsx (3)
35-35: LGTM: Import changes are well-organized
The addition of TExtensions type import is properly placed with other type imports and is used consistently in the code.
52-52: LGTM: Parameter destructuring is consistent
The disabledExtensions parameter is properly destructured alongside other parameters, maintaining consistency with the type definition.
167-169: Consider adding validation and reviewing extension order
Two potential improvements for the extensions configuration:
- Add validation for disabled extension names to prevent runtime errors
- Review the placement of additional extensions at the end of the array, as it might override previous configurations
Let's verify the extension configurations:
Consider adding validation:
...CoreEditorAdditionalExtensions({
+ // Validate extension names
+ disabledExtensions: disabledExtensions.filter(ext =>
+ Object.values(TExtensions).includes(ext)
+ ),
}),packages/editor/src/core/types/editor.ts (2)
151-151:
Breaking Change: disabledExtensions is now required in IReadOnlyEditorProps
Making disabledExtensions required is a breaking change that will affect all components implementing IReadOnlyEditorProps. Ensure all consumers of this interface are updated to provide this property.
Let's verify the impact on existing implementations:
109-109:
Breaking Change: disabledExtensions is now required in IEditorProps
Making disabledExtensions required is a breaking change that will affect all components implementing IEditorProps. Ensure all consumers of this interface are updated to provide this property.
Let's verify the impact on existing implementations:
web/core/components/pages/editor/editor-body.tsx (2)
227-227: LGTM: Consistent implementation of disabledExtensions.
The disabledExtensions prop is correctly passed to both editable and read-only editor components, maintaining feature parity between the two modes.
Also applies to: 236-236
87-87: Verify workspace slug type safety.
The useEditorFlagging hook is called with an optional chained workspace slug that might be undefined. Consider adding a type guard or default value to ensure type safety.
packages/editor/src/core/hooks/use-editor.ts (2)
19-26: LGTM: Type imports are well-organized
The addition of TExtensions type import is properly grouped with related type imports.
90-91: Verify extension disabling logic
Ensure that the CoreEditorExtensions function properly handles empty or undefined disabledExtensions arrays to prevent runtime errors.
✅ Verification successful
Let me generate additional scripts to check how the disabledExtensions property is handled in the core extensions implementation.
Let me check one more aspect - how the extensions are conditionally enabled/disabled in the codebase.
Based on the gathered information, I can now provide the final response:
Extension disabling is properly handled
The disabledExtensions property is safely implemented with:
- Proper TypeScript type definition limiting it to specific extension keys
- Optional chaining when checking disabled status
- Consistent null-safe usage across the codebase
- Default empty array behavior in extension configuration
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check how CoreEditorExtensions handles disabledExtensions
# Find the CoreEditorExtensions implementation
ast-grep --pattern 'export const CoreEditorExtensions = ({ $_ }) => {
$$$
}'
# Check for any null checks or default values
rg -A 5 'disabledExtensions' packages/editor/src/
Length of output: 25371
Script:
#!/bin/bash
# Find the implementation of StarterKit configuration that uses disabledExtensions
ast-grep --pattern 'StarterKit.configure({
$$$
$_(disabledExtensions)
$$$
})'
# Find any default value assignments for disabledExtensions
ast-grep --pattern '$_: { disabledExtensions = $_, $$ }'
# Check type definition of TExtensions
rg -A 5 'type TExtensions ='
Length of output: 338
Script:
#!/bin/bash
# Find conditional checks related to disabledExtensions
rg -A 3 'if.*disabledExtensions.*includes'
# Find where disabledExtensions is used in extension configuration
ast-grep --pattern 'if (!disabledExtensions?.includes($_)) {
$$$
}'
Length of output: 1150
packages/editor/src/core/extensions/slash-commands/command-items-list.tsx (3)
40-42: Imports updated appropriately
The added imports for TExtensions and coreEditorAdditionalSlashCommandOptions ensure that the necessary types and functions are available for the enhancements made to the code.
52-56: Addition of TArgs type enhances type safety
Defining the TArgs type clarifies the structure of arguments passed to getSlashCommandFilteredSections, improving code readability and maintainability.
58-60: Update function signature to accept TArgs improves parameter handling
Changing the function getSlashCommandFilteredSections to accept args: TArgs enhances parameter clarity and allows for expansion of arguments in the future. Destructuring additionalOptions and disabledExtensions from args improves code organization.
However, ensure that all calls to this function are updated to match the new signature to prevent any breaking changes.
Run the following script to verify that all usages of getSlashCommandFilteredSections have been updated:
This script searches for any calls to getSlashCommandFilteredSections that do not pass an object as the argument, indicating potential outdated usages.
✅ Verification successful
Function signature change is properly implemented across the codebase
The verification confirms that:
- The
TArgstype matches exactly withTExtensionPropstype, containing the same properties - The only usage of
getSlashCommandFilteredSectionsis inroot.tsxwhere it's called withpropsthat has the correct typeTExtensionProps - The function signature change is consistent with its usage, and no breaking changes were introduced
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Find all occurrences of 'getSlashCommandFilteredSections' to check for the new signature.
# Search for function calls to 'getSlashCommandFilteredSections' that may not use the new 'args' parameter.
rg 'getSlashCommandFilteredSections\((?!{)' --multiline-dotall
Length of output: 339
Script:
#!/bin/bash
# Search for all occurrences of getSlashCommandFilteredSections to analyze its usage
rg "getSlashCommandFilteredSections" -A 2
# Also search using ast-grep to find the function definition and its usages
ast-grep --pattern 'getSlashCommandFilteredSections'
Length of output: 1421
Script:
#!/bin/bash
# Let's examine the props being passed to getSlashCommandFilteredSections in root.tsx
rg -B 5 -A 1 "getSlashCommandFilteredSections\(props\)" packages/editor/src/core/extensions/slash-commands/root.tsx
# Also check the type definition of TArgs
rg "type TArgs =" -A 3 packages/editor/src/core/extensions/slash-commands/command-items-list.tsx
Length of output: 507
Script:
#!/bin/bash
# Let's check the type definition of TExtensionProps to ensure it matches TArgs
rg "type TExtensionProps =" -A 5 packages/editor/src/core/extensions/slash-commands/root.tsx
Length of output: 272
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (4)
packages/editor/src/core/extensions/core-without-props.ts (1)
22-23: LGTM! Clean separation of core editor extensionsThe approach of importing and spreading additional core extensions aligns well with the code splitting objective. This pattern allows for better maintainability and separation of concerns.
Consider documenting the purpose and contents of
CoreEditorAdditionalExtensionsWithoutPropsin a comment to help other developers understand what types of extensions belong there.Also applies to: 94-94
packages/editor/src/core/extensions/read-only-extensions.tsx (1)
37-37: Add documentation for disabledExtensions propPlease add JSDoc comments to document:
- Purpose of the
disabledExtensionsarray- List of valid extension names that can be disabled
- Impact of disabling specific extensions
type Props = { + /** List of extensions to disable in the editor + * @example ['bulletList', 'orderedList'] + */ disabledExtensions: TExtensions[];packages/editor/src/core/extensions/extensions.tsx (1)
Line range hint
40-50: Add documentation fordisabledExtensionsConsider adding JSDoc comments to document:
- Purpose of the
disabledExtensionsproperty- List of extension types that can be disabled
- Any limitations or side effects of disabling specific extensions
Example:
type TArguments = { /** * Array of extensions to disable in the editor * @example ['bulletList', 'orderedList'] * @note Disabling certain core extensions may affect editor functionality */ disabledExtensions: TExtensions[]; // ... other properties };packages/editor/src/core/extensions/slash-commands/command-items-list.tsx (1)
42-57: LGTM! Consider adding JSDoc comments.The new type definitions and imports improve type safety. Consider adding JSDoc comments to document the purpose and structure of the
TArgstype, especially since it contains required configuration for extensions.+/** + * Arguments for slash command filtering + * @property {TSlashCommandAdditionalOption[]} additionalOptions - Optional additional slash command options + * @property {TExtensions[]} disabledExtensions - List of extensions to be disabled + */ type TArgs = { additionalOptions?: TSlashCommandAdditionalOption[]; disabledExtensions: TExtensions[]; };
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (5)
packages/editor/src/core/extensions/core-without-props.ts(2 hunks)packages/editor/src/core/extensions/extensions.tsx(4 hunks)packages/editor/src/core/extensions/read-only-extensions.tsx(3 hunks)packages/editor/src/core/extensions/slash-commands/command-items-list.tsx(4 hunks)packages/editor/src/core/types/editor.ts(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- packages/editor/src/core/types/editor.ts
🔇 Additional comments (8)
packages/editor/src/core/extensions/core-without-props.ts (1)
96-96: Verify issue widget integration
The IssueWidgetWithoutProps is now part of document-specific extensions. This separation makes sense architecturally.
Let's verify the widget's integration:
✅ Verification successful
Issue widget integration is properly structured
The verification confirms that the issue widget integration is correctly implemented:
IssueWidgetWithoutPropsis properly isolated in the document-specific extensions array- The widget implementation is cleanly separated into two variants:
- A base widget node (
widget-node.tsx) with callback props - A prop-less version (
issue-embed-without-props.ts) for document-specific use
- A base widget node (
- No unexpected coupling or references exist in other core extensions
- The architectural separation is maintained through proper exports and imports
The current implementation aligns with the intended architectural design.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any direct dependencies or imports of IssueWidget in core extensions
# to ensure proper separation
# Search for any potential coupling between issue widget and core extensions
rg -t ts -t tsx "IssueWidget" "packages/editor/src/core"
# Check if the widget is properly isolated to document-specific features
ast-grep --pattern 'import { $_ } from "$_/issue-embed/issue-embed-without-props"'
Length of output: 167
Script:
#!/bin/bash
# Let's try a more comprehensive search approach
# Search for IssueWidget references in TypeScript files
rg -t typescript "IssueWidget" packages/editor/src/core
# Search for issue-embed related imports
rg -t typescript "issue-embed" packages/editor/src/core
# Look for any widget-related extensions
fd -e ts -e tsx . packages/editor/src/core --exec grep -l "widget"
# Check the content of core-without-props.ts to understand the context better
cat packages/editor/src/core/extensions/core-without-props.ts
Length of output: 3738
Script:
#!/bin/bash
# Let's examine the issue-embed integration structure
# Check the issue-embed directory content
cat packages/editor/src/core/extensions/issue-embed/issue-embed-without-props.ts
# Look at the widget node implementation
cat packages/editor/src/core/extensions/issue-embed/widget-node.tsx
# Check the index file for exports
cat packages/editor/src/core/extensions/issue-embed/index.ts
# Search for any document-specific imports of IssueWidget
rg --type ts "IssueWidgetWithoutProps" packages/editor/src/
Length of output: 3136
packages/editor/src/core/extensions/read-only-extensions.tsx (3)
32-32: LGTM: Import changes are appropriate
The addition of TExtensions type import is correctly implemented and properly used in the Props interface.
135-137:
Critical: disabledExtensions parameter has no effect
Based on the implementation in packages/editor/src/ce/extensions/core/read-only-extensions.ts, CoreReadOnlyEditorAdditionalExtensions returns an empty array without using the disabledExtensions parameter. This creates a misleading API where extensions appear to be configurable but remain active.
Consider implementing the extension filtering logic. Here's a suggested approach:
// In CoreReadOnlyEditorAdditionalExtensions
export const CoreReadOnlyEditorAdditionalExtensions = ({ disabledExtensions }: Props): Extensions => {
// Filter out disabled extensions from the base extensions
const baseExtensions = [
// ... your base extensions
];
return baseExtensions.filter(ext => !disabledExtensions.includes(ext.name));
};44-45: Verify disabledExtensions usage patterns
Let's ensure the new disabledExtensions parameter is being used consistently across the codebase.
✅ Verification successful
Let me gather more specific information about how disabledExtensions is being used.
The disabledExtensions parameter is implemented correctly
The implementation of disabledExtensions is consistent and well-structured across the codebase:
- It's properly typed as
TExtensions[]in the core types - It's correctly passed through component hierarchies from editor wrappers to core extensions
- The feature is used consistently in both read-only and regular editor components
- Extensions are conditionally included/excluded based on the
disabledExtensionsarray (e.g., slash-commands, enter-key)
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check usage patterns of disabledExtensions
# Find all files that might use disabledExtensions
echo "Files potentially using disabledExtensions:"
rg -l "disabledExtensions.*Extensions"
# Check for any direct extension configurations that might conflict
echo "\nPotential conflicting extension configurations:"
rg "configure\(\{" -A 3 -g "*.{ts,tsx}"
# Look for test files to ensure the feature is tested
echo "\nRelated test files:"
fd -g "*read-only*.test.{ts,tsx}"
Length of output: 11828
Script:
#!/bin/bash
# Check how disabledExtensions is used in the codebase
echo "Usage of disabledExtensions in read-only-extensions.tsx:"
rg -A 10 "disabledExtensions" packages/editor/src/core/extensions/read-only-extensions.tsx
echo "\nChecking how disabledExtensions is typed:"
rg -A 5 "disabledExtensions.*:" packages/editor/src/core/types/
echo "\nChecking how disabledExtensions is used in other components:"
rg "disabledExtensions" packages/editor/src/core/components/
Length of output: 4614
packages/editor/src/core/extensions/extensions.tsx (3)
36-38: LGTM: Import changes are well-organized
The new imports for TExtensions and CoreEditorAdditionalExtensions are properly placed and support the new extension disabling functionality.
52-53: LGTM: Improved type safety with explicit return type
The explicit Extensions return type enhances type safety and code clarity.
169-171: Verify impact of disabled extensions
The ability to disable extensions could affect core editor functionality. Please ensure:
- Core extensions required for basic editing can't be disabled
- Dependencies between extensions are properly handled
- UI gracefully handles disabled extension features
Let's check for extension dependencies and usage:
✅ Verification successful
Let me try a different approach to gather information about the extensions and their dependencies.
Let me try one more time with corrected file type flags:
Based on the search results, I can now provide a final response:
Disabled extensions implementation is safely handled
The codebase shows a well-structured approach to handling disabled extensions:
- Core editing functionality is preserved through
StarterKit.configure()inCoreEditorExtensions, which provides essential editing capabilities - Additional extensions are handled separately through
CoreEditorAdditionalExtensionswhich returns an empty array by default, making it safe to disable - The implementation includes proper checks before enabling optional features (e.g.,
if (!disabledExtensions?.includes("slash-commands"))) - UI gracefully adapts through the editor components which conditionally render features based on disabled extensions
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for extension references and dependencies
echo "Searching for extension references..."
rg --type typescript --type tsx "StarterKit|CustomQuoteExtension|CustomHorizontalRule|CustomKeymap|ListKeymap|CustomLinkExtension|CustomTypographyExtension|ImageExtension|CustomImageExtension|TiptapUnderline|TextStyle|TaskList|TaskItem|CustomCodeBlockExtension|CustomCodeMarkPlugin|CustomCodeInlineExtension|Markdown|Table|TableHeader|TableCell|TableRow|CustomMention|Placeholder|CharacterCount|CustomTextAlignExtension|CustomCalloutExtension|CustomColorExtension" -A 2
echo "Checking for extension configurations..."
ast-grep --pattern 'configure({
$$$
})'
Length of output: 726
Script:
#!/bin/bash
# Search for extension definitions and their dependencies
echo "Searching for extension definitions..."
rg -t js -t jsx -t ts -t tsx "StarterKit.*configure|CoreEditorAdditionalExtensions" -A 5
echo "Searching for disabledExtensions usage..."
rg -t js -t jsx -t ts -t tsx "disabledExtensions" -A 3
echo "Checking extension imports..."
rg -t js -t jsx -t ts -t tsx "^import.*Extension" -B 1 -A 1
Length of output: 540
Script:
#!/bin/bash
# Search for extension definitions and their dependencies
echo "Searching for extension definitions..."
rg --type-add 'ts:*.{ts,tsx}' -t ts "StarterKit.*configure|CoreEditorAdditionalExtensions" -A 5
echo "Searching for disabledExtensions usage..."
rg --type-add 'ts:*.{ts,tsx}' -t ts "disabledExtensions" -A 3
echo "Looking for core extensions..."
rg --type-add 'ts:*.{ts,tsx}' -t ts "export.*CoreEditorExtensions|export.*CoreEditorAdditionalExtensions" -A 10
Length of output: 34305
packages/editor/src/core/extensions/slash-commands/command-items-list.tsx (1)
59-62: LGTM! Clean function signature update.
The change to use an args object pattern improves extensibility and makes the function more maintainable.
packages/editor/src/core/extensions/slash-commands/command-items-list.tsx
Show resolved
Hide resolved
packages/editor/src/core/extensions/slash-commands/command-items-list.tsx
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
packages/editor/src/core/extensions/slash-commands/command-items-list.tsx (1)
292-304: Improve null check in options handlingWhile the index handling is now correct, the optional chaining operator (
?.) on the array is unnecessary since the spread operator already handles undefined values.Consider this improvement:
- [ - ...(additionalOptions ?? []), - ...coreEditorAdditionalSlashCommandOptions({ - disabledExtensions, - }), - ]?.forEach((item) => { + [ + ...(additionalOptions ?? []), + ...coreEditorAdditionalSlashCommandOptions({ + disabledExtensions, + }), + ].forEach((item) => {
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
packages/editor/src/core/extensions/slash-commands/command-items-list.tsx(4 hunks)
🔇 Additional comments (3)
packages/editor/src/core/extensions/slash-commands/command-items-list.tsx (3)
42-57: LGTM! Type safety improvements
The new types and imports enhance type safety and properly structure the function parameters.
59-62: LGTM! Improved parameter handling
The function signature change and args destructuring enhance code clarity and maintainability.
214-214:
Revert section key changes to maintain compatibility
The changes from 'text-color' to 'text-colors' and 'background-color' to 'background-colors' will break existing functionality as the codebase still uses the singular form extensively.
Also applies to: 255-255
Summary by CodeRabbit
Release Notes
New Features
disabledExtensionsproperty across various editor components, allowing users to specify which extensions should be disabled.Bug Fixes
Documentation
disabledExtensionsas a required property in relevant interfaces.Refactor