某些业务场景下需要来回切换页面,希望提供tab切换模式,这样不必每次打开又刷新页面。
这和我们自己内部的产品形态和设计规范相悖,我们也没有足够的能力提供和维护一个体验好的 tab 切换版本,因此暂时不会提供,感谢理解。
https://github.com/ant-design/ant-design-pro/issues/5812#issuecomment-569068809
另外,在 http://scaffold.ant.design/ 里找到了几个支持标签模式的 React 脚手架,做的都非常好,可以试试。
持续补充ing...这和我们的产品形态和设计规范相悖,暂时不提供。
对于产品来说,用户就是上帝,既然有这么多人有这个需求,为什么不能提供,或者提供一些demo,我们自己来实现,满足需求也是可以的。
@RivanLuo 可以试试 https://github.com/iczer/vue-antd-admin
@afc163 大哥,这样就整复杂了。。本来我们这种就是 后端 程序员,,学个react都不容易了。你又给了一个vue的,,真的学不动了。
@RivanLuo 我必须给你一个赞,,,还有一个就是table没有合计列这个问题 ,也是很多人提,但是都没得到有效的解决。。各种样式错乱。。
@RivanLuo 可以试试 https://github.com/iczer/vue-antd-admin
还是很谢谢你,不过这个是vue,对我来说是比较困难的,也许这个架构和pro的架构是不同的,感觉参考意义不大
@RivanLuo 我在 http://scaffold.ant.design/ 里找到几个支持标签模式的 React 脚手架,做的都非常好,你可以试试。
@afc163 d2-admin是vue.js的吧
@RivanLuo 如果你搞出来了,让我学习一下,OK?
@afc163 dva-boot-admin 虽然可以实现多tab 但是效率低,每次在tab之间切换会重新请求后台数据和渲染。。和我们平时用的多tab不是一个概念。
这个需求在后端管理系统是个非常必须的需求,传统的ERP里面都会有,用vue的keep-alive是可以实现这个,最近想转换用ant-design-pro。被这个问题卡主了。
既存在,即合理!
产品设计之初就是为了满足各种需求,大家都提出 tab 切换模式,那他在某一角度来说,就是合理的!
我们不应该将自己的思想过分的局促在一个固定的思维中。有时候还是要相对变通一下。
又找到两个:
方案2可行,已实现 thy

@RivanLuo 怎么实现的,分享一下撒
@RivanLuo 第二个体验没第一个好,不能移动,不能关闭
我自己写了一个,可以随意切换现有的和多tab模式,不过解决的问题和新增的问题差不多一样多,只能作特殊情况的备用方案

@RivanLuo 第二个体验没第一个好,不能移动,不能关闭
移动和关闭自己写下就好了,很简单,加个右键菜单
产品:react-ant-pro (支持多页签,支持多页签,支持多页签,动态路由)
功能:支持多标签,准备做报表系统,框架基本搭好
github链接:https://github.com/kuhami/react-ant-pro
演示链接:https://kuhami.github.io/react-ant-pro/
截图

@kuhami 你不是语句antd pro 2.0 改的吗?
@kuhami 你不是语句antd pro 2.0 改的吗?
有个新的,有个旧版本的,新版本感觉太复杂!https://github.com/kuhami
@kuhami 我用的是2.0开做的 二开,你说的复杂是什么意思,是有坑吗,如果有坑,我就先不切换成多tab 模式了。
@kuhami 我用的是2.0开做的 二开,你说的复杂是什么意思,是有坑吗,如果有坑,我就先不切换成多tab 模式了。
@xgj1988 路由和权限这块,你可以先踩踩坑。
@kuhami 路由就用的他本身的,,权限没用他的,我自己写了一套。
@kuhami 路由就用的他本身的,,权限没用他的,我自己写了一套。
@xgj1988 我们做的报表系统,选的这个https://github.com/kuhami/react-ant-pro 模版!
@kuhami 可以加你个微信不。。我发邮件给你,我把我的微信给你,你家一下。
@kuhami 可以加你个微信不。。我发邮件给你,我把我的微信给你,你家一下。
👌
这和我们的产品形态和设计规范相悖,暂时不提供。
对于产品来说,用户就是上帝,既然有这么多人有这个需求,为什么不能提供,或者提供一些demo,我们自己来实现,满足需求也是可以的。
@RivanLuo 体验一下demo:https://kuhami.github.io/react-ant-pro/
我们这边也有这个需求,我也做了一个带tab页面的pro,看看适不适合大家:https://github.com/bailihuiyue/ant-design-pro-tabs
GitHub
基于pro2.0制作的多标签版本,直接引入组件即可使用,十分方便. Contribute to bailihuiyue/ant-design-pro-tabs development by creating an account on GitHub.
@afc163 dva-boot-admin 虽然可以实现多tab 但是效率低,每次在tab之间切换会重新请求后台数据和渲染。。和我们平时用的多tab不是一个概念。
这个完全就是假多标签,没有实际意义
最近项目需求,把多标签页的功能提取了出来,这里秀一下 _(:3J∠)_

