Where BaseUI is used?

BaseUI is the design system library that mostly used in Wix editors.

This article explain in details, where is the BaseUI accountability and responsibility. The goal here to clearly what need review and approve by BaseUI team and also to help other teams to understand where they must use baseUI library.  

If you are looking to learn how BaseUI work as library, please see this article: How BaseUI works?
Important
Not everything in Wix editors is using BaseUI library. The editor frames (workspace) can reuse parts from BaseUI library, for example using buttons in the top header or icons anywhere in the workspace, but it's not BaseUI accountability.

Base UI in Editor classic

Editor classic, list of areas for base UI ownership
  • Floating settings panels (setting are all panels open from GFPP/right click triggers.
  • Pop-ups 
  • Most reuse-able areas 

What is using Base UI

Floating settings panels

BaseUI design system was built primarily for floating panels and that's our main focus and ownership.
Everything inside floating panels should be using base UI composites.
Including verticals and TPAs panels.

Example of a floating panel in editor classic.

* Note that some verticals and TPAs are not using base UI yet and therefor will not be supported.
See example in 'not using base UI' areas.


Popups

Popups should be triggered using platform api and everything inside should be using BaseUI components or composites.

Example for 'Message Modal' in editor classic.


Reusable Areas

In some cases in areas that are not usually part of base UI logic as floating panels but are have potential to be reused across the editors - will be determined by base UI team.

Example for Velo 'Tree' components in editor classic. 


What's not using BaseUI

Workspace

Workspace areas like: Top Bar, Left Panels, Toolbar or even Velo are mostly using base UI atoms or components, but are not part of Base UI ownership. 

The editors (Classic, X & Builder) can consume any part from base UI to build their tools, sometimes they do that and sometimes they don't. 

The idea is to give the editor the freedom to reuse any part from base UI, but these parts are not the goal of base UI. for example add panel can use the vertical navigation, or they can use something else if they need to.

*Note: Base UI will not be support and maintain the cases mention above. 
however it's recommended to use base UI atoms, components or even composites if possible to allow the editor save time.

Example for 'Add Panel' in editor classic.


Stage

Stage elements like gfpp buttons, bounding box, rulers etc.. are not part of base UI.

Example for 'bounding box' in editor classic.


Verticals & TPAs using UI-Lib

Some verticals and TPAs are not use BaseUI but a deprecated library called UI-Lib, it's mandatory that any new vertical panel will be using BaseUI library.

Example for 'wix music' in editor classic.


Non-Reusable Areas

Not all areas in the editor including components inside floating settings panels and modals are reusable enough to be added to the library. 

*Adding new components to the library or not will be decided by base UI team.

Example for "Gallery image organizer" in editor classic.


BaseUI in Editor X

Editor X, list of areas for base UI ownership
  • Floating settings panels (setting are all panels open from GFPP/right click triggers)
  • Inspector
  • Pop-ups
  • Most reuse-able areas


What is using BaseUI

Floating Settings Panels

Everything inside floating settings panels should be using base UI composites.
Including verticals and TPAs panels.

Example of a floating panel in editor x.

* Note that some verticals and TPAs are not using base UI yet and therefor will not be supported.
See example in 'not using base UI' areas.


Inspector

In addition to floating settings panels Editor X uses the inspector for stage component properties.
Almost everything in the inspector uses BaseUI.

Example of the 'inspector panel' in editor x.

Popups

Popups should be triggered using platform api and everything inside should be using BaseUI components or composites.

Example for 'Message Modal' in editor x.


What's not using BaseUI

Workspace

Workspace areas like: Top Bar, Left Panels or even Velo are mostly using base UI atoms or components, but are not part of Base UI ownership. 

The editors (Classic, X & Builder) can consume any part from base UI to build their tools, sometimes they do that and sometimes they don't. 

The idea is to give the editor the freedom to reuse any part from base UI, but these parts are not the goal of base UI. for example add panel can use the vertical navigation, or they can use something else if they need to.

*Note: Base UI will not be support and maintain the cases mention above. 
however it's recommended to use base UI atoms, components or even composites if possible to allow the editor save time.

Example for 'Add Panel' in editor x.


Stage

Stage elements like gfpp buttons, bounding box, rulers etc.. are not part of base UI.

Example for 'bounding box' in editor x.


Non-Reusable Areas

Not all areas in the editor including components inside floating settings panels and modals are reusable enough to be added to the library. 

*Adding new components to the library or not will be decided by base UI team.

Example for "focal point" component in editor x.


Base UI in Blocks

Wix Blocks are uding Editor X framework (production is still using classic) and therefor are also using BaseUI with X skin.
Wix Blocks list of areas in base UI ownership:
  • Floating settings panels (setting are all panels open from GFPP/right click triggers)
  • Pop-ups
  • Most reuse-able areas