search

Home  >  Q&A  >  body text

javascript - The webapp business process is basically the same, multiple sets of themes (the styles are basically different, and the interactions are slightly deviated) are managed, and there are constantly new themes. How to design a componentized architecture?

Business scene

A set of single-page applications needs to be connected to different partners, so the UI needs to be adjusted, and sometimes some interactions need to be changed, but the entire process is basically the same.

Currently, we plan to use Vue to reconstruct the project and have separated the public business logic into the business layer. However, when writing page-level components, we found that there are still most reusable codes, such as on the login page:

 // viewModel
{ 
    phoneNum, smsCode, loginbtn
 }

It exists for every version. Basically, you can use a set of viewmodels to describe this business process. I think this part of the repeated code is reusable.

For each new version, most of the changes are styles and a small amount of interactions (there are also many interactions, but the specific business logic process remains unchanged).

Have considered:

Option One:

1.分割viewmodel到各子组件,构建该页面时,引用这些业务组件拼凑,添加/修改样式;
2.子组件间事件通信或动态注册data。
3.交互变更大,新增某个子组件。

However, generally there should be UI components first and then business components. The design here is to have business components first and then UI components.

Option II:

1.先编写ui组件
2.再编写viewmodel对应的流程逻辑
3.引用ui组件,mixin对应逻辑

The ideas are very messy, please give me some opinions, thank you.

曾经蜡笔没有小新曾经蜡笔没有小新2737 days ago868

reply all(2)I'll reply

  • ringa_lee

    ringa_lee2017-05-24 11:38:22

    First of all, please distinguish the concepts of [component] and module. Components are only used to express UI interactions and should not contain business logic such as front-end and back-end requests.

    Specifically speaking, Sass-based site development often needs to deal with this type of [function configurable] requirements. The common process is:

    1. The backend opens the [Function Configuration] interface, and the frontend obtains the [Current Page Configuration Parameters] information when the page is loaded

    2. The front-end encapsulates each business logic into independent JS modules, and provides business functions to the UI layer of Vue through the function of the export module.

    3. The front-end UI layer calls different module functions based on functional configuration.

    Simply put, the development model is consistent with the Vue single-page application. Just add a JS module that defines UI logic based on functional configuration and encapsulate it.

    As for the function of dynamic theme switching, it can also be implemented through the configuration interface. For example, the style field in the configuration interface stores the className prefix that identifies the current business party's theme, and then binds the style prefix to the current page through the :class command. With the corresponding css, theme switching can be easily achieved.

    P.S. Don’t use mixins at the beginning of the project. Mixins can make business logic difficult to find and debug (after mixing in mixins, functions and variables imported from unknown locations can be referenced). The correct approach is to import business modules on demand.

    reply
    0
  • 怪我咯

    怪我咯2017-05-24 11:38:22

    1. Separate ui and functional components (such as network requests, local storage), and the functional components can basically be freely combined;

    2. UI component extraction and splitting, the specific granularity depends on how big the difference is between the subject projects, and the iterative release speed requirements; in reality, it is not that the higher the degree of reusability, the better, the more layers, the execution The lower the efficiency, the greater the chance of error and the higher the difficulty of debugging; a balance point needs to be struck.

    reply
    0
  • Cancelreply