一次 github 跟开源大佬的抬杠经历
先叠个盾: 感谢所有开源作者的贡献
不是前端,写个小工具,需要有个简单的界面,于是找了一个比较知名的开源前端 UI 库,非常好上手
几十分钟就写完了,非常不错 完全就按照 sample 拷的代码就行了 因为也只是需要一些基础的功能,显示个 alert ,做个 input 采集用户数据之类
调试时,发现了一个问题,UI 组件之间的排列逻辑有点小问题,于是!important 一把梭 完成任务收工
闲下来了,觉得这问题肯定不是我一个人遇到的,就去了 github 提了个 issue 标签 bug
就像我前面说的,我也不是前端,基本停留在知道 dom 是啥会 getElementById 和理解简单 js 语法的程度
问题所在呢,就是这个 UI 库提供了一个组件,就是整个屏幕都变成半透明灰色没法点,然后中间弹一个类似桌面程序 modal 窗口的的框弹出的是白色的框,产生反差,里面可以自由发挥 html 代码的组件 不知道这玩意你们一般叫啥
这个组件显示是正常的,我完全 copy 的手册的代码,只是把中间的文字替换成了我要显示的文字
然后无意发现,这个组件下面的基本布局组件里有个色块,不会被变灰遮挡,也不会被弹出的 modal 窗口遮挡,modal 窗口正中间有个超级鲜艳的色块
我对 html 还是有点概念的,这应该是下面那个组件里有一部分颜色功能用了 relative/absolute 定位(这玩意不存在用 fixed 定位吧)给了个 z-index 1 导致的问题 相当于类似 floating 的状态
他 z-index 给 1 是因为他想让这个东西显示在他那个组件内部的基准层上面 1 层
而这个白色的框是 display:block 的 普通定位 就到下面去了
这里我最开始犯了个错误 因为这个 modal 状态 F12 不好定位 而 html 是通过前端框架渲染的 代码里写的是模板 所以我漏掉了 直接看那个白色框的 block 的状态 position 是默认值 刚开始以为这个组件整体不是 floating 的状态
提完了 issue 很快维护的大佬就来解答了
他纠正了我的错误分析 告诉我这个组件都是非默认 position 的
然后我又回去仔细找了下,确实,那个背景整体变灰是个 fixed 的 width height 都是 100%的 div 且 z-index 是 1
两个 z-index 都是 1 结果就是按定义顺序了 问题发现
维护的大佬纠正的我的想法时,另外说到: “这是个 z-index 合不合理的问题”
我认为这不合理,我就反问了一句,那你认为这种 modal 功能而论,给 1 的 z-index 到底合不合理?说这话时候,我认为这不合理。我认为这种组件默认应该有一个较高的 z-index 。没必要最高给个 2000 但是高于一般组件 让这个东西确实能遮住大部分组件,应该是正常人类应该有的思维吧?
到这里,我这个职业杠精八代高低杠转世都没想杠什么,您说了,我就一提,委婉的表示了一下我认为这个不太合理,咱是不是要在远期版本改进一下这个默认值 改个 3 或者 5 之类 这就完事了
然后就得到了一个公式化的答复
“它们的层级是一样的,所以最终它们展示上的层级和在文档流的顺序也有关系。修改默认的 z-index 值属于 breaking change 。不过提供了 z-index 的 prop 和 css 变量,你可以根据项目的实际情况进行配置。”
说实话,这玩意我已经改完了,也没用他的方法,因为文档里压根就没写过这玩意要怎么改,变量在哪也没看到,也没有说明。我不觉得一个公开的知名的广泛传播的开源组件,我不过分的基础用法使用它还得去看他源码怎么写的才能正常用
然后我就吐槽了一句,贵司果然大厂风范。然后我就主动 close 了这个 issue 。 毕竟大周末的,不是带薪抬杠,跟大佬在 github 杠不划算……
为啥大厂风范呢?因为这个开源代码在某个大厂的组织下,而不是在个人作者名下。项目简介明确写道是该厂开源产品,且用了该厂商标。
都 closed 了的,该大佬又跑来跟我一顿解释。
可是我就想知道,大佬认为这个到底合不合理,我就杠了一下 我只是想知道你认为到底合不合理
然后又换来了长篇大论的解释……
可是我只是想知道,到底大佬们怎么想的,这种设计到底合不合理。你要觉得合理,你就告诉我合理,以后我也多学习学习怎么设计这种合理。
我就又补充了一句,我只是想知道到底合不合理,能不能用一个字或者两个字告诉我到底合理不合理。我说大厂风范,就是指的这种从不正面面对问题,顾左右耳言他的行为
然后,我就又收获了更长的一篇长篇大论……
这次还用 markdown 给我列了 1 2 3 4
其中第四条是
“默认的值无论是什么都有可能在某个场景下是不合理的。”
我就想知道,现在程序员的群体里,都已经这样了么?话不能直接说,沟通不能简洁有效 什么都得长篇大论,生怕触动了原始写这段代码的巨佬的权威
你觉得合理,你就明确的告诉我合理,我也接受就完事了
原来是你呀。
原来是你啊
遮罩层。我觉得问题在你,人家都详细的写出他的意见了,尽力给出一个能够说服你的理由。你不认同还反手给人扣上“沟通不够简洁,理由不够合理”的帽子挂人。
你这个不叫吐槽,叫阴阳怪气
有没有可能,大佬维护的厂里主导的开源项目算是工作内容,跟个人项目不一样,说什么也有工作纪律管着的。
开源项目礼节: developer.mozilla.org/zh-CN/docs/MDN/Community/Open_source_etiquette
你的描述来看,大佬对人对事不对人,你对人不对事
#3 #4 我也没想去开盒谁或者那个项目我没觉得自己没问题合理不合理的问题是他提出的 我就想知道这个 在大佬的想法里 到底合不合理 一句话的事儿 你要说合理 那我就反思反思我自己是不是看的不够高既然认为合理 那就直接说出来好了 爱挂人的,随便挂 无论 V2 还是 GH 这个账号都是纯匿名的反人肉号 不跟现实发生关系
#7 如果不是总是得到顾左右而言它从不正面回答问题的答复,能杠起来?
要是我就喷一顿拉黑了
经典的 z-index=1 ,不过你这个"那没问题了 贵司果然大厂风范 领教了" 不就是来吵架了么
#10 那就拉黑呗反正我是敢直接的表达观点:我认为这个不合理但是大佬,他就不敢说 “我认为这个合理” “我认为这个有一定合理性”
“修改默认的 z-index 值属于 breaking change”没毛病啊,比如页面有个在线客服图标需要一直在最上面,总不能突然升级一下就把这个图标给盖住了吧?人家解释那么多就已经告诉你不合理了。
#11 反正我是敢直接的表达观点:我认为这个不合理但是大佬,他就不敢说 “我认为这个合理” “我认为这个有一定合理性”
#13 我也没要求项目组现在就去改,或者因为一个外行的想法就去改项目我只是想知道这个设计到底合不合理?就算他不合理,不去改也是可以接受的,因为多少生产环境在用,总不能因为这点破事造成一堆事故
我突然想起了以前我也在这个问题纠结过。 getbootstrap.com/docs/5.0/layout/z-index/ 这里贴一下 bootstrap 的文档。
太长不看系列- 一次 github 跟开源大佬的抬杠经历:这是一个 V2EX 的社区帖子,作者 realpg 分享了他在使用一个大厂开源的前端 UI 库时,发现了一个 z-index 的问题,并在 github 上提了一个 issue 。他描述了他和维护者的对话过程,以及他对维护者的不满和吐槽。- z-index 的问题:作者发现了一个 UI 库提供的一个 modal 组件(类似桌面程序的弹出窗口)的问题,就是这个组件下面的基本布局组件里有个色块,不会被变灰遮挡,也不会被弹出的 modal 窗口遮挡,造成视觉上的干扰。作者认为这是因为这个色块的 z-index 设置为 1 ,而 modal 组件的 z-index 也是 1 ,导致了层级冲突。作者认为这个设计是不合理的,modal 组件应该有一个较高的 z-index ,以确保能遮住大部分组件。¹[1]- 维护者的回复:维护者很快回复了作者的 issue ,纠正了作者的一些错误分析,解释了这个问题的原因和解决方法。维护者说这个问题是因为 modal 组件和色块组件的层级是一样的,所以最终的展示顺序和文档流的顺序有关。维护者说修改默认的 z-index 值属于 breaking change ,不过提供了 z-index 的 prop 和 css 变量,可以根据项目的实际情况进行配置。²[2]³[3]- 作者的反应:作者对维护者的回复不满意,觉得维护者没有正面回答他的问题,也没有承认这个设计的不合理性。作者还觉得维护者的解决方法不够明确和方便,需要去看源码才能知道怎么改。作者就阴阳怪气地说了一句“那没问题了 贵司果然大厂风范 领教了”,并主动关闭了这个 issue 。作者说他只是想知道维护者到底认为这个设计合不合理,而不是想听一堆长篇大论的解释。⁴[4]作者说这就是大厂风范,就是指的这种从不正面面对问题,顾左右而言他的行为。⁵[5]- 其他人的评论:这个帖子引起了一些其他人的评论,有的人认同作者的观点,有的人觉得作者是在杠精,有的人给出了一些开源项目礼节的建议。
没看具体争论内容,不过我就按你的文字来说说我的看法默认的值无论是什么都有可能在某个场景下是不合理的。这句话,确实没啥毛病,只不过,也确实不是很恰当,因为几乎所有问题都可以这样回答,显然是属于消极的回复,肯定带点情绪,不过那毕竟是别人不过你也可以改一改回复的形式,可以避免类似这样无谓的争论。例如当你说 “这是个 z-index 合不合理的问题”的时候,虽然没有明确,你自己也可能没有意识到,但这某种意义上就是在批判作者当初做的这个决定是否是不好的(这是合不合理的问题 -> 这个决定不合理 -> “你”做出的这个决定不好 -> “你不好”),也许对方比较敏感,被否定的时候下意识的就开始维护自己,那自然就容易引发对抗心理。如果改一下提法,比如说换一种弱化的语气,“我们可以探讨一下这个 z-index 的设计在当初是否有别的考虑”,这样既能保留讨论问题的空间,也不会把问题直接指向对对方具体的人或者决策的否定,而是引导对方重新思考当初的设计,这样就可以得到更有建设性的讨论了
大佬只是委婉了一点,说你的建议不合理。至于 zindex=1 合不合理,很难说,是因为历史问题,不要有 break change 是开源项目素养之一。就好像你现在跑去质问为什么 java 还用 jit ,不用 aot ,这哪里说的通?
#15这只是由开发者自由约束的事情,你认为合理就是合理,别人认为不合理也没问题。你可以选择一直这么较真儿下去,那你就是对的。文无第一,武无第二。
你可能没意识到这一点:非熟人是不了解你的习惯有没有恶意的,为了避免这种不了解导致的误会,我们一般会说的更礼貌更友善一些。
高情商
z-index 2000 可能还不如 z-index 1 高
虽然我觉得你说的可能是 ali 的开源库,但是你提到的维护大佬说得还是合理的 :)
从你的描述来看, 人家好心好意耐心地解释, 没看到哪里摆谱了, 而你却阴阳怪气的.
我站开源大佬, 人家已经很客气了, 再说你又不是甲方, 也没 donate, 人家能回复还帮你解决了问题已经是仗义, 没义务被你指手画脚
你就说到底合不合理,这不就是一个典型的二极管问题。。人家也说了,不管哪种方案都有可能存在问题,那意思就是现在只能是个妥协解,还找不到最优解,就这么难理解么,非这么咄咄逼人干啥
这个年代,没想到好好说话居然成了一种稀有的品质。
珍德食泥鸭 来网曝自己啦
本来想发帖找认同的, 结果被一顿怼, 笑死人.
开源作者合理而且很专业,你就纯阴阳怪气
z-index: 1 是符合规范的,而 9999 是为了图省事
人家这话里的意思不就是 z-index 合不合理很难讲吗?事实上这东西就是没法评价合不合理。人家还给你说明白了可以如何调整,你来句“果然大厂风范”,我倒是想知道你是什么意思了。打架?还是说你只能理解合理/不合理这种二值逻辑?
换成后端就是:某个接口的输出原本是 int ,更新版本后变成了 float 。
大佬耐心告诉你背后的原因也能被挂如果他只回了个合理并关闭了 issue 估计会被你喷大厂的人真高傲吧
你觉得不合理可以去个 pull ,被拒时会告诉你原因,而不是阴阳怪气
嘴硬的典型
"我这个职业杠精八代高低杠转世" 全盘为数不多的正确结论
作为开源项目的维护者( dperf dperf.org/ 项目,不是这个项目),谈谈我的感受,供参考。开源项目的维护者大多数是出于兴趣,责任感,是一些很单纯的程序员,除了一些虚名,也谈不上什么好处,希望社区里的小伙伴多一些理解、尊重、友善。提 issue 时,做到表述清楚,理由充分,能够节约维护者的时间(维护者往往是非常非常忙的),想象维护者一个人面对多少用户。
- 不是 OP 擅长领域2. OP 产生疑惑发问、对方给耐心讲解,OP 看不懂反倒觉得被敷衍多数人都会有这种浮躁的时候、很正常,OP 平常心一些
感觉再网曝自己
就算看不懂他这么回复也很怪吧,正常一点的回复甚至可以是要求对方手把手教,起码是正常回复
感觉楼主这是心态问题,建议找时间休息休息调整一下
你这...
欢迎 PR
1.你作为一个新手,竟然没有新手的觉悟,你为什么觉得你有能力给人家提正确的意见?2.阴阳怪气。3.只论方案,人家说的毫无问题,"默认的值无论是什么都有可能在某个场景下是不合理的",这句话非常正确。组件提供了 prop ,我使用 z-index=1 是非常正确的方案。最后反问 op ,“现在程序员的群体里,都已经这样了么?”,你说人家“你觉得合理,你就明确的告诉我合理,我也接受就完事了”,又觉得人家“沟通不能简洁有效 什么都得长篇大论”。请问人家要怎么才能明确的告诉你合理?再来论坛写个小作文,绝了
github.com/youzan/vant/issues/12453我觉得人家的回复专业且耐心且合理,你就在阴阳怪气二极管
开源社区相信伸手党,实在看不下去就用 forked 和 PR 狠狠地踹开源大佬的屁股就行。
开源社区不相信伸手党...
太长不看,文字叙述应该回炉重造语文
绷不住了,人家因为你这个 issue 还特地开了个 pr 增加关于这个的 demo
翻译一下 OP:你怎么可以有礼貌?你怎么可以讲道理?你怎么可以拒绝承认世间万物是可以一句话描述清楚的。你怎么不看看我?我怎么就可以直接扣帽子?我怎么就可以面对友好的社区环境阴阳怪气?我怎么就可以勇敢的向这个世界展示自己的无知与愚昧?
感谢传送门,看了完整事件~感觉 op 在挂自己。。。
你也是个老面孔了,干这事确实不在理。。。 人家对这个问题详细解释是好事
难绷
怎么还有你这样的人啊?
就是因为有楼主这样的人存在,我(非公司项目)看到用户开的 issue 过于初级都懒得回复。因为表现出比他更完整的思考就会被理解成对他的技术鄙视,然后收到无能为力却又不甘心承认的人最擅长的转移话题阴阳怪气
我遇到这种人一般不回复冷处理,这样会减少很多烦心事。因为你可能一不小心说错话,别人就去写小作文了。这件事的开源大佬说话有理有据,没任何过分的地方。想象一下,他要稍微说过一点,还不背网友口诛笔伐喷到死。
看了 issue 总结一下:OP 又菜又傲慢,跟 OP 这种人废话半个字都是浪费人生
我认为维护者还能好好维护就很好了,而且还帮忙解决问题,提出很好的建议,这还不够吗?人家代码直接给你写了才行?你这种人也是够了,饭来张口?
贴个地址让大家瞧瞧,顺便看看能不能解决你的问题 😅
你就是个纯杠精,看见大家都在骂你我就放心了。你的想法:我觉得不合理所以需要改对方的想法:虽然不合理但是没必要改你如果不是给项目提建议,就是想知道对方的想法,何必在这个项目里提 issue ?所以你并不是只是单纯的想知道对方是否觉得合理你先搞清楚你在干什么,再搞清楚你在说什么,最重要的是搞清楚你想要的是什么
你自己跳出来要被网暴? z-index 无论设置成啥在部分场景下都是不合理的,你的世界只有 0 和 1 ,没有 0-1 的中间态吗?去看了 issue 只感觉到你既无知也没礼貌。
这么多人都觉得你不对,不会承认自己错误然后 append 一份道歉吗
自己挂自己。这脑回路前所未现
牛,把 issue 从上到下看了一遍,目前只发现 OP 在阴阳怪气人,这个作者也说了“由用户自己根据需要配置层级”,所以这有什么好纠结的,这不算 bug 仅仅是设计上规避一些冲突,不要那么浮躁。
一句话能说清楚的事非要说十句话,楼主想吐槽的就是这个吧?理解楼主的吐槽。越是水平高,官职大的人,回答问题越严谨,又或者说说话长篇大论。(俗称打官腔)他们不会简单的 回答是 or 否,通常是不给结论或者列出 1234 让你自己“悟”出结论。
怕是 100 个人里有 99.9 个人都认为你的态度不好,老老实实认个错吧
自挂东南枝,小丑竟是你自己
受不了了,直接把 op 这个傻逼拉黑了
老哥是想要明确的对于他这个问题的答案,yes or no,但是这个问题对于对方来看没法给出十分明确的答案,看场景,并给出一系列理由阐述自己的观点。而老哥只是想让对方明确的回答他的问题就行了。而对方确实根据他的判断没法简单地给出十分明确也就是是还不是的答案。这也说明了,与其问别人,其实还不如自己试一下,自己思考一下,这也是很多人问问题能听懂别人说的啥其实对问题本身就知道的大差不差的,要是一点不知道,别人说的就跟没说一样,哪怕喂到嘴里还是不知道。所以结论是,自己多试多写写多想想,自己对自己的问题才是最清楚的
我理解其实对方已经说的挺明确的了吧?开源组件的代码本身大部分并不是给某个特定唯一场景使用的,那么“默认值”这个事情对于 A 用户和 B 用户的理解本身就是不一样的。这不是很正常的事么?
看了一下发帖历史,已经不是第一次这么干了,这过去一年多了,还一点没成长,挺为一个公司里面同为同事的人难过的,这都啥人啊...
"不愧大厂风范"什么人会在 issue 里这样回复?
看笑了😂
全世界我最牛逼?😂不要试图在人家专业领域打败人家。
说真的,我建议你去看看心理医生,你的精神状态不像是正常的样子。
看到 GitHub 那么多踩我就放心了: github.com/youzan/vant/issues/12453#issuecomment-1817456536
github.com/youzan/vant/issues/12453#issuecomment-1817456536 👎
OP 戾气太重了啊, 好好讨论别扣帽子不好吗
其实你完全可以写一个这块的补充说明,一来帮助后来者,二来也帮助大佬完善项目,基于合作的理念对大家和自己都好,可你偏偏选择了对抗,看来是被茧中互联网影响太深了
首先问题描述尽量精简,这样一大串文字,真的没法看
楼主可能没修过人文学科或管理学科,这个领域内,存在很多问题,并没有 yes 或 no 的回答,而是有很多单一分支或叠加分支,要根据喜好、对利益与风险的判断,才能做最终决定。
我就想知道,现在程序员的群体里,都已经这样了么?话不能直接说,沟通不能简洁有效 什么都得长篇大论,生怕这个主题有 2138 个字符长。
op 觉得看大佬的详细解释不如“合理”两字学到的多?
卧槽回复你的那个大佬也太有耐心了吧
大佬愿意解释原因原理你还不乐意 感觉你不适合做技术
先叠个盾: 感谢所有开源作者的贡献叠甲无效,纯纯的暴躁不讲理的 issue author 。维护者已经是在将技术细节了,而你只是在胡搅蛮缠。
贴个链接吧,以免大家不知道发生了什么 github.com/youzan/vant/issues/12453
对于 op 这种人,回复直接扣帽子就行了。“你个三流程序员也不配用我们的插件,用也用不懂,issue closed”
op 到底对不对我不知道,但是哪个回 issue 的作者真的很有耐心了
OP 真是逆天的玩意,喜加一
虽然楼主确实有毛病,但是这个也确实是 bug 啊,自己框架组件的遮罩层默认不能将自己其他组件遮挡住,这是妥妥的 bug 。
我感觉开发者更多的是在回应 modal 的 z-index 是否合理,我个人感觉这里是没有问题的,如上面 v 友所说 breaking change 是一方面,可以自定义 z-index 也是一方面。但是 tab 的底部边框为什么需要通过 z-index 来控制,这个才是更让我在意的
看到大家都在骂你,我就放心了。
退一万步,我假设 OP 的意见是完全正确的,即使在这种前提下,OP 的态度也太嚣张了,得理不饶人,何必呢?就算你占理吧,“你们是大厂风范,你们不正面回答就相当于说:用户,我是你爸爸” 这种话也是不能说的啊,你这样说话,有理也变无理了。有人的地方就有江湖,不可能只看技术,不可能完全不看人情世故的。更何况这只是一件小事,要是你抓住的是对方的巨大漏洞、巨大错误,你嚣张没问题,但你只抓住别人的一个小问题…… 你想想,如果我捉住你一个标点符号的错误,就大骂你是文盲,你觉得怎么样?你的标点是错了,我在“技术上”完全正确,我就能骂你文盲吗,显然不能。
减少攻击性很重要,别人认真耐心回答你的问题是出于礼貌和素养
已拉黑
没有谦卑之心 进步有上限
这个世界从来都不会缺少另类的东西,人类自然世界如此,计算机世界也一样。编程语言方面,看过本站《6个变态的C语言Hello World程序》的朋友们一定对BT和另类不会陌生,但那…
如果共用一个,为了避免 id 重复,还得加 id 前缀,同时有些数据更新频繁,这样也会影响到那些更新不频繁的数据的实时性,但是开多个,也会有维护多个实例的负担,大家都是怎么考虑…
比如说 String s = "hallo world"; 在不创建新的 string 下, 把 s 修改成 s = "hello world"; 怎么做, 兄弟们... 重…