迷之iuap

[Glimis]

原文
用友1年半,每次看到iuap都脱口而出哎呦卧槽,其实1年半时间也不短,鬼知道哎呦卧槽究竟有什么变化,或许有人认为这是欲加之罪,纯属扣屎盆子乱扣的逗比行为,以下为盆子,并且是从我发现到现在依然存在的盆子

为了避免意外,注入兼容性,版本号等智障的问题出现,一下图片均在官网上截取,以github的名义发誓,由本人修改的地方一定会有提示,使用最新chrome,所有问题在3台以上电脑复现过(卧槽,iuap提个bug还需要报chrome版本号,你倒不如报个能用的版本号),时间为2017年7月30日01:04:53 前2小时(我就不信此处描述的盆与部署时间有关)

组件

先说这些屌炸天的组件

层叠系列

指modal,下拉,时间,tip等一切层叠相关的组件

先来一个面试题,z-index有哪些特性?请自行度娘或者找个实习生问问

下拉实现如下

很好,将上级容器overflow改为hidden,就会

意料之中,所以当弹出层,grid等需要下拉,tip时

iuap给的具体方案是将上层,上层的上层...overflow修改为auto,很好,滑动显示tip顺带显示滚动条不算bug

easyui,yui看不懂也没事,就算是抄jqueryui也不会出现这种解决方案,难道抄的是bootstrap的dropdowns?人家的定义叫菜单,不叫下拉

下拉(select)属于窗口元素,是少数可以穿透浏览器容器的元素,注入

取消这种穿透无所谓,但至少...算了,下拉与菜单的区别,找个实习生问问

当然,如果是山寨的是某些国产山寨的bootstrap系的ui库,记得帮我喷死他

迷之定位

点击第二下,就迷之上去了

注入多个时间组建下更混乱的方式...官网中没例子就不丢吐了

模态框

绑个ko我看看,这段代码为啥又变成jq了,我咋跟小白解释

验证

点击提交验证,验证不通过提醒,仅作提醒,点击确定保存,取消继续修改...求实现

长度限制要求到了长度就不允许添加,求实现

当前内容已经错误,字体变红,求实现

通用解决方案丢到ui了...我就不好意思提,我们要求的验证不是这个ui

迷之ui

我知道大前神的组内是没有测试的,但我真的不知道,原来大前神都是盲编的,写这个组件的时候,一定是显示器坏了,为了不让业务组的弟兄着急,大前神仅通过键盘和记忆撸了这个组件

这风骚的错落感

美人痣,程序猿中艺术细胞最好的

ReactUI

专门的吧

时间组件上下跳,需求就是这个,我懂得,假设我是个弹出框下的时间呢?

至于具体的api...

卧槽,竟然有人敢用?

下拉,不支持datatable

神说,datatable是模型的封装,神说dataSource是下拉的数据源,神却用行动表示,dataSouce必须为数组

联动处理时,需要各种使用dom操作,很好,很MVVM

datatable不支持嵌套

datatable放屁第一句叫减少错误,为了拓展性,后台会对一个类追加一个属性为对象,一个月内经历了由单层,对,就是datatable希望的那种如[{name:''}]类似结构,扩展到五层,我那时一个绝望,就一个将单选变为多选,将属性转换为对象的需求,我需要多写100行,神一样的子孙嵌套结构,抖机灵

js中写html...

异教徒,这款框架不能加上模板的概念吗,你这么用html,你让小白怎么追加ko绑定(grid的render系列略)?

概念

再看颠覆传统的概念

组件和js组件

先看bootstrap对js组件的定义,为组件赋予生命,再看组件文档,即便如dropdown,也会加上此处需要引入js使其动起来,且第一个例子一定无任何交互,即此处定义为

• 组件,亦可叫css组件,无js
• js组件,js对组件赋予生命的结果

iuap中组件的定义包含了js

大哥,你想让我怎么看文档,求教育如何区分iuap下的组建和js组建

