Cacher is the code snippet organizer for pro developers

video

• 要加水印and animation

• 最大size限制

  resource_type: 'video', upload_preset: "ys9tzolg", max_file_size: 50000000, // 50M

image

上传要加tag， 要能让运营的人员根据板块和标识字段id etc找到具体图片

导数据

• 在知道有着方面的需求的时候， 产品需要和开发沟通， 让开发知晓这个事情
• 需要有一个标准的流程。 前端/后端， 怎么做
• 风险处理？
• google sheet的格式统一
• EM/AM 那边自己也要有个备份， 这样不需要/不应该向开发要数据

权限/角色/帐号

之间的关系为：一个帐号可以有多个角色， 一个角色可以有多个权限

权限信息都保存在 nav_config.js 中， 这个只有开发有

比如有一个权限：

    "TRANSLATION": { // 模块
        // 权限名称：权限编号
        "翻译首页": "TRANSLATION-INDEX",
    }

1. 先在权限管理中选择模块： 翻译
2. 添加对应的名称和编号(之前在nav_config.js里面添加的key/value)，权限描述： "翻译首页"； 权限编号： "TRANSLATION-INDEX",
3. 去角色管理页面 选择现有角色或添加新角色， 比如新建 翻译查看角色
4. 给这个角色添加刚才的权限，- 翻译首页 权限
5. 去到账户管理页面
6. 给对应账户添加刚才的角色 -翻译查看角色

此时用户可能需要重新登录

在js中获取用户权限信息：

1. 在js中获取: window.KLK_PAGE_DATA 里面有对应信息
2. 在 web_comm.js 里面有方法： get_page_roles(), 加入对应权限会更新 KLK_PAGE_DATA

多次请求

为了避免用户多次请求, 简单粗暴的方式是用 main.addloading() 的方式全局添加蒙层

ajax

目前整体的ajax用promise & async/await 的方式去处理, 见 klook.pmsGet etc...

图片

• 图片要有大小和宽高限制
  • max_file_size: 4000000, // 4M
  • max_image_width: 3000,
• 图片尽量不要用png, png相对耗资源
• 图片最好提前声明宽高, 并在admin里面提供预览
• 图片前缀为: https://res.klook.com

main.syncParamMixin

在有搜索功能或筛选功能的页面 , 需要提供同步搜索/筛选信息与url的功能, 这样用户刷新页面或者分享页面链接的时候就可以看到 同一个页面. 不要将状态保存在localstorage或者其他缓存中.

code review

review 的时候不要只看代码, 还要看页面功能, 要让开发演示下页面的流程.

TODO

admin needs it's own icon library to make interactive UI.

octave [10:38 AM] octave [10:16 AM] @rita.zhao 我听说城市页要导数据， 可以说下原因和需求么？

rita.zhao [10:36 AM] 嗯嗯，因为城市页改版增加了一些新的内容版块，我们网站城市数量也比较多，现在运营人员那边几个团队一起在整理翻译这些新增版块的内容，把内容整理到一张表格了，因为数据量比较大，运营人员手动去填写那些信息到admin后台耗时会比较久，我们改版的话也需要把所有城市的信息都填写好，统一发布。所以这边想让开发们帮忙看看有没有可以帮助运营同事快速导入数据的方式，谢谢～ @here 今天 @mish.zhong 跟我说城市页那边要导数据， 这种事情不是第一次了， 但是每次都好象是第一次处理， 我感觉有必要讨论一下

mish.zhong [10:40 AM] 之前campaign的是无奈，因为旧数据不在代码里做兼容，所以就只能想办法洗成新的数据结构，不然没法使用

octave [10:40 AM] 因为 AM那边给的sheet往往格式不能够满足前端/后端导数据的需求，甚至很多是有表格之间各个团队填写的格式也都有出入，会给我们带来不必要的麻烦

mish.zhong [10:41 AM] 所以我有问产品这些表格的结构是不是都一样的

