Sb/whitelabel UI

[smuun]

Important

Introduces customizable UI elements in script-related components using a customUi configuration, allowing for tailored user interfaces.

• UI Customization:
  • Introduces customUi configuration in ScriptBuilder, ScriptEditor, DisplayResult, EditableSchemaForm, EditorBar, LogPanel, and Tooltip components.
  • Allows enabling/disabling specific UI elements like tooltips, download buttons, and variable pickers.
  • Supports different configurations for old, new, and no whitelabel UI in test_dev_page/+page.svelte.
• Components:
  • DisplayResult.svelte: Adds customUi prop to control AI fix and download options.
  • EditableSchemaForm.svelte: Adds customUi prop to control JSON view and variable picker.
  • EditorBar.svelte: Adds customUi prop to control context variable, resource, and reset buttons.
  • ScriptBuilder.svelte: Integrates customUi for top bar, settings panel, and editor bar.
  • ScriptEditor.svelte: Integrates customUi for editor bar and preview panel.
  • LogPanel.svelte: Adds customUi prop to control history and trigger captures.
  • Tooltip.svelte: Adds customUi prop to disable tooltips.
• Types:
  • Defines ScriptBuilderWhitelabelCustomUi, ScriptEditorWhitelabelCustomUi, EditorBarUi, PreviewPanelUi, DisplayResultUi, EditableSchemaFormUi, SettingsPanelUi, and SettingsPanelMetadataUi in custom_ui.ts.

^{This description was created by for 07563df. It will automatically update as commits are pushed.}

[github-actions]

Thank you for your submission, we really appreciate it. Like many open-source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution. You can sign the CLA by just posting a Pull Request Comment same as the below format.

---

I have read the CLA Document and I hereby sign the CLA

---

_{You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot.}

[ellipsis-dev]

👍 Looks good to me! Reviewed everything up to 537c88f in 3 minutes and 1 seconds

More details

• Looked at 925 lines of code in 12 files
• Skipped 0 files when reviewing.
• Skipped posting 15 drafted comments based on config settings.

1. frontend/src/routes/test_dev_page/+page.svelte:84

• Draft comment:
  Using a reactive assignment to update the customUi and then updating globalUiConfig inside the reactive block might introduce subtle race conditions. Consider moving the globalUiConfig update into a dedicated function or reactive store derived from customUi.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50%
  In Svelte, reactive statements are handled in a deterministic order based on their dependencies. Since the second reactive block explicitly depends on customUi, Svelte will ensure it runs after customUi is updated. The comment seems to misunderstand how Svelte's reactive system works - there shouldn't be race conditions here.
  I could be wrong about Svelte's reactive system guarantees. Maybe there are edge cases I'm not considering.
  Svelte's documentation and implementation explicitly guarantee that reactive statements run in dependency order, making race conditions impossible in this scenario.
  The comment should be deleted because it incorrectly suggests there could be race conditions in a scenario where Svelte's reactive system prevents them by design.

2. frontend/src/routes/test_dev_page/+page.svelte:109

• Draft comment:
  The inline script object used for the ScriptBuilder component seems hard-coded for testing. Verify if this should later be made configurable or fetched from a service to avoid potential inconsistencies in production.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50%
  The comment is asking the PR author to verify if the inline script object should be made configurable or fetched from a service. This falls under asking the author to confirm their intention or ensure behavior, which is against the rules.

3. frontend/src/lib/components/custom_ui.ts:113

• Draft comment:
  Custom UI type definitions seem comprehensive. Verify that all optional properties (e.g. 'editorBar' and 'previewPanel') are used consistently in the components to avoid type mismatches.
• Reason this comment was not posted:
  Confidence changes required: 30% <= threshold 50%
  None

4. frontend/src/lib/components/Tooltip.svelte:18

• Draft comment:
  Consider handling the case when globalUiConfig is not yet initialized; the use of !$globalUiConfig?.tooltips?.disabled is good, but ensure that the default behavior (e.g. tooltips enabled) is well defined.