模型增强

求教育,求指导,model与viewmodel到底有什么养的区别

datatable(卧槽,ie8,r u sure?)

ko的官网是如下定义

并在例子中,一再明确,通过observable创建vm

神奇的datatable封装以后,嗯...

就变成了model

所以viewmodel的集合+封装==model+增强==datatabel

涨姿势了,我猜,iuap的后台版,一定使用的是mvc两层架构

全组的人都在html中循环,datatable,各种if判断,$parents做关联

很长一段时间我也这样做,因为rows,iuap就是这么提供的,但有一天我回忆起做velocity时,因为业务追加,因为jsp这种蠢萌蠢萌的东西可以写java,模板中嵌套大量业务逻辑时,我才注意到,卧槽,我竟然也在视图/模板里写复杂的业务逻辑了,视图要的是vm啊,model+逻辑转换成视图不行啊

嗯,好像不行,组建不支持非datatable格式

控件模型

神一样的控件模型,我就当他是ko组件传参的params,属于调用组件下的参数,但是组建内部是通过jq实现的,会变身的,脱离原有ko的控制了,变身玩的这么好,就是说u-meta 或者 u-type的所有子元素其实全都是配置参数?

框架设计

既不是组件,又不是概念的迷之生物

迷之命名规范

我就跟type=textarea刚上了,这个异教徒为什么不是u-textarea

u-meta

设置组件参数,有以下几种方式

• div占坑+js(config)

标准jq组件

• html初始化数据(自定义属性)+js初始化

后端渲染方式,html初始化or组件html化均可代表,内部表示数据源,参数表配置,需要处理组件未初始化时样式

• css组件+js事件

轻量级组件,参考bootstrap,最大特点为无法通过样式判断组件是否已经初始化

• u-meta

突破传统结构的初始化方式,表现为

u-meta为配置参数的json格式

描述datatable时,一定是string类型

内部结构不可使用ko绑定

组件内部结构是固定好的,请不要乱写,写了也没用

内部结构有必填情况

内部组件是固定好的,但不能不写,比如input组件,如果不写input/textarea,u-meta会很贴心的告诉你,input不存在

(我当你是slot,但求你自带初始化)

组件是否初始化可通过ui感知

为了初始化失败导致交互失败,iuap很贴心的通过样式的方式告诉程序猿,你的组件加载失败了

Grid组件

datepicker,ztree系列同理

我就请教下,我就一个最简单的grid,却要下载gzip压缩后70K的代码,还不含jq...对,本身还号称不依赖jq,如何处理?

下图实现如何处理?

不要说这种情况...日,第一版本的时候超级iuap,然后一点一点的煮青蛙,一周一个col的renderType,直到我看的这个进度的UI

每个格子重新用js写html...就算是ko,也有热(嵌套)加载/启动的方式,就算不用ko,追加个模板不难吧

就算是和grid组建api一毛一样的Datatable(表格)组建,至少人家有plugin的概念

至于其内部的api与datatable间稀奇古怪的关系...还需要暗示吗

CND

卧槽..就这速度,就这稳定性...CDN,r u sure?

性能

肉眼都能看见的卡...需要具体数据吗?

单纯的打开,确定setData可以支持1000条数据吗?

点了两下全选,确定setAllRowSelect hold住1000条?

other

1年半,vue都2了,webpack都3了,node直接8了,我还在跟iuap当年的bug正面刚

求不要删,求不说大规划,求不要道歉,只求怼回来

愿下家没有iuap

[GuoYongfeng]

@Glimis 看完之后，先来答一波。

虽然是这么言辞激烈的回馈，而且搜集了大量的【证据】，并提供了很多图文并茂的反馈，所以可以理解你是作为框架的资深用户，你能这么翔实的说出来，好过在心里默默对我们千百遍的问候。所以，对于文章的内容，不会删除，会一直保留；做的不好的，会改正。