之前有通过 menuData 实现过一个多标签页功能,提取过程中发现页面子路由不好使,所以又通过路由实现了一个版本,欢迎一起交流学习。
我自己使用react-router, react-redux, redux-saga实现了多Tab页面瘦身版Ant Design Pro,地址是https://github.com/JerryMissTom/ant-design-lite,大家可以做个参考。
参考上面的老哥结合最新版的pro实现了多页面版本,可以通过defaultSettings中的配置切换普通模式和tab模式。项目地址webmagician-ui,今后大概也将不断改进。
希望官方出个tabs模式
自己实现过多Tab版本的Ant Design Lite 后,有一个场景需要注意,举个例子,从设备列表页打开设备详情页,假如详情页的数据使用models的state存储,会出现打开多个设备详情页的内容是一样的情况,这就需要将所有的数据处理放置在页面的state中,不能放在models的state中。
@JerryMissTom 我是基于路由实现的,可以不用这样,监听一下路由参数变化重新请求即可。
@theprimone 我的场景是从Device List 页面打开多个DeviceDetail页面,切换Tab可以查看不同Device Detail。监听界面路由参数变化发送请求是可以,但是每次切换Tab都要请求一次,这个明显是浪费的。还有一种情况,当切换Tab后网络请求失败,会导致两个Device Detail界面的信息是一样的。
那是场景不同了,我是用每个页面的路由定义作为唯一 id 的,所以像 /device/:id 不可能打开两个页签的。这样,只监听 id 变化的才请求的话就不会每次都请求了。
@theprimone 嗯,我是以页面url作为唯一的,像 /device/:id 的话,id不同,会同时打开多个tab页签的
感觉自己写也不难,umi可以拦截路由,自行渲染

核心思路是:
1、在layout/index.js 的BaseLayout 的render里面使用

替换原来的this.props.children
2、拦截路由

灵感来自:
https://umijs.org/zh/guide/router.html#%E4%B8%8D%E5%90%8C%E7%9A%84%E5%85%A8%E5%B1%80-layout
https://ant.design/components/tabs-cn/#components-tabs-demo-editable-card
公司项目也有多标签功能的需求,看了各位的实现感觉还是不太满足自己的需求,就自己写了一个基于Ant design pro 4 + 路由拦截的方案,解决了一些标签切换、关闭、路由关联、相同类型不同数据详情页、url直接访问指定标签等问题,有兴趣的兄弟可以瞅瞅 多标签实现地址