• Reason this comment was not posted:
  Confidence changes required: 40% <= threshold 50%
  None

5. frontend/src/lib/components/DisplayResult.svelte:432

• Draft comment:
  Good use of customUi.aiFix flag to conditionally render the copilot fix slot. This pattern provides flexibility for whitelabeling.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50%
  None

6. frontend/src/lib/components/EditableSchemaForm.svelte:57

• Draft comment:
  Introducing the customUi prop (of type EditableSchemaFormUi) to drive JSON-only and variable picker behavior is a nice extension for whitelabeling.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50%
  None

7. frontend/src/lib/components/EditorBar.svelte:85

• Draft comment:
  Conditional rendering for resource picker based on customUi.resource != false is clear. Consider verifying consistency of boolean checks throughout.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

8. frontend/src/lib/components/ScriptBuilder.svelte:172

• Draft comment:
  Filtering the script languages using customUi.settingsPanel.metadata.languages is a good approach. Ensure the supported language list is kept in sync with documentation.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

9. frontend/src/lib/components/ScriptSchema.svelte:15

• Draft comment:
  Pass the customUi property to EditableSchemaForm so that whitelabel options apply to schema editing; this enhances consistency with new UI configuration.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50%
  None

10. frontend/src/lib/components/Tooltip.svelte:18

• Draft comment:
  Using $globalUiConfig to disable tooltips globally is a clean solution. Verify that the scale transformation computed from customSize works across different UI themes.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50%
  None

11. frontend/src/lib/components/custom_ui.ts:39

• Draft comment:
  The new whitelabel type definitions provide granular control. Consider adding inline comments or documentation to describe each property for future maintainers.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

12. frontend/src/lib/components/schema/SchemaFormDND.svelte:23

• Draft comment:
  Introducing the noVariablePicker prop (passed to SchemaForm) is a good addition for customizability. Ensure its behavior is tested when disabled.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50%
  None

13. frontend/src/lib/components/scriptEditor/LogPanel.svelte:97

• Draft comment:
  The conditional rendering of tabs based on customUi.history and customUi.triggerCaptures is well implemented to support custom whitelabel UI.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50%
  None

14. frontend/src/lib/stores.ts:149

• Draft comment:
  Creating a writable store for globalUiConfig is a straightforward solution to manage global UI settings. Ensure this store is updated consistently across components.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50%
  None

15. frontend/src/routes/test_dev_page/+page.svelte:91

• Draft comment:
  The example whitelabel UI configurations (no/old/new) help visualize the customization options. The reactive block updates globalUiConfig based on customUi.tooltips.disabled, which is a neat implementation.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50%
  None

Workflow ID: wflow_mXAWsqtCTPIH6ZW8

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[smuun]

@ellipsis review this

[ellipsis-dev]

👍 Looks good to me! Reviewed everything up to 07563df in 3 minutes and 20 seconds

More details

• Looked at 966 lines of code in 11 files
• Skipped 0 files when reviewing.
• Skipped posting 26 drafted comments based on config settings.

1. frontend/src/lib/components/DisplayResult.svelte:435

• Draft comment:
  Good use of customUi checks to conditionally render the AI fix and download button. Ensure that the naming of the customUi flags is consistently documented.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50%
  The comment is asking the author to ensure consistency in documentation, which falls under the category of asking the author to double-check or ensure something. This violates the rule against asking the author to ensure something is done.

2. frontend/src/lib/components/EditableSchemaForm.svelte:207

• Draft comment:
  Using customUi?.jsonOnly as boolean for the JSON view is concise; verify that when customUi is undefined it behaves as expected and that disabling the variable picker via customUi works correctly.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50%
  This comment is asking the PR author to verify the behavior of the code when customUi is undefined and to ensure that disabling the variable picker works correctly. This falls under the category of asking the author to double-check things, which is against the rules.

3. frontend/src/lib/components/EditorBar.svelte:429

