[Research] [CCI] OUI Usage Audit in ```console``` plugin

[curq]

I have preformed audit of the console plugin. To start I identified all .scss files and found that custom styling is used in 3 of them (the rest are files with only imports). They are _app.scss, _history.scss and _help.scss. To start, I decided to look through every custom style and investigate what they do.

---

_app.scss

• #consoleRoot, .conApp, .conApp__editor, .conApp__output, .conApp__editorContent, .conApp__outputContent These are styling for the \
  containers with flex that should be replaceable by OUI flex components.
• .conApp__autoComplete Is a classname that used by single \
  element that looks like is no longer used. The same thing was mentioned in comments. https://github.com/opensearch-project/OpenSearch-Dashboards/blob/a8ace28a97f5b178e5e767db03dc8d38046ce14e/src/plugins/console/public/styles/_app.scss#L80-L90
  • .conApp__editorActions, .conApp__editorActionButton, .conApp__editorActionButton--success Used for styling of action buttons. The \ was used insted of OUI components. If replaced less styling will likely be used.
  • .conApp__resizer This is classname for the resizer element (implemented in \ tag) that dynamically changes size of editor and output fields. Not likely to be removable, unless the separate OUI component will be implement later.
  • .conApp__settingsModal Sets min-width: 460px for the EuiModal. This component does accept prop for max-width, but there is no prop for min-width. Might be reasonable to add it to the OuiModal implementation.
  • .conApp__requestProgressBarContainer position styling for the progress bar.
  • .conApp__tabsExtension sets border-bottom: $euiBorderThin;

  ---

  _history.scss

  All stylings are either minor adjustments like overflow: auto;, color: $euiColorMediumShade; or styling for the html elements used as flex container. Some of them can be removed by using OUI components instead.

  ---

  _help.scss

  • .cconHelp__example used for styling example code block \
    container.

  ---

  After analyzing css styles, I investigated usage of native html tags.

  • In a lot of places \
    elements were used as container instead of OUI components.
  • In some files plain \ were used, instead of OuiButton
  • Many html elements were used as part of OUI components like OuiText OuiScreenReaderOnly, where raw html is expected.
  • \
    , \
    • tags used as a container in console/application/containers/editor/legacy/editor.tsx We could possibly replace them with OUI container or list components

    ---

    Conclusion

    A large chunk of the custom styling are aimed to style native html elements, especially containers that use flex. So converting them to OUI will reduce number of custom stylings. Furthermore most if not all native html elements can be converted to OUI, with exception of places where the raw html is expected by the OUI components. Files with native html elements in console/public/application/ (except when used appropriately with OUI):

    • ./components/: console_menu, editor_content_spinner, editor_example
    • ./containers/console_history: console_history, history_viewer
    • ./containers/main: main
    • ./containers/editor/legacy/console_editor: editor_output, editor
    • ./containers/editor: editor

    Suggestions

    Based on my finding I have a few suggestions.

    • Currently OuiFlexItem only have props for flex grow, and not for shrink and basis. While looking through custom styles I noticed that flex: x y z; is often used, so adding support for it might be worth it.
    • As far as I know resizer used in several other places in Dashboards like Data Table Visualization, and it looks like we have OUI component for that OuiResizableContainer, but we don't utilize it here and instead custom component PanelsContainer from opensearch_dashboards_react/public was used. I believe we should switch from it to OUI component. https://github.com/opensearch-project/OpenSearch-Dashboards/blob/ca0bb8f63f5db103c4ea2ca21fd41dc66310d957/src/plugins/console/public/application/containers/editor/editor.tsx#L92-L109
    • Add minWidth option for the OuiModal component. Currently it only got maxWidth prop, so we have to use custom styling to set min-width css property.

    Action Plan

    1. Replace native html elements with OUI components, update tests if applicable.
    2. Review the custom styling and remove unnecessary rules
    3. Report any additional finding or issues.

[BSFishy]

Currently OuiFlexItem only have props for flex grow, and not for shrink and basis. While looking through custom styles I noticed that flex: x y z; is often used, so adding support for it might be worth it.

https://github.com/opensearch-project/oui/issues/776 (for tracking :) )

Add minWidth option for the OuiModal component. Currently it only got maxWidth prop, so we have to use custom styling to set min-width css property.

Do you want to create a feature proposal for this in OUI? If not, I can

[curq]

@BSFishy Yes, I created a feature proposal https://github.com/opensearch-project/oui/issues/783

[joshuarrrr]

@curq Can you add some screenshots to this audit so that it's easier to understand visually and functionally what some of these components and styles are doing?

[joshuarrrr]

At a high level, it may also be worth analyzing this component in the context of https://github.com/opensearch-project/OpenSearch-Dashboards/issues/4160, because dev_tools is the wrapper for this functionality, and fixing it's layout to utilize https://oui.opensearch.org/1.0/#/layout/page may make many of the layout styles here unnecessary. I've also provided some detailed feedback:

consoleRoot, .conApp, .conAppeditor, .conAppoutput, .conAppeditorContent, .conAppoutputContent These are styling for the

containers with flex that should be replaceable by OUI flex components.

Yeah, that's one valid way to go, but I'd wait on https://github.com/opensearch-project/OpenSearch-Dashboards/issues/4160, first.

.conApp__autoComplete Is a classname that used by single

element that looks like is no longer used. The same thing was mentioned in comments.

Yeah, let's remove.

.conAppeditorActions, .conAppeditorActionButton, .conApp__editorActionButton--success Used for styling of action buttons. The was used insted of OUI components. If replaced less styling will likely be used.

Probably OuiButtonIcon for the action buttons.

.conApp__resizer This is classname for the resizer element (implemented in tag) that dynamically changes size of editor and output fields. Not likely to be removable, unless the separate OUI component will be implement later. As far as I know resizer used in several other places in Dashboards like Data Table Visualization, and it looks like we have OUI component for that OuiResizableContainer, but we don't utilize it here and instead custom component PanelsContainer from opensearch_dashboards_react/public was used. I believe we should switch from it to OUI component.

Agree with this approach. Can you also leave a comment linking to that finding on https://github.com/opensearch-project/OpenSearch-Dashboards/issues/4089? It will help whoever picks that up start with the context.

.conApprequestProgressBarContainer position styling for the progress bar. .conApptabsExtension sets border-bottom: $euiBorderThin;

These are likely antipatterns we can get updated design guidance on once we provide screenshots.

All stylings are either minor adjustments like overflow: auto;, color: $euiColorMediumShade; or styling for the html elements used as flex container. Some of them can be removed by using OUI components instead.

We should aim to remove all these styles. Start by moving to OUI components, and then we can see what styles remain.(For example, overflow can be handled by https://oui.opensearch.org/1.0/#/utilities/css-utility-classes, but it's probably not needed at all).

[joshuarrrr]

@curq It sounds like you have a good plan. The next step is to create issues for actually implementing these changes. The first issue could either be to use OuiResizableContainer, or else to start by replacing all the low-level native components with OUI equivalents. You can make multiple issues at once, or you can do it incrementally, making one issue and a PR to solve that problem, and then moving on to the next phase.

[curq]

@joshuarrrr Thank for the feedback! I will take an incremental approach and do it one by one starting with OuiResizableContainer. During working on this first issue I will make sure to capture screenshots for better visual overview. I will update this audit after that.