Intensive reading of Bi construction – screening conditions

Time:2021-8-20

Screening conditions are the core concept of Bi construction. Most of the exploratory analysis and chart linkage we mentioned also belong to the category of screening conditions,Its essence is that one component filters the data query of another component

How does the filter component work

The most common filter condition is the query control of the form scenario, as shown in the following figure:

Intensive reading of Bi construction - screening conditions

Several components with “output capability” are used as filtering components. Clicking the query button triggers their active components to retrieve data again.

Note that components with “output capability” here are not only input components such as input boxes, but also all components with interactive capability, and even ordinary components can undertake the ability of filtering and triggering:

Intensive reading of Bi construction - screening conditions

Clicking on the header of a table can also trigger the filtering behavior, or clicking on a column of the histogram, as long as this level of abstraction is carried out,The linkage between components is also a screening behavior in nature

Equally important, the filtering component can also be a component with input capability:

Intensive reading of Bi construction - screening conditions

When the target component is a component with filtering capability, this is the filtering linkage scenario, soScreening linkage also belongs to common screening behavior。 As for whether to modify the filter value immediately after the target component triggers data retrieval, and then trigger subsequent filter linkage, it is entirely determined by the business characteristics.

A component can also interact with its own filtering. For example, the scenario of clicking drill down in a broken line chart is an example that triggers the filtering and acts on itself.

What is a filter component

Any component can be a filter component

The components with input characteristics, such as input box, drop-down box and date selector, may be the easiest to understand. These components can only be said to be naturally suitable as filtering components, but they do not mean that the system design should deal with these components in a special way.

Think about it. In fact, ordinary buttons, tables, line charts and so onComponents with presentation properties also have the side of input propertiesFor example, when a button is clicked, a query is triggered, when a cell is clicked, you want to query the data trend of the current city, when a line in a line chart is clicked, you want to drill down from year to month, and so on.

thereforeThere is no concept of filtering components, but any component has the ability to filterTherefore, filtering is the ability of any component, not limited to a few components. Once designed in this way, the following can be achieved:

  1. Realize the screening from input class components to display class components, which meets the basic screening requirements.
  2. It realizes the filtering from display components to display components, which belongs to the advanced function of chart linkage chart.
  3. It implements the filtering from input class components to input class components, which belongs to the filtering linkage function.
  4. Realize the screening from the component itself to itself and realize the tripping function.

The following describes the filter condition design of Bi designer.

Filter condition design

Based on the above analysis, Bi designer does not add the so-called filtering component type to the component meta information, but sets it as a filtering capability, which can be triggered by any component.

How to trigger filtering

Component callonFilterChangeTo complete the filtering action:

import { useDesigner } from "@alife/bi-designer";  
  
const InputFilter = () => {  
  const { onFilterChange } = useDesigner();  
  
  return (  
    <input onChange={(event) => () => onFilterChange(event.target.value)} />  
  );  
};  

But this development method violatesLow invasionWe can use the way of component and engine deconstruction to directly call when the input box changesprops.onChange, this component maintains maximum independence:

const InputFilter = ({ onChange }) => {  
  return <input onChange={(event) => () => onChange(event.target.value)} />;  
};  

How does the rendering engineonFilterChangeMap toprops.onChangeAnd? Configure DSL as follows:

{  
  "props": {  
    "onChange": {  
      "type": "JSExpression",  
      "value": "this.onFilterChange"  
    }  
  }  
}  

Which components are affected by filtering

Generally, the filter component will select the target component to act on, similar to the following figure:

Intensive reading of Bi construction - screening conditions

This information is stored in the component configuration of the filtering component, i.ecomponentInstance.props, filter target componentscomponentMeta.eventConfigsEvent configuration of component meta information:

import { Interfaces } from "@alife/bi-designer";  
  
const componentMeta: Interfaces.ComponentMeta = {  
  eventConfigs: ({ componentInstance }) =>  
    componentInstance.props.targets?.map((target) => ({  
      //   Filter access  
      type: "filterFetch",  
      //   Trigger component  
      source: componentInstance.id,  
      //   Action component  
      target: target.id,  
    })),  
};

As shown above, it is assumed that the action on the component is stored inprops.targetsField, we put itmapSet tofilterFetchType, indicating the role of filtering,sourceThe trigger source is itself,targetThe target component is storedtarget.id

So whensourceComponent calledonFilterChangetargetThe component will trigger fetching and get the filter component information and filter value in the fetching parameters.

How do components perceive filter criteria

Component retrieval is combined with filter criteria, as long as it is set as abovefilterFetch, the rendering engine will automatically calculate the callback function of fetching parametersgetFetchParamAdd infiltersRepresents filtering component information, which can be combined with itselfcomponentInstanceAndfiltersDerive final retrieval parameters:

Intensive reading of Bi construction - screening conditions

Finally, only one component meta information is writtengetFetchParamJust call back the function,You can automatically get the filtering components acting on it, regardless of which configurations cause the association, as long as you deal with the filtering function responsively

import { Interfaces } from "@alife/bi-designer";  
  
const componentMeta: Interfaces.ComponentMeta = {  
  //   Assembly access parameters  
  getFetchParam: ({ componentInstance, filters }) => {  
    //   combination   componentInstance   And   filters.map...   Return fetching parameters  
  },  
};

Frequent data retrieval caused by linkage between filtering components

For complex scenarios with filtering linkage, you will encounter the problem of frequent data retrieval.

It is assumed that the national, provincial and municipal linkage screening conditions are at the same timefilterFetchIt is used for a table. The filter criteria for accessing data in this table need to include three parameters: country, province and city, but we set the filter criteria among the three filter components: country, province and cityfilterFetchAs a screening linkage, the screening value will change three times after the country is switched, the province is changed, and the linkage city is changed. However, we only want the table component retrieval function to execute only the last time. What should we do?

