Hello everyone, I am han Cao 😈, a grass code ape 🐒 who has been working for more than a year. If you like my article, you can follow ➕ to like it and grow up with me. Add my wechat: Hancao97, invite you to join the group, learn and communicate together, and become a better engineer

Where does the story begin

Note: this article for the cold grass 🌿 self attempt, part of the idea is still very young. Big guy do not spray, might as well give advice, exchange ~

Hello everyone, I am small cold grass 🌿 ah!

Why is the minor cold grass ⚡️, because I recently found myself very small, really is to send mayfly in heaven and earth, one of the millet in the sea. I am sorry for the moment of my life, and I envy the endless Yangtze River…

Okay, I’m gonna cut to the chase. I’m gonna cut to the chase. In the middle of last year, my previous honorary team leader shared his experience in component splitting and design with me, and I also learned a lot from him ☀️

A few days ago, WHEN I was developing a project with an intern student, I learned from the experience of the former honorary group leader and did sufficient preliminary design work. However, in fact, some differences were found in the review process after the development was completed.

My initial component design divided components into four categories:

The division scheme here is purely from my experience, slightly immature.

  • Page components: generally do not reuse, that is, the corresponding components of the page, in my eyes, it is equivalent to the motherboard of various components and styles into a whole page
  • Layout component: Pure style reuse, no business
  • Business base ComponentsReference:element-uiComponents of this class are commonly calledxxx-form.xxx-table, exposedapiIt will also be basically consistent with the underlying components
  • Underlying business components: Common services are basically composed of add, delete, modify and check. Such components are also the encapsulation of such granular services. This type of component is commonly called:xxx-creator.xxx-deleter.xxx-updater.xxx-viewer

My next example comes from business base components:

Component TicketForm [ticket-form --props-- disabled {Boolean }
disabledFields { Array<String> }
--events--

--methods--
getData() => TicketData;
setData(ticketData: TicketData) => Undefined;
clearData() => Undefined;
validate() => Promise. <Boolean>;
clearValidate() => Undefined;
--slots--

]
Copy the code

As you can see, I specified the API provided by a business base component, ticket-Form, and the props needed

props:

  • disabled
  • disabledFileds

methods:

  • getData
  • setData
  • clearData
  • validate
  • clearValidate

After that, I entered the development stage, but WHEN I conducted code review, I found that the API implementation was incomplete. At first, I suffered from obsessive-compulsive disorder, but later I thought about it and decided not to restrict it simply through review, because the cost is very high, and the consistent components do not have high review value.

I thought about how to solve the problem, and then after I thought about it for about five minutes, I had the rest of the story.

How will the story continue

Because of my obsessive-compulsive disorder, I desperately want to solve this problem, which I actually define as:

Provide automation solutions to solve common component implementation inconsistencies

First, we need to determine what we have at this stage:

  • The company’s internal base component library (see ElementUI)
  • Implemented business components in the system
  • The component design specification I finalized with my former team leader (regardless of whether the specification is good or not)

So I drew a picture like this

Here’s a little bit of interpretation:

  1. First, we output certain specifications or constraints through the team’s development experience
  2. After that, we will produce some best practices or demo cases based on the base component library or business component library
  3. After a certain stage of game, we formed a certain consensus on the norms
  4. For me and my former team leader, we developed a taxonomy of base business components and business base components and unified their apis
  5. Finally, once the basic components are unified enough, we can output in low code

Yes, in the end my idea was to solve it with low code. You may question how this code can be so consistent, but as in the form case in the previous chapter, the code is pretty uniform by this constraint.

After that, I spent an hour making a simple demo to generate the XXX-form component. The method to generate the code is as follows:

export const getFormCode = (schema) = > {
  return `<template>
  <q-form
    ref="form"
    :model="formData"
    :rules="rules"
    :disabled="disabled"
  >
    ${
      schema.map(item => `
      <q-form-item label="${item.label}" prop="${item.key}" ${item.isInline?'class="inline-form-item"':' '}>
        <q-input v-model="formData.${item.key}":placeholder=" Please input${item.label}" :disabled="disabledFields.includes('${item.key}')" />
      </q-form-item>
      `).join('\n')}

  </q-form>                                   
  </template>
  <script>
  const getBaseCustomFormData = () => ({
    ${
      schema.map(item => `
        ${item.key}: ''
      `).join(',\n')}
  })
  export default {
  props: {
    disabled: {
      type: Boolean,
      default: false
    },
    // Array.<String>
    disabledFields: {
      type: Array,
      default: () => []
    }
  },
  data() {
    return {
      formData: getBaseCustomFormData(),
      rules: {
        ${
          schema.filter(item => item.required).map(item => `
            ${item.key}: [{required: true, message: 'Please enter${item.label}', trigger: 'blur' }
            ]
          `).join(',\n')}}}; }, methods: { setData(data) { this.formData = Object.assign(getBaseCustomFormData(), data); }, getData() { return Object.assign({}, this.formData); }, clearData() { this.formData = getBaseCustomFormData(); }, validate() { return this.$refs.form.validate(); }, clearValidate () { this.$refs.form.clearValidate(); }}}; </script> <style lang="scss" scoped> .inline-form-item { display: inline-block; width: 50%; vertical-align: top; } </style> `
}
Copy the code

The effect is also relatively simple, support we commonly used layout configuration:

The resulting code must also conform to my specification for the XXX-Form component.

After that, I took the demo and chatted with my former team leader. After that, I talked with the senior leader about component design and team specifications on the way off work.

Thus comes the conclusion of the last chapter ✨

The last chapter is left for conclusion

This is just a simple demo, mainly to share with you my inspiration for development, but now it turns out to be problematic:

  • About the rationality of component classification and design
  • About the limitations of this code generation program
  • .

In fact, if you want to make something, you should have more preparation and stand in a larger vision to explore the value. The idea of this article is relatively immature, please give me more advice.

Write in the last

✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨

Painting ling yan, on the oasis. Since ancient times, fame belongs to young ☀️

Welcome to praise ~ I am Hancao, wechat: Hancao97

✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