从去年 6 月份团队成立并接管这些事情，我们就秉持开源开放的心态，以小鸟啄食的心态一点点努力完善，才有了今天成体系的文档、教程、示例和 github 上维护的源代码仓库，这在之前是不可想象的，而且还背负这诸多的项目工作。所以既然决定了把这些东西完全开放出来，我们也没有你想象的那么脆弱和小肚鸡肠，所以就不要去 YY 我们会删你的 issue，放心吧。

你的 issue 提供了很多很具体的点，非常好，这会是一场很有针对性的对话，对话的内容好过笼统的对骂和甩锅。而且这里面的很多锅，都是我们亲手而为，含着泪也得背，这是我们的态度。

最后，看到你最后的一句话，也为你的眼界和心胸所遗憾。不仅仅是我们整个小团队乃至的大的平台，在负重前行的路上，做了大量有价值有意义的产品和项目。做为平台方，面对复杂的需求和繁重的工作，一直是被骂着长大的，但所支撑你们成长起来的业务，你们应该心怀感恩，而不是恶语相向。被扶着长大的过程你没看见，长大后连自己的奶娘都诅咒，这我也就呵呵了。

[GuoYongfeng]

对于反馈的回答

更多形成的 TODO，稍候也会发出。

1. 对于问题反馈，早在去年就采用版本管理，无论是发布还是问题反馈，都需要明确的版本号，而对于部分特定问题定位，需要提供基本的所使用的浏览器名称及其版本，以方便定位。
2. 对于提到的 neoui 文档中有关下拉的示例问题，这个会尽快确定修改。
3. neoui 中时间组件的样式错乱问题，会尽快确定修改这个 BUG，并完善示例。
4. 模态框 Modal 与 KO 结合的示例，包括类似的写法，都需要修改，用操作 DOM 的方式修改数据和 MVVM 一起用本身就是一种错误的写法。
5. 校验相关的组件和正则确定后会尽快修改完善。
6. 示例系统中 grid/group 这个示例的问题确定后会尽快修改。
7. 分隔下拉组件的 UI 、图片画廊的 UI 需要调整修改。
8. tinper-bee 中的时间组件的定位问题会尽快修改，并完善 API 文档。
9. datatable 本身是对所定义的 Viewmodel 能力扩展，增强其对数据的处理和UI的处理能力。
10. js 中写 html ？是否这样写取决于业务，如果这样的 html 片段多，需要使用模板进行维护；但如果只是简单的一些插入，js 中写 html 也是很好的方式。具体结合上下文。
11. 关于组件和插件这些概念都是明确的，文档迁移之后本身需要做更合理的分类，这个确定后尽快修改。
12. 框架是三四年前的技术产物，那个时候 react 和 vue 都还没看见几家线上使用的，对于组件化的实现，每个框架都给出了自己的一些实践。u-meta 的出现本质也是为了解决组件化的能力，现在回头看，和流行的 jsx 以及 Web components 等肯定是有差距的。另外，u-meta 可以定义单纯的组件和使用 kero 增强数据处理能力的组件，这是两个维度。

[GuoYongfeng]

TODO 进展更新

问题

• 分割下拉显示问题
• 图片画廊显示问题
• webide下的分组显示ui问题

需求

• textarea组件改名为u-textarea，保持组件统一
• grid组件提炼出精简版
• 优化grid的拓展机制
• setSimpData和setData，setAllRowSelect性能优化

说明

• 本框架的组件和js的组件的区别
• model和viewModel的区别

[Glimis]

删,指不要改回答,那会让我在看一遍答案,甚至感觉前言不搭后语
不说大规划,指不要谈以前和情怀,那是老头该干的事情
不要道歉,指不要说改正,知错改错不认错才是程序猿的标配
至于iuap,我只能浅显的为某种奇妙的组织,而你却直接定义为业务组奉献的架构组,并将我定义为不懂感谢(玩恩负义),来,互相呵呵
至于版本号,我指的是每次解决问题,都是通过qq传递文件进行覆盖,且版本号不变的方式..我已经不想提供版本号了,毕竟,升级一次,加班一周,最后回滚