Intensive reading of Bi construction - screening conditions

As shown in the above figure, in fact, each filter condition also stores one in the rendering engine data streamreadyStatus, indicating whether the filter criteria are ready,There is only one filter criteria associated with a componentreadyNot fortrue, the component will not trigger fetching

Therefore, we need to always ensure the security of a filtering component in the process of filtering changesreadybyfalse, when the linkage between filters is completed, all filtersreadybytrueThe data will be retrieved by the component. We can use itfilterReadyFilter dependency configuration:

import { Interfaces, createComponentInstancesArray } from "@alife/bi-designer";  
  
const componentMeta: Interfaces.ComponentMeta = {  
  eventConfigs: ({ componentInstance }) =>  
    componentInstance.props.targets?.map((target) => ({  
      //   Filter ready dependencies  
      type: "filterReady",  
      //   Trigger component  
      source: componentInstance.id,  
      //   Action component  
      target: target.id,  
    })),  
};

After this configuration, whensourceComponent triggeronFilterChangeAfter,targetFiltering of componentsreadyWill now be set tofalse, onlytargetIt is triggered automatically after the component fetches dataonFilterChangeWill put their ownreadyReset totrueThat’a all, other processes have no perception

Several filter components are aggregated into a query control

In addition to linkage, there will also be demands to prevent frequent queries. You want to bind multiple filter criteria into a large filter component and retrieve the data when you click the “query” button:

Intensive reading of Bi construction - screening conditions

Can useFilter scopeIt’s easy to do this in just two steps:

Filter component set independent filter scope

import { Interfaces } from "@alife/bi-designer";  
  
const componentMeta: Interfaces.ComponentMeta = {  
  //   adopt   componentInstance   Judge. If it is internal to the global filter, set   filterScope  
  filterScope: ({ componentInstance }) => ["my-custom-scope-name"],  
};

In this way, this batch of filter components are different from their componentsFilter scopeTherefore, the filtering will not take effect immediately, and the function is half realized.

Called when the confirm button is clickedsubmitFilterScope

import { useDesigner } from '@alife/bi-designer'  
  
const componentMeta: Interfaces.ComponentMeta = {  
  const { submitFilterScope } = useDesigner()  
  //   When you click the confirm button, call   submitFilterScope('my-custom-scope-name')  
};

You can call after clicking the query button.submitFilterScopeAnd pass in the corresponding scope name, so that the filtering component in the scope will immediately filter ittargetThe component is in effect.

As for the confirmation button and the aggregation on the UI, you can write a custom component to do itComponentLoaderAggregate the filtering components and load them together. In short, the function is decoupled from the UI.

If you are interested in the principle, you can take another look at this diagram:

Intensive reading of Bi construction - screening conditions

Breakthrough filter scope

However, in the actual scenario, there may be more complex combinations, as shown in the following example:

Intensive reading of Bi construction - screening conditions

Filter 1 can filter filter filter 2 and table at the same timefilterFetchHowever, the effect on the table is expected to be blocked by the query button, while the effect on filter 2 is expected to take effect immediately. For this example, there are two ways to solve it:

The simplest way is to set filter 1 and filter 2 to the same scopegroup1In this way, the effect is naturally realized through scope segmentation,And this is essentially an example of two filter UIs that are not together, but have the same filter scope

Intensive reading of Bi construction - screening conditions

However, for another change, if filter 2 also filters the table, we will put filter 1 and filter 2 into the same tablegroup1Queries equal to tables will be controlled by the query button, butWe also want filter 2 to act on the table immediately

Intensive reading of Bi construction - screening conditions

As shown in the figure, we can only set the filtering scope of filter 1 togroup1In this way, filter 2 and the table belong to the same filtering scope, and the filtering between them will take effect immediately. We just need to solve the problem that filter 1 cannot act on filter 2 immediatelyignoreFilterScopeHow to break through the filtering scope:

import { Interfaces } from "@alife/bi-designer";  
  
const componentMeta: Interfaces.ComponentMeta = {  
  eventConfigs: ({ componentInstance }) =>  
    componentInstance.props.targets?.map((target) => ({  
      //   Filter access  
      type: "filterFetch",  
      //   Trigger component  
      source: componentInstance.id,  
      //   Action component  
      target: target.id,  
      //   Breakthrough filter scope  
      ignoreFilterFetch: true,  
    })),  
};

We just have toSource: filter 1 Target: filter 2YesfilterFetchIn configuration, theignoreFilterFetchSet totrue, thisfilterFetchThe filter scope will be ignored to achieve the effect that filter 1 immediately acts on filter 2.

summary

What are your special screening demands? Can this screening design be used to solve the problem?

The discussion address is: Intensive Reading of Bi construction – screening conditions · issue #270 · DT Fe / weekly

If you want to participate in the discussion, please click here. There are new topics every week, published on weekends or Mondays. Front end intensive reading – help you filter reliable content.

followFront end intensive reading WeChat official account

Intensive reading of Bi construction - screening conditions

Copyright notice: Free Reprint – non commercial – non derivative – keep signature (Creative sharing 3.0 License)

Recommended Today

Design pattern | Chapter 1 seven principles of design pattern

catalogue preface 1. Single responsibility principle 1.1 basic introduction 1.2 single responsibility principle, precautions and details 1.3 an example 2. Interface Segregation Principle 2.1 basic introduction 2.2 diagram 2.3 an example 3. Dependency Inversion Principle 3.1 basic introduction 3.2 three methods and examples of dependency transfer 3.2.1 interface transmission 3.2.2 construction method transfer 3.2.3 setter […]