开发人员真是一根筋,大家的需求就在那,人家就是不做。
开发人员真是一根筋,大家的需求就在那,人家就是不做。
@gudufy 我们自己业务中没遇到这个需求,这种情况下我们做不好的。
开发人员真是一根筋,大家的需求就在那,人家就是不做。
自己就可以实现,为什么非要等官方提供?对自己没信心吗?
ant design pro v4 添加TabsNav功能:
BasicLayout.tsx:
<Authorized authority={authorized!.authority} noMatch={noMatch}>
<TabsNav propsList={props} />
{/* {children} */}
</Authorized>
TabsNav.tsx:
import React, { useState, useEffect } from 'react';
import './index.less';
import { DownOutlined } from '@ant-design/icons';
import { BasicLayoutProps as ProLayoutProps } from '@ant-design/pro-layout';
import { Layout, Tabs, Dropdown, Button, Menu } from 'antd';
const { Content } = Layout;
const { TabPane } = Tabs;
export interface TabsNavType extends ProLayoutProps {}
//获取 router 数组
const getRouterArray = function (routes): array {
let newArray = [];
routes.map((item) => {
//有子节点
if (item.name) {
if (item.children && item.children.length > 0) {
newArray = [...newArray, ...getRouterArray(item.children)];
} else {
newArray.push({
path: item.path,
name: item.name,
});
}
}
});
return newArray;
};
const TabsNav: React.FC<TabsNavType> = ({ propsList }) => {
const {
route,
location: { pathname },
children,
} = propsList;
//获取 router
const routeArray = getRouterArray(route.routes);
const routeItem = routeArray.find((item) => pathname === item.path);
//初始化 or 赋值
const changePaneItem = routeItem
? [
{
path: pathname,
children,
name: routeItem.name,
},
]
: [];
//设置 tab item
const [pane, setPane] = useState(changePaneItem);
//监听 propsList 传值变化
useEffect(() => {
const existPane = pane.some((item) => item.path === pathname);
//不存在的添加
if (!existPane) {
setPane([...pane, ...changePaneItem]);
}
}, [propsList]);
//删除tab item
const onRemove = (targetKey: string): void => {
//不能删除最后一个节点
if (pane.length === 1) return;
//如果删除的节点 为现选中节点 , 则需要选中当前删除节点的前一兄弟节点
if (pathname === targetKey) {
//获取 删除节点的 前节点
let previousIndex: number;
pane.forEach((item, i) => {
if (item.path === targetKey) {
previousIndex = i - 1;
}
});
onChange(pane[previousIndex].path);
}
const newpanes = pane.filter((item) => item.path !== targetKey);
setPane(newpanes);
};
//切换选项卡
const onChange = (activeKey: string): void => {
propsList.history.push(activeKey);
};
//删除其他
const onRemoveOther = (): void => {
const newpanes = pane.filter((item) => item.path === pathname);
setPane(newpanes);
};
const onRemoveAll = (): void => {
setPane([]);
};
const onTabsActions = ({ key: string }): void => {
switch (key) {
case 'close':
onRemove(pathname);
break;
case 'closeother':
onRemoveOther();
break;
case 'closeall':
onRemoveAll();
break;
default:
break;
}
};
return (
<Layout className="tabs-layout">
<Content>
<Tabs
hideAdd
type="editable-card"
className="tabs-content"
activeKey={pathname}
onEdit={onRemove}
onChange={onChange}
tabBarExtraContent={
<Dropdown
overlay={
<Menu onClick={onTabsActions}>
<Menu.Item key="close">关闭当前</Menu.Item>
<Menu.Item key="closeother">关闭其它</Menu.Item>
{/* <Menu.Item key="closeall">关闭所有</Menu.Item> */}
</Menu>
}
>
<Button type="primary" ghost>
操作
<DownOutlined />
</Button>
</Dropdown>
}
>
{pane.map((item) => (
<TabPane key={item.path} tab={item.name}>
{item.children}
</TabPane>
))}
</Tabs>
</Content>
</Layout>
);
};
export default TabsNav;
插眼
看到这个被置顶还以为团队有计划了,原来是被问多了烦不胜烦的意思😂
其实多标签大部分只是遗留的操作习惯,真说能提高工作效率还是有待商榷的,以前在一个tab中管理许多复杂的操作并不容易,加上iframe用的多开发者选择了多标签的形式,但对于现在的单页面应用来说,设计时就应该考虑用户完成整个流程操作需要的信息整合于一个页面,用户用起来体验会更好,以我司目前所接触的客户和行业还没有说非得多标签解决不了的,不过是换个思路
看到这个被置顶还以为团队有计划了,原来是被问多了烦不胜烦的意思😂
其实多标签大部分只是遗留的操作习惯,真说能提高工作效率还是有待商榷的,以前在一个tab中管理许多复杂的操作并不容易,加上iframe用的多开发者选择了多标签的形式,但对于现在的单页面应用来说,设计时就应该考虑用户完成整个流程操作需要的信息整合于一个页面,用户用起来体验会更好,以我司目前所接触的客户和行业还没有说非得多标签解决不了的,不过是换个思路
我列举一个场景 , 企业应用有的时候 需要两个模块数据做参考或者对比 但系统期初的时候并没有规划相应的报表或者功能设计 这个功能就特别有用
我们也有啊,按你的说法,常用就应该形成功能需求,前期没有规划那直接在浏览器中打开两个标签不完事了,这就是临时方案.
PKAQ notifications@github.com 于2020年7月8日周三 下午8:23写道:
看到这个被置顶还以为团队有计划了,原来是被问多了烦不胜烦的意思😂
其实多标签大部分只是遗留的操作习惯,真说能提高工作效率还是有待商榷的,以前在一个tab中管理许多复杂的操作并不容易,加上iframe用的多开发者选择了多标签的形式,但对于现在的单页面应用来说,设计时就应该考虑用户完成整个流程操作需要的信息整合于一个页面,用户用起来体验会更好,以我司目前所接触的客户和行业还没有说非得多标签解决不了的,不过是换个思路
我列举一个场景 , 企业应用有的时候 需要两个模块数据做参考或者对比 但系统期初的时候并没有规划相应的报表或者功能设计 这个功能就特别有用
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ant-design/ant-design-pro/issues/220#issuecomment-655485952,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFTOIG3FYIAQVZCITC5L27TR2RQLLANCNFSM4EEFT2QQ
.
@Liu-Ya 如果是 CSR 的话,在浏览器多开标签页体验 ok 吗?
@Liu-Ya 如果是 CSR 的话,在浏览器多开标签页体验 ok 吗?
没看懂CSR是什么,如果你说的是CSRF的话我可以说基本没问题(抛开比较奇葩的csrftoken方案),例如我们后端使用的django就是直接写入cookie的,如果你认为不安全也可以使用localStorage或者其他存储方案,都是同源可用的
@Liu-Ya 相对于 SSR 的客户端渲染啊,客户端渲染再在浏览器多开标签页体验感觉没那么好啊
@Liu-Ya 相对于 SSR 的客户端渲染啊,客户端渲染再在浏览器多开标签页体验感觉没那么好啊
😂 这个CSR啊,你说的体验不好是指哪个方面,我们的项目都没用SSR,首屏加载后多开标签文件都是从缓存来的,而且因为token等信息都已经准备好了所以打开另一个标签对用户来说没有什么额外的负担呀
@Liu-Ya 是把代码和全局数据状态都是通过缓存在第一次加载就搞定的了啊,这样的确没有什么额外的负担了 _(:3」∠)_
看到这个被置顶还以为团队有计划了,原来是被问多了烦不胜烦的意思😂
其实多标签大部分只是遗留的操作习惯,真说能提高工作效率还是有待商榷的,以前在一个tab中管理许多复杂的操作并不容易,加上iframe用的多开发者选择了多标签的形式,但对于现在的单页面应用来说,设计时就应该考虑用户完成整个流程操作需要的信息整合于一个页面,用户用起来体验会更好,以我司目前所接触的客户和行业还没有说非得多标签解决不了的,不过是换个思路我列举一个场景 , 企业应用有的时候 需要两个模块数据做参考或者对比 但系统期初的时候并没有规划相应的报表或者功能设计 这个功能就特别有用
浏览器再开一个Tab标签页不就行了?
看到这个被置顶还以为团队有计划了,原来是被问多了烦不胜烦的意思😂
其实多标签大部分只是遗留的操作习惯,真说能提高工作效率还是有待商榷的,以前在一个tab中管理许多复杂的操作并不容易,加上iframe用的多开发者选择了多标签的形式,但对于现在的单页面应用来说,设计时就应该考虑用户完成整个流程操作需要的信息整合于一个页面,用户用起来体验会更好,以我司目前所接触的客户和行业还没有说非得多标签解决不了的,不过是换个思路我列举一个场景 , 企业应用有的时候 需要两个模块数据做参考或者对比 但系统期初的时候并没有规划相应的报表或者功能设计 这个功能就特别有用
浏览器再开一个Tab标签页不就行了?
所以用户要
普通用户: 复制链接->新建标签页->黏贴地址->点击需要的菜单
熟悉点操作的用户: 找到菜单->右键->在新标签页中打开
这种操作咯?实际情况中很多用户复制粘贴都还是在靠右键的 这过高估计了用户的信息化水平了. 这个问题的感觉官方像当初的后台获取菜单一样无法理解现实中用户的实际需求.
看到这个被置顶还以为团队有计划了,原来是被问多了烦不胜烦的意思😂
其实多标签大部分只是遗留的操作习惯,真说能提高工作效率还是有待商榷的,以前在一个tab中管理许多复杂的操作并不容易,加上iframe用的多开发者选择了多标签的形式,但对于现在的单页面应用来说,设计时就应该考虑用户完成整个流程操作需要的信息整合于一个页面,用户用起来体验会更好,以我司目前所接触的客户和行业还没有说非得多标签解决不了的,不过是换个思路我列举一个场景 , 企业应用有的时候 需要两个模块数据做参考或者对比 但系统期初的时候并没有规划相应的报表或者功能设计 这个功能就特别有用
浏览器再开一个Tab标签页不就行了?
所以用户要
普通用户: 复制链接->新建标签页->黏贴地址->点击需要的菜单
熟悉点操作的用户: 找到菜单->右键->在新标签页中打开这种操作咯?实际情况中很多用户复制粘贴都还是在靠右键的 这过高估计了用户的信息化水平了. 这个问题的感觉官方像当初的后台获取菜单一样无法理解现实中用户的实际需求.
所以是临时方案,只是在用户需要的时候引导他去这么做,然后抓紧时间去完成功能升级
看到这个被置顶还以为团队有计划了,原来是被问多了烦不胜烦的意思😂
其实多标签大部分只是遗留的操作习惯,真说能提高工作效率还是有待商榷的,以前在一个tab中管理许多复杂的操作并不容易,加上iframe用的多开发者选择了多标签的形式,但对于现在的单页面应用来说,设计时就应该考虑用户完成整个流程操作需要的信息整合于一个页面,用户用起来体验会更好,以我司目前所接触的客户和行业还没有说非得多标签解决不了的,不过是换个思路我列举一个场景 , 企业应用有的时候 需要两个模块数据做参考或者对比 但系统期初的时候并没有规划相应的报表或者功能设计 这个功能就特别有用
浏览器再开一个Tab标签页不就行了?
所以用户要
普通用户: 复制链接->新建标签页->黏贴地址->点击需要的菜单
熟悉点操作的用户: 找到菜单->右键->在新标签页中打开
这种操作咯?实际情况中很多用户复制粘贴都还是在靠右键的 这过高估计了用户的信息化水平了. 这个问题的感觉官方像当初的后台获取菜单一样无法理解现实中用户的实际需求.所以是临时方案,只是在用户需要的时候引导他去这么做,然后抓紧时间去完成功能升级
想升级? 给钱才行啊兄弟 不给钱就凑合用吧
看到这个被置顶还以为团队有计划了,原来是被问多了烦不胜烦的意思😂
其实多标签大部分只是遗留的操作习惯,真说能提高工作效率还是有待商榷的,以前在一个tab中管理许多复杂的操作并不容易,加上iframe用的多开发者选择了多标签的形式,但对于现在的单页面应用来说,设计时就应该考虑用户完成整个流程操作需要的信息整合于一个页面,用户用起来体验会更好,以我司目前所接触的客户和行业还没有说非得多标签解决不了的,不过是换个思路我列举一个场景 , 企业应用有的时候 需要两个模块数据做参考或者对比 但系统期初的时候并没有规划相应的报表或者功能设计 这个功能就特别有用
浏览器再开一个Tab标签页不就行了?
所以用户要
普通用户: 复制链接->新建标签页->黏贴地址->点击需要的菜单
熟悉点操作的用户: 找到菜单->右键->在新标签页中打开这种操作咯?实际情况中很多用户复制粘贴都还是在靠右键的 这过高估计了用户的信息化水平了. 这个问题的感觉官方像当初的后台获取菜单一样无法理解现实中用户的实际需求.
你刚才描述的场景是用户想要对两个模块的数据做对比,我觉得这种场景是不是应该开两个浏览器,然后在一屏里面分左右并排放着看更加直观?
看到这个被置顶还以为团队有计划了,原来是被问多了烦不胜烦的意思😂
其实多标签大部分只是遗留的操作习惯,真说能提高工作效率还是有待商榷的,以前在一个tab中管理许多复杂的操作并不容易,加上iframe用的多开发者选择了多标签的形式,但对于现在的单页面应用来说,设计时就应该考虑用户完成整个流程操作需要的信息整合于一个页面,用户用起来体验会更好,以我司目前所接触的客户和行业还没有说非得多标签解决不了的,不过是换个思路我列举一个场景 , 企业应用有的时候 需要两个模块数据做参考或者对比 但系统期初的时候并没有规划相应的报表或者功能设计 这个功能就特别有用
浏览器再开一个Tab标签页不就行了?
所以用户要
普通用户: 复制链接->新建标签页->黏贴地址->点击需要的菜单
熟悉点操作的用户: 找到菜单->右键->在新标签页中打开
这种操作咯?实际情况中很多用户复制粘贴都还是在靠右键的 这过高估计了用户的信息化水平了. 这个问题的感觉官方像当初的后台获取菜单一样无法理解现实中用户的实际需求.你刚才描述的场景是用户想要对两个模块的数据做对比,我觉得这种场景是不是应该开两个浏览器,然后在一屏里面分左右并排放着看更加直观?
很多时候真的是高估了用户的电脑操作水平,从JQuery切换成现代框架才几年,还要教育引导客户的操作习惯,是没有被客户爸爸怼过么
基于Ant Design Pro 二次开发,支持多Tab标签页面,模拟Chrome标签页功能
我们的业务场景也是,需要支持多Tab标签页面,找不到类似的功能,自己二次开发实现,支持打开第三方页面,目前用着挺好的。
看下是否满足要求
https://github.com/lengjh/antd-design-pro-tabs


