How can the front-end business components better adapt to data sources and state sources, achieve separation of concerns, and achieve higher reusability?

question background

  • We refine the common parts to make reusable business components. Generally, we display the corresponding components by passing data, and we can define several different types and states. Later, there is no problem with reuse according to the design rules.
  • so if there are many modules or applications maintained by different backend developers with different interfaces, can adaptation be done at the front end to keep up with the changes?

give me an example

how can the filtering components, calendar components, and so on of the hotel be reused to other modules such as real estate without any changes to the interface data source?

current situation

  • forgive me for being stupid and have no ideas, but is it possible to forcibly transform the data structure into a usable data structure after tedious steps when receiving data? Complex algorithms are completely rookies
  • now I mainly do Mini Program development, but I don"t limit the scope of the technology stack. The ideas and principles are the same

thanks for the invitation. If the problem description of the subject is eventually simplified to " how to make the data from the back-end interface available to the same front-end project, and requires the front-end implementation ", then consider using the adapter pattern , that is, adding a layer dedicated to data conversion between the interface return data and the js, so that the interface can remain unchanged. Make a slight change to the front-end project (the change is to dock the transformation layer to minimize the scope of code changes). Take the simplest example:

// service
 
// getDatapromisethen
getData = (params) => {
    return $.get(params)
}

export defult {
    getData 
}

/* ---------------------  ---------------------*/
//  
getData = () => {
 //    
}

const adapter = (func) => {
    return function(params) =>{
          return new Promise(resolve=>{
            func(params).then(result => {
                //,  convert
                const newResult = convert(result)
                resolve(response)
            })
         })
    }
}

export defult {
    getData:adapter(getData) // 
}

in the above example, in theory, you only need to write the convert function clearly, so that the scope of changes can be limited to the current service file. Of course, the specific situation needs to be discussed in detail

.

just write a simple example to attract jade.


Thank you for inviting

the filter component and calendar component written in the main column of the building belong to the basic UI component. Such components are generally in a fixed format, and then pass parameters to render according to the specified format. Similar to components like cube-ui, developers must also code according to their agreed format if they want to use the components.

of course, depending on different background formats, it is best to add a layer of converter to convert to the corresponding format. However, there is a disgusting situation, that is, the parameters worn in the background need to be passed back to the background in the original format, which requires two layers of conversion. In this case, it is better to write a component that passes parameters from one data structure to another


does not require return data format field specification cannot be done, adding middle layer for data processing is not recommended. Internal bindings of components all require key or array traversal (multiple fields or key)

Menu