Read this article 📖

You will be:

  1. Understand throughJSONTo configure theel-tableThe columns may not be so beautiful. (Author’s subjective opinion)
  2. Learn some examples of VNode operations. (A little)
  3. Think critically about what we need to trade off when repackaging components within the team.

preface

Hello, I’m Spring brother. I love vue.js, ElementUI, and Element Plus. My goal is to share the most practical and useful knowledge points with you. I hope you can leave work early, finish your work quickly, and feel calm 🐟.

Most of you who use VUE have used the Element family framework, and most of you have used the EL-Table component. And almost everyone encapsulates tables and pages.

However, many people habituallychange the official recommendation of “slot writing” to “JSON array “when encapsulating el-Table.

Something like this:

<template>
  <my-el-table :columns="columns" :data="tableData">
  </my-el-table>
</template>
<script setup>
const columns = [
  {
    prop: 'date'.label: 'Date'.width: '180'
  },
  {
    prop: 'name'.label: 'Name'}]/ /... Other slightly
</script>
Copy the code

But after years of treading in puddles, I had to say it out loud: Stop it! Better packaging skills!

JSONWhat are the disadvantages of type encapsulation?

Disadvantage one: learning cost increases

If you were starting today, which component would you prefer to see in your business code?

I prefer 1 and 4 anyway! The first means that it has rich community support, accurate and clear documentation and demos to draw on. The fourth means you can still rely on official documentation to get around, and can use some of your colleagues’ “enhancements” based on the business.

What about 2 and 3? Maybe my colleague can really do a good package, but if you’re in a small factory, a startup, or even an outsourcing company, it’s more likely that your colleague isn’t reliable. Some of its packages are just for a single business scenario, but you have to deal with a whole new API in order to understand its capabilities, even by looking at its source code to see what the API and capabilities are.

In this scenario, I choose to face the familiar, the officialapi.

Disadvantage 2: Custom content needs to be writtenhfunction

You don’t really like writing h functions in business, do you?

When the simpleJSONWhen the configuration doesn’t fit the product manager’s wild imagination, you may need toel-table-columnMore customization of the content in.

At this point, you may miss the convenience of the slot.

Suppose your product manager asks you to write oneColored state column 。

Which of these two ways would you write it? Also, as the business gets more complex, the readability of h-writing declines exponentially, do you worry?

And, of course, it’s a good idea to use JSX notation to simplify h notation.

JSONWhat are the advantages of type PACKAGE?

Advantage one: can simplify writing? (don’t)

Someone said,”JSONType package, can simplify code writing.”

When I heard this, MY heart was filled with confusion: what on earth can it simplify?

Can you see that? This common encapsulation, as it’s called, is simply a formal transformation: you’re not missing a single attribute, you’re just moving it from here to there.

Even for extreme scenarios, you need to write more code:

/ / from:
<el-table-column show-overflow-tooltip />
/ / to:
{
  'show-overflow-tooltip': true
}
Copy the code

Advantage two: onlyJSONTo implement dynamic columns? (don’t)

I am inI encapsulated Element’s Table.During the discussion,JackLiR8The student raised a question:

To simplify this:

How can encapsulation implement dynamic columns while preserving slot writing?

This is not a difficult question, provided you understand what VNodes are and how to operate them.

I made a simple example, the core code is as follows:

// vue3 is a functional component
const FunctionalTable = (props, context) = > {
  // Get the vNodes in the slot
  const vNodes = context.slots.default()
  / / filter vNodes
  const filteredVNodes = props.visibleKeys == null ? vNodes : vNodes.filter(node= >props.visibleKeys.includes(node? .props? .prop))// Pass attributes transparently to el-table
  return <el-table {. context.attrs} >
    { filteredVNodes }
  </el-table>
}
// vue3 functional component definition props
FunctionalTable.props = {
  visibleKeys: {
    type: Array.default: () = > null}}Copy the code

So that’s dynamic columns, right? Yes. Here is the code to use:

<template>
  <el-button @click="onClick">Give me a change!</el-button>
  <FunctionalTable :data="tableData" :visibleKeys="visibleKeys">
    <el-table-column prop="date" label="Date" width="180" />
    <el-table-column prop="name" label="Name" />
    <el-table-column prop="address" label="Address" />       
  </FunctionalTable>
</template>
<script setup>
/ / other slightly
const visibleKeys = ref(['date'.'name'])
const onClick = () = > {
  visibleKeys.value = ['date'.'name'.'address']}/ / other slightly
// ...
Copy the code

The effect is as follows:

Slot writing is definitely better when you have complex scenes and columns where you need to render all sorts of weird things like tags, popovers, or you need more complex definitions. This is the above demo source => Github source

Three advantages:JSONCan you configure database storage? (I advise you to be careful)

“If I save the JSON configuration of the column in the database, I don’t have to write code!”

Dude, I call dude!

Unless you’ve packaged a very sophisticated visual configuration scheme, When the business needs a new column, don’t you write it? The server and operations don’t write the code for you.

It’s just that the place where you store your code, instead of Git, is a database.

On a lazier server, you’ll need to install database linking software and add the task of writing SQL update statements.

Even scarier, you lose the ability to track code versions.

“Why is the production/test/development inventory data different, who should be used, I don’t know what version of this field is, why is it added by whom….”

You may miss git commit-msg at that moment.

What kind of encapsulation do I expect?

If you want to design an “Element UI” or” Element Plus” that solves some pressing problems, optimizes some writing, standardizes some formatting, and makes your team members happy to use the component library. I think you might want to consider the following:

  • Is its API simple and easy to learn (even most of itelementExactly the same)?
  • Does it really simplify business writing?

    Such as theform 和 The pagerMerge, such as provideRequest methodAs apropEtc are encapsulation that can greatly reduce business complexity.
  • Is it scalable and easy to maintain?apiIs the design stylistically consistent with the project?

    In the same project,render/jsx/templateMixing is likely to be difficult for some newcomers.
  • Is it incremental and incremental?

    I don’t want it when I try to useelementUII suddenly realized that the component my colleague had packaged did not support a feature!

Avoid spraying statement

All the above illustrations and texts are my personal opinions.

If you think they’re wrong, they’re wrong.

As for my initial objections to jsonization of the Element table column, I did get tired of having to go over and over my former colleagues’ lousy wrappers on different teams and companies, trying to understand what they did, whether the spelling was changed, whether the features were lost, and learning apis all over again that had no value in learning.

I want you to have a good experience writing code.

When you encapsulate a component, you can encapsulate a component that “works”, “works”, and “everyone wants to use”.