What are data-driven components?

In fact, at present, only HEYUI component library is the attempt of this way, which is also the result of my slow thinking in the process of designing the component library. So, no one has used this definition yet. Of course, this is what sets HEYUI apart from other component libraries. Those who are not familiar with HEYUI can take the following steps: HEYUI official website. Or take a look at our self-introduction article: HEYUI, the new VUE component library released.

preface

A lot of people are confused about what I wrote about the config global configuration for HEYUI. So, today’s article is intended to detail what exactly is HEYUI a “data-driven component”? And the global configuration triggered by data-driven components is used.

Two-way data binding

Before we talk about components, let’s talk about data bidirectional binding. Instead of using jquery to manipulate the DOM for all of our interactions, we’re using two-way data binding for our front-end interactions. So why are more and more people choosing to use two-way binding? Because we wanted to only deal with the logic of the interaction, the dom changes caused by the logic could be made automatic, and our development speed and code quality would be greatly improved. Back in the day, we changed one value, jquery changed the display in one place, changed the display in a second place, and sadly missed a third change.

Similarly, let’s talk about data-driven components.

Data-driven components

We’ve simplified the DOM on top of two-way data binding, and we’ve even gotten rid of jquery. More and more components are being developed based on bidirectional binding.

So what’s the difference between a data-driven component and a normal component? First of all, I’d like to ask, what are most front-end components for?

My answer is: give the user a set of data and let the user choose

I’ll take the global configuration I wrote in Heyui to illustrate:

  • One to five options are available: Radio or Select
  • Select multiple options from 1 to 5: Checkbox, or Select(multiple)
  • 5 to 15 Options Single or multiple options: Select
  • 15 to 40 single/multiple options: Select(Filterable) or AutoComplete
  • 40 + or remote fuzzy queries required: AutoComplete
  • Data selection with hierarchical information: TreePicker

No matter what the design looks like, the data and interactions are consistent. I don’t care what the components look like, what we’re trying to do is help you encapsulate the data and the internal interaction mechanism so that you can develop according to your own needs, instead of having to write the same logic over and over again.

Let’s use an example to illustrate.

The sample

Online code & run: codesandbox. IO/s/a lot/vv…

Simple application

Let’s use the example of Demo1 to illustrate. All components are handled by datAS.

<template>
  <Select v-model="value" :datas="options" placeholder="Please select"></Select>
</template>

<script>
export default {
  data() {
    return {
      / / heyui also supports a variety of data format, details are available at http://www.heyui.top/component/data/plugin/select
      options: [ { key: "a".title: "Golden cake" }, { key: "b".title: "Double skin milk" }, { key: "c".title: Oyster omelet }, { key: "d".title: "Dragon beard noodles" }, { key: "e".title: "Peking Duck"}].value: "a"}; }};</script>
Copy the code

Let’s look at the element examples, including iView and Ant-Design.

<template>
  <el-select v-model="value" placeholder="Please select">
    <el-option
      v-for="item in options"
      :key="item.value"
      :label="item.label"
      :value="item.value">
    </el-option>
  </el-select>
</template>

<script>
  export default {
    data() {
      return {
        options: [{key: "a".title: "Golden cake" }, { key: "b".title: "Double skin milk" }, { key: "c".title: Oyster omelet }, { key: "d".title: "Dragon beard noodles" }, { key: "e".title: "Peking Duck"}].value: ' '}}}</script>
Copy the code

The main difference here is that we don’t tag option. In fact, option tag writing, or inherited HTML native mode of thinking mode.

If you look closely at the Heyui select component, you will see that we set the behavior of the select through radio, dual, and “please select” options, while the source of the select itself is set through dict. For those interested, check out the HeyUI Select component.

Code instructions

1. Show data-driven components

By using datAS data, we can render different components.

The code directory: SRC/components/demo/datas

2. Define dictionaries

Code directory: SRC /js/config/dict-config.js

3. Use dictionary configuration

Code directory: SRC /components/demo/dict

4. More applications


advantage

Less repetitive code

Select and other components, the principle of the above are key and title data, and then select. Of course, we also have more complex presentation forms, which Heyui supports.

<Select v-model="value" :datas="options" placeholder="Please select"></Select>
Copy the code
<el-select v-model="value" placeholder="Please select">
    <el-option
      v-for="item in options"
      :key="item.value"
      :label="item.label"
      :value="item.value">
    </el-option>
</el-select>
Copy the code

When you reuse select over and over in your system, you’ll find that your code is extremely concise.

Code readability

When you write a large Form, the code is reduced to one component per line, which makes our code very readable. In some cases, you only need to worry about the v-model binding functions, eliminating countless for loops.

Code controllability

Centralized configuration, better invocation, and better maintenance with dict Config, a common dictionary. In code writing, you only need to configure the dict attribute.

Background photo –LAN (zoige, Sichuan province)