• Draft comment:
  Conditional rendering for resource picker and reset button based on customUi properties looks good. Double-check property names (e.g. customUi?.resource, customUi?.reset) to ensure they match the definitions in custom_ui.ts.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

4. frontend/src/lib/components/ScriptBuilder.svelte:175

• Draft comment:
  Filtering languages using customUi.settingsPanel.metadata.languages is a clear approach; ensure that type casting for languages is handled properly in all cases.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50%
  This comment is asking the PR author to ensure that type casting is handled properly, which falls under the rule of not asking the author to ensure behavior is intended or tested. It doesn't provide a specific suggestion or point out a specific issue in the code.

5. frontend/src/lib/components/ScriptEditor.svelte:168

• Draft comment:
  The collaboration and test-run integration looks well-organized. Verify that the WebsocketProvider is properly cleaned up on destroy to avoid memory leaks.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

6. frontend/src/lib/components/ScriptSchema.svelte:15

• Draft comment:
  Passing {customUi} to EditableSchemaForm is concise; ensure that the editableSchemaForm options in custom_ui.ts are properly passed down.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50%
  This comment is asking the author to ensure that a specific part of the code is properly implemented. It doesn't provide a specific suggestion or point out a specific issue, but rather asks for a confirmation of correct behavior, which violates the rules.

7. frontend/src/lib/components/Tooltip.svelte:22

• Draft comment:
  The tooltip checks using getContext are clear. Consider whether a fallback should be rendered when tooltips are disabled.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50%
  This is a UI component and the PR author explicitly chose to render nothing when tooltips are disabled. This seems like a reasonable design choice - if tooltips are disabled, you probably don't want any visual indication of them. The comment is speculative ("consider whether...") and questions a UI design decision.
  Maybe in some cases users would want to know that there was additional information available even if they can't see it right now?
  If that was important, it would be a product/UX decision that should be specified in requirements, not suggested in a code review. The current behavior of showing nothing when disabled is a valid implementation.
  Delete this comment as it questions a reasonable UI design choice and is speculative rather than pointing out a clear issue requiring changes.

8. frontend/src/lib/components/custom_ui.ts:89

• Draft comment:
  Type definitions for the custom UI are clear; ensure these types remain in sync with UI flags in all components.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50%
  This comment is asking the PR author to ensure that type definitions remain in sync with UI flags, which is a general reminder rather than a specific code suggestion or issue. It doesn't provide a specific actionable item or point out a specific problem in the code.

9. frontend/src/lib/components/schema/SchemaFormDND.svelte:91

• Draft comment:
  The drag-and-drop configuration using custom dndConfig and dragHandle is neat. Confirm that deepEqual is performant with large schema orders.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

10. frontend/src/lib/components/scriptEditor/LogPanel.svelte:125

• Draft comment:
  Ensure that the download property for LogViewer respects customUi?.disableDownload, and that tooltips for rich display rendering are accessible.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50%
  The comment is asking the author to ensure that certain properties and tooltips are respected and accessible. This falls under the category of asking the author to ensure behavior, which is against the rules. The comment does not provide a specific suggestion or point out a specific issue with the code.

11. frontend/src/routes/test_dev_page/+page.svelte:92

• Draft comment:
  The dynamic selection of whitelabel UI configurations via customUi is well implemented. Verify that UI changes trigger immediate updates in ScriptBuilder.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50%
  This comment is asking the PR author to verify that a specific behavior is intended, which violates the rule against asking for confirmation or verification of intentions. It does not provide a specific suggestion or point out a specific issue with the code.

12. frontend/src/lib/components/ScriptBuilder.svelte:653