octave [10:42 AM] 另一方面，导数据这种事情最好不要在最后迫不得已的时候突然提出来，这样会让开发措手不及，另外做的时候也不是没有风险， 如果需求发现需要导数据的话， 最好一开始在AM就开始做的时候就让开发知道， 这样可以提前商量好怎么做会比较从容一点。

1. 另外印象中以前导数据都是后端来做，但是后端这边也不胜其烦，现在也没有一个标准的流程去做这个事情 @powerfj @pengchaonest (edited) @lena @rita.zhao 这个事情并不是针对这次城市页的需求， 但是依经验来看， 在这方面是有合作上的缺陷需要沟通，而且会让我想到帮助中心那边的事情 另外有的时候我们开发也会想不到这种东西， 也会有问题。 大家有什么看法么？

mish.zhong [10:44 AM] 把Excel表的格式规范化 (edited) 这样在洗Excel数据的时候，可以减少不必要的处理逻辑 (edited)

aiming.chen [10:46 AM] joined 关于导数据 by invitation from octave, along with chris.

octave [10:46 AM] @aiming.chen @chris FYI

mish.zhong [10:50 AM] 在导数据，除非新旧数据一些的格式变化比较大，代码层面又不能去做旧数据的兼容，免得后期维护更大的情况下，才会让后端或者前端去更新数据 例如campaign的时候 其他的如数据巨量，上线时间又急的，就可以考虑是否比较折中的方式去帮忙填充数据或者导入数据 产品找我的时候，我给的方案是，Excel数据洗成json格式，然后在admin里以附加工具的形式出现，数据是注入的形式添加（这个注入的代码需要根据不同的情况去重新写），但提交的动作交给运营人员。

rainweb [10:53 AM] joined 关于导数据 by invitation from octave.

octave [10:53 AM] @rainweb FYI

lena [11:14 AM] Campaign page那个我刚才也问了一下，那个原来有七八百个老的campaign 内容，要别人重新全部手动录入一次，这个工作量真的是太巨大了，所以才需要导入 城市页这次的数据，也是因为新增加了字段之后，我们目前上线了多少城市，他们就需要进入到城市页面去填写多少次，而且还有多语言的填写 所以是希望能够有帮助他们工作的方法，不然真的是要耗费他们很长的时间去做这件事 但是我们也是秉承商量的态度，如果有其他的解决方案，都是可以去实行~~ 再实在不行，最后一招就是人手一个城市一个城市的再重新录入一遍 然后google sheet的格式，如果有需要，我们是可以配合修改成方便的格式~~ 但是，是前端还是后端来做这件事的话，还是看大家觉得，哪一边来做会好一些来决定

octave [11:28 AM] 我觉得可以优化的流程是： 如果有数据要导的话， 产品会先知道这个事情， 最好在AM/EM填写文案之前， 先通知开发这边， 这样开发可以先商量一下怎么做合适， 然后把对应的方法/建议给到产品，这样有改动的话EM也可以提前按规定的格式来做，另外开发也可以预先把这部分工作预估出来， 大家都会比较从容来做。如果开发完了突然说要导数据，会有点措手不及， 而且也不好改。 @lena 这样开发可以时刻把导数据这部分内容估算在工作内容之中， 比如这次四季气候的改动， 我们并不是写在一个地方， 如果提早在sheet那边改到的话可能更简单一点。

lena [11:35 AM] 这个应该是可以的~~ 这次是因为本来想Admin提早上线，他们就直接去admin里添加了~~ 但是后来前端开发也快完成了，所以我们只好提前让运营人员开始准备数据，不然如果等待Admin上线了他们才开始填写，开发一直就不能上线前端页面的内容 以后如果有类似的，根据我以前有导数据的经验，应该会先和开发看一下表格的格式，是否符号要导入系统的格式~~ 未来如果类似的，我们也尽量先和开发这边核对需要导入的内容，是否是可行的

octave [11:36 AM] 好， 我是觉得应该这样会比较好。

lena [11:39 AM] 好的~~ 这个可以~~ 未来类似的情况，我们都还是先提前和开发这边商量进行