微信小程序開發(fā)之快速實現(xiàn)運營需求
作為一枚前端,我想在我們的日常中,除了不斷的積累各種語言框架外,我們更多的時候是給產(chǎn)品、業(yè)務(wù)提供切實、可行的解決方案,并最大程度上簡化我們的后期維護工作。
本文以小程序端的兩個場景為例,簡述下我們在解決運營類數(shù)據(jù)的思路和方案。歡迎拍磚。
場景一:動態(tài)實時更新頁面數(shù)據(jù)
京東有禮小程序的首頁,是為用戶呈現(xiàn)的禮品卡列表。我們的需求是可以動態(tài)、實時更新禮品卡列表,比如春節(jié)期間推出一批拜年的卡面,而元宵節(jié)時更換為猜燈謎的卡面,平日再更換一批其他的卡面。這里我們稱這些被動態(tài)實時更新的數(shù)據(jù)為運營類數(shù)據(jù)。
這其實是一個很簡單的問題,即需求方在后臺維護這些運營數(shù)據(jù) => 后臺提供數(shù)據(jù)接口 => 前端調(diào)用并渲染,就可以了。不過,當(dāng)時后端沒有維護“運營數(shù)據(jù)”的系統(tǒng),在一周內(nèi)完成系統(tǒng)并提供數(shù)據(jù)接口的方案基本被 pass 掉了。
當(dāng)時適逢小程序推出 web-view 的解決方案,而在PC 和 M 端,需求方有通過運營活動平臺搭建的活動鏈接,如果能夠直接使用現(xiàn)有的活動鏈接,似乎也可以解決問題。不過 web-view 對業(yè)務(wù)域名做了限制,而我們搭建的活動頁涉及到的域名、登錄、領(lǐng)券等功能,未知風(fēng)險不可控,一周內(nèi)也未必能搞定,也放棄。
有趣的是,我們在考慮web-view方案的時候,發(fā)現(xiàn)運營活動平臺可以提供數(shù)據(jù)接口?。』蠲撁撘粋€“配置系統(tǒng)”呀。很快我們確定了方案:在現(xiàn)有活動頁的基礎(chǔ)上,新增列表的數(shù)據(jù)結(jié)構(gòu),讀取配置接口,渲染數(shù)據(jù)。
數(shù)據(jù)結(jié)構(gòu)如下,其中首焦、樓層通過groupName區(qū)分,首焦、樓層數(shù)據(jù)即是每個list的內(nèi)容.
這樣一來,從需求提出到實現(xiàn),我們用了不到一天的時間。后來需求迭代更新時,增加了一個首焦圖,和春節(jié)紅包抽獎活動,我們在此基礎(chǔ)上增加字段,只需在源碼基礎(chǔ)上增加一條判斷和一次循環(huán),就可以搞定需求,非??旖?,滿足了產(chǎn)品的快速迭代,減少了前端的工作量,基本沒有動用后端資源。
場景二:多場景個性化實現(xiàn)
京東圖書小程序,承載著京東實體書,活躍在眾多公眾號的首頁。比如我們的公眾號首頁,可以快速鏈接到京東圖書的小程序。那么需求來了,我們每個公眾號的受眾群體存在著差異性,那我們怎么給用戶提供精準(zhǔn)的數(shù)據(jù)以便用戶快速獲取所需圖書呢?
我們的方案就是為不同的公眾號實現(xiàn)自己定制的京東圖書小程序的首頁,如下兩張圖中,分別是不同的公眾號對應(yīng)的不同京東圖書的首頁的活動頁面,實現(xiàn)了多場景個性化的定制。
在收到該需求時,我們已經(jīng)實現(xiàn)了通過 web-view 接入 H5 的方式,運營頁面內(nèi)容已經(jīng)更加靈活。那如何實現(xiàn)這種差異性的展示呢?
有了場景一的啟發(fā),我們很快決定,借助活動平臺,根據(jù)公眾號的 appId 配置不同的 H5 url 鏈接。當(dāng)數(shù)據(jù)約定完畢后,我們只需要在活動頁根據(jù)數(shù)據(jù),及當(dāng)前小程序的 appId 進行匹配,待匹配成功后,將現(xiàn)在的 web-view 的 url 鏈接更新即可。
以上就是微信小程序開發(fā)之快速實現(xiàn)運營需求,希望能對大家有所幫助。