• Draft comment:
  The self‐invoking function for determining the default selected tab is a bit dense. Consider extracting this logic into a separate helper function to improve readability and testability.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50%
  The function is moderately complex with multiple conditions, but it's a one-time initialization that's fairly straightforward to understand in its current form. The logic is self-contained and the comments help explain what's happening. Moving it to a separate function would add indirection without significantly improving readability. The testability argument is weak since this is UI initialization code that would rarely need direct testing.
  The comment makes a reasonable point about code organization. A separate function could make the initialization logic more modular.
  However, the current code is already readable and the initialization logic is simple enough that extracting it would add unnecessary complexity through indirection. The testability benefit is minimal for UI initialization code.
  The suggestion would not meaningfully improve the code. The current implementation is clear and appropriate for its purpose.

13. frontend/src/lib/components/ScriptEditor.svelte:167

• Draft comment:
  In the collaboration mode setup, the use of 'wsProvider' (the Yjs WebsocketProvider) can be made clearer by renaming it (e.g. to 'collabProvider'). Also, consider adding more robust error handling during connection and cleanup in onDestroy.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

14. frontend/src/lib/components/Tooltip.svelte:27

• Draft comment:
  The inline style using parseFloat(customSize) could be extracted into a reactive variable for clarity and potential reactivity if customSize changes.
• Reason this comment was not posted:
  Comment was on unchanged code.

15. frontend/src/lib/components/schema/SchemaFormDND.svelte:33

• Draft comment:
  The nullish coalescing in computeItems is a bit redundant. Since Object.keys always returns an array, consider simplifying the expression.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

16. frontend/src/lib/components/scriptEditor/LogPanel.svelte:192

• Draft comment:
  For improved accessibility, ensure interactive buttons (e.g. 'See Result' and 'View logs') have descriptive aria-labels.
• Reason this comment was not posted:
  Confidence changes required: 50% <= threshold 50%
  None

17. frontend/src/lib/components/ScriptEditor.svelte:352

• Draft comment:
  The inferSchema call on the editor's change event might run too frequently if the user is typing. Consider debouncing this function to improve performance.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

18. frontend/src/lib/components/test_dev_page/+page.svelte:87

• Draft comment:
  The UI configuration for whitelabel settings is clear; however, adding comments or documentation on what each option implies may improve maintainability.
• Reason this comment was not posted:
  Confidence changes required: 40% <= threshold 50%
  None

19. frontend/src/lib/components/custom_ui.ts:31

• Draft comment:
  The type definitions are clear. Ensure that any future additions follow the same naming conventions for consistency.
• Reason this comment was not posted:
  Confidence changes required: 20% <= threshold 50%
  None

20. frontend/src/lib/components/DisplayResult.svelte:28

• Draft comment:
  The component is imported as 'ParqetTableRenderer' from './ParqetCsvTableRenderer.svelte'. If this is supposed to refer to the Parquet file format, consider renaming it to 'ParquetTableRenderer' (and updating the file name accordingly) for clarity.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

21. frontend/src/lib/components/DisplayResult.svelte:409

• Draft comment:
  The closing tag seems to be split across two lines (line 409 shows </div and line 410 shows >). It would be clearer and less error-prone to have the tag written fully on one line as </div>. Please adjust the formatting.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

22. frontend/src/lib/components/EditableSchemaForm.svelte:242

• Draft comment:
  Typo: The exported variable 'pannelExtraButtonWidth' is likely misspelled. Consider renaming it to 'panelExtraButtonWidth' for consistency and clarity.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

23. frontend/src/lib/components/EditorBar.svelte:374

• Draft comment:
  Typographical error: the tooltip text for contextual variables contains a duplicate word ('are are'). Please remove the extra 'are' to improve readability.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

24. frontend/src/lib/components/ScriptBuilder.svelte:256

• Draft comment:
  Typo: Please change 'occured' to 'occurred' in the error message.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

25. frontend/src/lib/components/ScriptEditor.svelte:332

• Draft comment:
  Minor typographical error: consider updating the text 'Use VScode' to 'Use VS Code' for consistency and clarity.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

26. frontend/src/lib/components/custom_ui.ts:17

• Draft comment:
  Typographical error: 'sharedDiretory' should be corrected to 'sharedDirectory'.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

Workflow ID: wflow_bQ4Cly9Sl3YLkgyr

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.