1. 程式人生 > 其它 >解放前端工程師——手把手教你開發自己的自定義列表和自定義表單系列之一緣起

解放前端工程師——手把手教你開發自己的自定義列表和自定義表單系列之一緣起

> 之前有序言章節<Vue中路由到一個公共元件,然後根據路徑中是否存在檔案動態載入元件>,已經是一個雛形了。而現在,重新梳理下,我們要做的是讓前端工程師不用上班了,哈哈,這麼貼心的後端哪裡找?

1、終極需求

產品經理A:“經常有些需求,並不是那麼複雜,可能僅僅是增刪改查,做些驗證,為啥總要時間開發?”

後端甩鍋王: “我開發很快的,但是! 每次做需求的時候,總需要前端童鞋的協助,他們總是很忙~~~”

產品經理A:"既然都是類似程式碼,那有沒有可能讓開發的童鞋歇會呢?"

後端甩鍋王心裡一萬頭神獸掠過,這是要 讓程式設計師不寫程式碼啊!, 不寫程式碼的程式設計師還是程式設計師嗎?

好吧,我就靜靜的看你裝B!

後端甩鍋王:“我想到了個方案,可以 讓前端程式設計師不寫程式碼!”

產品經理A:“好棒耶,去幹, ta!”

2、元件規劃

既然決定不需要前端人員參與,就能搞定一個模組。 那我們就做個通用模組的增刪改查就好了。

當然根據產品經理的“需求的發展”,也許需要多個不同型別的元件,滿足各類奇葩需求。

我們就用最簡單的列表(按鈕),同頁面增刪改查方式實現一個。
大概的介面如下:

一個模組需要的基本的功能都有了:

  • 增加(增加按鈕,彈出頁面)
  • 修改(修改按鈕,彈出頁面)
  • 刪除(彈出確認提示)
  • 搜尋,可以搜尋定製列
  • 分頁,展示多頁

2.1 面向約定開發

根據這些功能,我們提取變化的地方到配置中。
配置裡儘量按照約定來約束後端的開發

, 僅把模組名視作變化量。

  • 介面命名按照增刪改查的動作+模組名 來定義
  • 提供公共介面,入參:模組名,出參:該模組的下配置(列表、form表單)
  • 後端配置 前端頁面的路由,並由前端整合到路由表內。
    這裡路由資訊 參見序言文章.
    views/common/index 就是我們的公共入口
{
  path: '/test',
  component: Layout,
  hidden: false,   
  meta: { title: 'test', icon: 'dashboard' },
  children: [{
    path: 'testa',
    name: 'testa',
    component: () =&gt; import('@/views/common/index'),
    meta: { title: 'test1', icon: 'dashboard' }
  },
  {
    path: 'testb',
    name: 'testb',
    component: () =&gt; import('@/views/common/index'),
    meta: { title: 'test2', icon: 'dashboard' }
  }
]
},

2.2 預留前端開發入口

為了給前端童鞋留條活路(應對複雜的需求變化),我們心存善良的留下了前端參與的方式。

如果前端童鞋開發了該模組的功能,那我們就客氣的使用吧

 var path = this.$route.fullPath
  try{          
       this.realCompoonent =  require(`@/views${path}`).default
       //this.$router.push(this.realCompoonent)
   }
   catch(ex){
       console.log(`load sub com [${path}] failed. ${ex}`)
       this.realCompoonent = null
   }

2.3 減少Ctrl+C\V

因為預留了擴充套件介面,前端童鞋又可以快樂的 Ctrl+C,Ctrl+V了,有沒有什麼辦法救救孩子們?

嗯嗯,明白了,雖然需要定製,可能也只是某些部分吧,那我們能不能多預留幾個slot呢,嗯嗯,這種方式是可以的。

我們採用了另外的方式,引入了mixList.js ,在這裡定義了公共元件大部分功能, 擴充套件的瘦,僅需要引用 mixins:[mixList],即可繼承所有的方法, 看那個方法事件不滿意,都可以過載覆蓋它們,.

嗯嗯,好了吧,

2.4 動態載入配置

按照2.1章節,我們已經預定了所有的配置和模組名強相關,那麼我們需要做的就是怎麼解析到 模組名,並傳送給公共元件?

眼見的童鞋們,應該發現了路由路徑上就是最好體現模組名的地方,那我們就約定路徑的前2個節點為模組名,.
把模組名組織好,傳給後臺, 然後一切的配置都由後臺決定了。

至此,前端的工程師們可以躺平了!

3. 後端開發

之前已經聊過,後端只需要按照約定開發相應的介面即可。

後端甩鍋王:“做完了這個需求,我咋發現我自己被套路了,這下需求再完不成,就沒辦法甩鍋前端了!oooop,我要失業了!”

當然開發這個需求還是不容易的,後端童鞋可以收藏下,畢竟本次也沒法一次寫完,後續會不斷更新。

大致先欣賞下前端的配置介面。

3.1後端表設計

  • 先定義一個模組全域性表
  • 定義列表配置表
  • 第三個就是form表單配置表


最後一列可以儲存為json格式的資料,這樣每個控制元件都有了自己可以定的屬性了。

看到這裡的童鞋,祝賀你,你已經進入了PASS設計的領域。

3.2 後端介面開發

介面仍在開發中,相信從資料庫的設計,童鞋們應該可以自己動手擼程式碼了。
> 前端工程師們,別慌,你可以順便做做PASS平臺的開發了!

4.後記

產品經理A:“經常有些需求,並不是那麼複雜,可能僅僅是增刪改查,做些驗證,為啥總要時間開發?”

後端甩鍋王: “我要寫程式碼才能完成啊?”

產品經理A:“既然都是類似程式碼,那有沒有可能讓開發的童鞋歇會呢?”

後端甩鍋王:“................#$#%^^%@#!”