Why componentization

Technical modeling needs

Business life cycle, even the same business, different projects will have different business processes. This is the life cycle of the business. But even if seemingly different business processes, such as presale and direct sales, are vastly different, the UI level, presentation structure and content form will have some commonality. If we write the same code for different business models, it will be inefficient and costly to maintain, so at this time we need system abstraction ability to do technical abstraction modeling. One way of thinking about technical abstraction is to abstract business logic with the same layout structure and presentation into front-end components. The use of componentized abstraction is helpful to improve the code reuse rate and thus improve the development efficiency.

The transformation of collaboration model

In the past, the way of collaboration may not be separated before and after, the back end provides data, the front end provides templates, the back end renders into pages, and the View layer is placed in the Java application project, resulting in the front and back ends have permissions on VM operations, blurred functional boundaries, and confusion between business logic and presentation logic. Based on the componentized collaboration model, the designer provides the UI, the front end provides the components modeled from the UI, and the back end provides the data, so that everyone’s communication dimension is limited to the component level. This smaller granularity of communication dimension, centralized management approach, can make collaboration costs lower.

How components are encapsulated

planning

The core meaning of componentization is to extract things that are really reusable, for example

  • Common style
  • controls
  • Stable business logic

Component layering: Common style parts –>> Common components –>> Business components.

The component layer architecture is

style

Components should be self-governing, self-limiting, and mutually exclusive, but if you use CSS to manage styles, there are problems with namespaces. Solutions include:

  • inline style
    • Disadvantages: Cannot use pseudo-class selectors
    • Radium can solve the problem of pseudo-class selector, but also derived incompatible IE8, does not support RN, opacity and other problems.

The overall architecture

There are a few more issues to consider:

  • Where does the data that the component needs come from
    • Write dead inside the component
    • From the HTTP get
      • Disadvantage 1: If a component appears on the same interface more than once, there will be a waste of requests. Each component will generate one request.
      • Disadvantage 2: If the data display component exists on the data configuration page, the data configuration is modified but the component data is not updated.
      • Method: Introduce a layer of store, where each component does not directly request data from the server, but instead fetches data from the corresponding front-end data cache, and lets the cache itself keep in sync with the server.
  • How do components communicate with each other
    • Dispatch-store-view-action –dispatch is used to notify different pages of changes through data flow. It’s actually the data flow pattern that we use with Redux.
  • How do the front and back ends communicate
    • This is done by adding asynchronous data requests to the REDUx data stream, which is dVA effectives

The architecture of the entire application looks like this:

This is the basic idea behind in-app component development, but if the component or component library needs to be used by other projects, consider adding another layer of encapsulation:

  • Unified call mode

Reference: Bought baby front end componentization exploration