@lengjh 👍 补充到楼上了。
@afc163 整个PR到 ProLayout里面吧
我是做比较传统的财务报账系统的,交互性较强,多页切好多客户都想要(甲方要求,无奈😭,而且多页切是缓存的,只要不关闭切页面那状态不清除,类似vue => keeplive)自己也基于antp3 实现了一个,但是总觉的要有一个标准,能够基于antp能够很好升级。》》但 antd和antp 更新太快。每次想用官方新东西但是 又要满足之前要求(比如多页切)可能还得重新封装😂。 真心希望官方能够给个标准可维护的🙏
有的也是参考大家做的
AntP4 前: https://github.com/Wen006/myadmin
AntP4: https://github.com/Wen006/my-antd
老大赶紧出一个
支持。。官方出的才是正品。。不然以后升级 好麻烦啊
今天看了几个 issue, 感觉这个问题的根源在于 官方对pro的定位是 简易web管理系统, 而大家大部分都是拿来做企业级开发;
所以对于 根据登录用户的后台角色获取菜单 / multitab 等这种功能不感冒;
所以也缺少企业级开发中典型的 字典/菜单/角色/用户 这种必备功能;
而权限之所以鸡肋也大概是因为缺少企业级管理系统中 基于角色的灵活菜单配置 需求场景把
最主要是easyui 和ext js 风格比较更适合企业应用, 以前很多系统都是基于这种模式, 现在很多企业用户也偏爱这种模式。现在这些企业应用公司也迭代更新,想转Vue和React结果这里一个坑就需要填平。
自己实现了一个,上到项目中感觉还可以,可以参考一下:https://github.com/Fengly0503/ant_pro_tabs 在线演示地址:http://pc.loveeveryday.cn/ant-pro-tabs/
看到这个被置顶还以为团队有计划了,原来是被问多了烦不胜烦的意思😂
其实多标签大部分只是遗留的操作习惯,真说能提高工作效率还是有待商榷的,以前在一个tab中管理许多复杂的操作并不容易,加上iframe用的多开发者选择了多标签的形式,但对于现在的单页面应用来说,设计时就应该考虑用户完成整个流程操作需要的信息整合于一个页面,用户用起来体验会更好,以我司目前所接触的客户和行业还没有说非得多标签解决不了的,不过是换个思路
其实在企业级的应用中,多页签(iframe方式)是必不可少的支持,因为客户可能同时打开多个页签做多件事情,某个页签可能做一半就切到另外一个页签做另外一件事情。还有就是可能嵌入其他页面(可能是一个系统,也可能是另外一个系统),我们的系统(作为客户的一个应用系统),客户就要求嵌入他们企业邮箱和门户的dashboard,如果不支持iframe多开方式,是很难达到客户要求(这是他们日常工作方式决定的)。
Most helpful comment
对于产品来说,用户就是上帝,既然有这么多人有这个需求,为什么不能提供,或者提供一些demo,我们自己来实现,满足需求也是可以的。