datatable 本身是对所定义的 Viewmodel 能力扩展,主要拓展的是ajax请求的能力吧

todo,大哥,我说的bug,真的只是随便浏览一遍看到的,稍微随便点点,提的化...能塞满整个服务器

u-meta,将原因归为3年前...即使是5年前,java web 主宰整个页面的时候,类似的方案已经很成熟了

• div占坑+config
  复杂组件,chart图,地图,grid..

• div+自定义属性/class+html结构+配合自动初始化(甚至不需要)+js挂在事件
  后端组件,由html结构初始化数据

• div+自定义属性+config
  前端组件

请注意,以上均为jq组件
再看u-meta,打着MVVM(ko 三年前已经包含web component的概念了)的旗号,喊着用操作 DOM 的方式修改数据和 MVVM 一起用本身就是一种错误的写法(我就断章取义,顺带嘲讽各种通过id操作组件的方式),却使用jq组件初始化的方式,最关键一点我能通过样式,判断组件是否加载成功...你不觉得这是个bug吗?

与iuap合作是什么样的体验?

强制,看了一天文档我就申请不要用,但听说项目审批之类的会过不了,而且组内的同志都会iuap(r u sure?)
白鼠,我们的测试,提出的问题,我都想直接丢给iuap,尤其是刚开始,我一直好奇,为什么别的组没有发现这些问题?
解决慢,需要bug描述多,我只想说,测试一眼看出的问题,用一句话打发我,我却要打上各种我都不知道的参数,浏览器版本号,我就想问,你们用什么浏览器看过,没测试吗-。-
不兼容,升级一次,加班一周,最后回滚
不提bug不解决,不找leader没回复

我想,其他合作的部门,要么是纯java web,要么,正大光明的引入后,然后不使用吧

最后
我不是没问候过,我是每天问候千百遍
我不是资深,我是被资深

[HuYuee]

​ @Glimis 最近看到你发的这篇文章。作为该框架的维护人员和开发人员，百味杂陈。于是，就自己的看法，想站出来说点自己的真实想法。

首先

看你如此详细的描述种种问题，不管你是出于什么初衷（希望你是怀着帮助我们框架进一步完善和改进的态度），我心里都是欣慰的、感激的。至少还有你这位认真的框架使用者。你给我们提的bug，我们会逐个修复。至于需求，我们会尽可能的去完成。这些我们都会具体问题具体对待。然而看到你的文章和回复，我作为一个读者和开发人员，我同事也希望你的态度能诚恳或者委婉一点。我们不欠你什么，我们也希望尽可能的让框架能越来越好用，问题越来越少。

其次

如果由于我们升级一次，导致你加班一周。在这里我由衷的道个歉。虽然我们再升级的过程中，尽量保证使用我们框架的每个项目组、开发人员。不用因为我们升级的原因去重新修改代码。但是由于我们才疏学浅，这个问题我们也在逐步的去完善。同时，这个也是我们一定会在一个固定的周期才会去升级版本的原因。

然后

来说说todo的事情，我们现在的开发的流程都是会在具体工作之前会列出ToDo。这样好明确我们下一步的工作，也方便告知别人跟踪进度。至于你说的，如果你要提的化...能塞满整个服务器。还请不吝其辞的一一列出来，我相信我们这个框架的问题，一个普通的服务器还是能容得下。只要你提，我们这边还是会尽量去修复。毕竟我们是该框架的维护人员，这是我们的责任！

​同时

说说提bug的事情。我们还是希望使用者在发现问题，或者有需求的时候，能整理一份清单，或者在相应的仓库上面提issue。然后我们会尽快进行修复bug和完善需求。毕竟我们的时间也有限，除了维护框架，还有其他工作等着我们。

最后

