github.com/oam-dev/kubevela@v1.9.11/design/vela-cli/vela_top_design_document.md (about)

     1  ---
     2  title: vela top design document
     3  ---
     4  
     5  The directory structure of `vela top` code is as follows:
     6  
     7  ``` shell
     8  ├── component
     9  ├── config
    10  ├── model
    11  ├── utils
    12  └── view
    13  ```
    14  - The component directory stores the relevant definitions of basic components, such as information board components, menu components, logo components, etc. These components will be combined to form the UI interface of the tool.
    15  - The config directory is used to store tool related configuration files, such as color and component size.
    16  - The model directory is mainly used to store the code related to data loading. Each resource can find the corresponding file in this directory, which stores the function to obtain this resource information.
    17  - The utils directory stores general tool functions that will be called by functions in other directories when needed.
    18  - View directory store UI startup file `app.go`, as well as the most important component of the whole tool, namely the resource information table in the middle. This table is actually a component, but because it is the core of the tool, and it will perform multi-level switching and modify the data in the table according to the user's interaction, after the content of the component is refreshed, it can be considered to have entered a new resource view, so we put this component in a separate view directory, Instead of the component directory where the basic components are stored, the refresh of the resource view will trigger the refresh of the menu and bread crumb components, which will be described in detail in the **View** chapter.
    19  
    20  ## Component 
    21  
    22  ### Information board
    23  
    24  The information board component is used to display the basic information of Kubernetes, including the currently used Context, Kubernetes version, and the number of clusters. In addition, the information board will also display the performance information of the KubeVela system, including the versions of Vela Core and Vela CLI, and the running applications in the KubeVela system account for all applications. Proportion, performance information of Vela controller (Vela Core) and Vela gateway (Vela Cluster GateWay) (the ratio of the current usage of CPU and memory to the two set values of request and limit respectively).
    25  
    26  The performance information for the Vela Controller and Vela Gateway here actually comes from the performance information of the Pod where they are located. The function to obtain information about Pod performance (references/cli/top/utils/metrics.go) will be reused in subsequent Pod view. It should be noted that to collect the performance information of the Pod, you need to install the [metrics server](https://github.com/kubernetes-sigs/metrics-server) in the cluster, otherwise the performance information of the pod will not be obtained correctly.
    27  
    28  ### Menu board
    29  
    30  The menu board will generate corresponding menu prompt items according to the key operations that the user can perform in the current view. There are two data structures involved here, `KeyAction` (references/cli/top/model/key_actions.go) and `MenuHint`, for how to render `MenuHint` according to the `KeyAction` in the new view when switching views, you can refer to **View** chapter of the introduction.
    31  
    32  ### Logo board
    33  
    34  The Logo board will display the KubeVela Logo.
    35  
    36  ### Crumbs
    37  
    38  The crumb component is located at the bottom of the entire UI and is used to indicate the hierarchical state of the current view. There are three resource views: Application, ManagedResource, and Pod. There are also two filter views: Cluster and Namespace. There are also Yaml views and help views.
    39  
    40  ### `ViewListener` interface
    41  
    42  The menu component and breadcrumb component above implement a view listener interface `ViewListener`, which contains two methods `StackPop` and `StackPush`, these two methods correspond to when the view will be inserted or exited, the component should take Actions. For specific implementation, please refer to the introduction in the **View** chapter.
    43  
    44  ## View
    45  
    46  The view is the core of the whole tool, and the code is the more complex part of the whole. The following image is the UI architecture of the entire tool, where the position of the view is in the blue `PageStack` position. `PageStack` encapsulates `component.Pages`, `tview.page` in `component.Pages` is responsible for loading views, and the `[]View` array in `model.Stack` is responsible for pushing old views onto the stack like stacks so that when the current view subsequently exits, the old view will be popped stack and rendered again. The `[]ViewListener` array is responsible for saving the components that monitor view switching.
    47  
    48  ![vela-top-view](../resources/vela-top-view.png)
    49  
    50  ### View switch
    51  
    52  The view switching of the resource level can refer to the following image. After selecting a resource in the current resource level, you can enter the more fine-grained resources under the resource by pressing the ENTER key, which exist from Application -> Managed Resource -> Pod has three resource levels. At each resource level, you can use the Y key to view the Yaml text information corresponding to the current resource. In addition, the Managed Resource view can also switch to the Cluster view and the Namespace view to select the corresponding item to filter the Managed Resource resources.
    53  
    54  ![vela-top-view-switch](../resources/vela-top-view-switch.png)
    55  
    56  Specifically, the process of switching the new view is shown in the following figure:
    57  1. First triggered by the user's key operation.
    58  2. Convert the user's keys into corresponding commands.
    59  3. Then render the corresponding view according to the command.
    60  4. Insert the view into app, the view will be initialized first when inserted.
    61  5. The initialized view will then be inserted into `pageStack`, and `pageStack` will notify each component to update its content according to the listener recorded in `[]ViewListener`.
    62  
    63  ![vela-top-view-switch-step](../resources/vela-top-view-switch-step.png)
    64  
    65  ### Resource view
    66  
    67  The resource view is the most frequent type of all views, and the structure of each view is similar, mainly composed of table header and table body, so the life cycle of these views can be abstracted as: first initialize the view, this stage will set the title, Set the border and bind the keys; then build the header and the body of the table. In addition, the content in these tables should be refreshed regularly. Therefore, we abstract the resource view as follows. These views first implement the View interface and have a view. The most basic method, and then implements the ResourceView interface, has the methods used in the entire life cycle of resource view loading data.
    68  
    69  
    70  ![vela-top-resource-view-abstract](../resources/vela-top-resource-view-abstract.png)