作为框架的使用者，你，或者你们，如果有多余的时间，我也希望你们能参与到框架的维护和开发中来。帮我们分担一份工作的同时，你们能在维护框架的过程中，也能更灵活地去使用我们的框架，何乐而不为。作为维护框架的我们会非常欢迎！也非常感激！

[Glimis]

欠

我见过很多关于欠的话题,覆盖了亲人,友人,师生,同事各种关系,唯独没见过这种...嗯,站在对面都互相不认识的关系,在其他层面也没有进行过精神上的沟通,还去探讨欠...咱都互相不认识,特质的经济物质的欠肯定不存在,但你非要谈,那估计就是欠了,我算了一下,大概欠了保证500条不卡的承诺,欠了下拉支持datatable的解决方案,欠了优化时间组件的需求,欠了在我们上线前完成的承诺,欠了对架构组的信任...不对,这个不是,这个是欠多了,产生的利息

态度

态度触使行为,也是逐步变化的,很久之前我发现一个很有意思的问题,如果我直接请教,九成九是得到一句好的我知道了,如果我抄送(领导)邮件,领导会直接要求陪人沟通,如果我跟人直接沟通,大致是qq传文件,这次没问题,这辈子就别升级了(升级以后问题重现),如果去参加所谓的吐槽会,会说,你说的问题我们都记下来了,态度很端正,然后类...就说楼上的几个bug,完全可以这么描述,都是停留超过1年的的bug,且部分,就是态度很明确的告诉我一定会改正的bug....我能想到最快的方式,大致就是在公共场合大喊一声,卧槽,iuap的什么鬼Bug,期待或许明天就有人上门大脸,怒吼一句,你还原一个我看看....态度这东西,无非是你认为我在'杀人行凶',而我认为我是'正当防卫'

初衷

原本想工作交接时,做个交接文档,包含iuap大坑指南,但坑太多,尤其是看到1年前提的bug,别说什么bug系统,咱有对接人,也当着一群人的面提过(传说中的吐槽大会),就着办事效率,我就单纯的想嘲讽一次

最后

我写过N多iuap的补丁,你知道什么叫做烂到骨子里吗,除了工作,鬼愿意参加一个js写html,没有模板,生命周期混乱,vm与model更乱,组建实现诡异,性能低到爆,样式丑成翔,文档残次还有错的项目?

[songhlc]

在看kero的时候 偶然发现原来程源的吐槽，程源离职也和技术栈上没有太多他能发挥的余地有一定关系。

顺便来说说对之前平台处的框架的看法，比较认同iuap里的datatable(kero)，不认同里面组件的设计方式，尤其是u-meta的方式。

在knockout本身给出了组件标准化写法的前提之下，又大费周折写出一套u-meta的不方便兼容的写法，确实有点走歪了。认同datatable是因为在各类复杂场景下，需要抽象出一个类似datatable的东西来处理vm层（否则会有大量重复的代码），但是平台也没有给出datatable使用的最佳实践，而且几乎把组件和datatable强绑定了，导致了组件的可扩展性会差一点。
然而目前云采已经基于ko技术栈走了这么多，完全转换到其他更现代的技术栈也不太可能了。所以我们自己重新开发了一套UI层的组件：ycloud，完全用ko组件的写法来实现，更像iview或者element，让开发去记住语义化的标签即可，把css弱化到最低的成都，只需要知道栅格布局即可，其他都通过标签名称+参数去实现，另外对表格组件的扩展性做到最大。目前一部分业务已经开始使用了。
云采最终的目的是一套ycloud+自建页面生命周期（对于开发可维护的代码太重要了，原来平台没有提供相关的最佳实践）+封装了kero的数据模型的一套开发技术栈。

有需要基于knockout和iuap-design 进行改造的可以关注，当然目前还属于内部发版，只有示例页面，没有文档。
ycloud源码：
https://github.com/yonyouyc/ycloud

admin类页面：
https://yonyouyc.github.io/ycloud-admin/dist/index.html#form

也希望平台在发展react的同时别忘了对原来ko技术栈的支持