关于瀑布流:瀑布流自实现思想及踩坑记录

工作我的项目实现瀑布流向上滚动到顶加载上一页,向下滚动到底加载下一页。依据最小高度优先排列。 设计思维v1: 一开始需要只有向下滚动到底加载下一页,默认初始加载第一页。从左到右从上到下排列。判断滚动条达到底部发出请求加载下一页。列数不是固定的,依据window的宽度跟单卡宽度的比照确定以后展现的列数,依据列数循环加载单卡,设置单卡的top和left款式。left能够间接依据index和列数来确定。top须要计算当前列之前数据的高度总和。v2: 单卡中图片的高度差距较大导致在每列数据个数雷同的状况下,高度差有可能很大。界面不美观。需要更新为按以后高度最小列排放数据。多增加了一个记录高度的数组变量,渲染也变成了优先渲染列数的div,每列div渲染该列的数据。须要先依据列数将以后已存在的数据结构变更成二元数组,不便后续渲染。每列的div只用依据列数设置left,每列中的数据只用依据当前列该数据之前的数据高度和来设置top。v3: 列表模式和网格模式切换时,牵扯到数据更新的问题。需要设定,列表模式跳转到网格模式时,网格模式应该对应显示当前页,即列表模式为第三页则网格模式显示第三页。需要减少向上滚动到顶加载上一页的性能。 抉择的计划监控滚动条的计划:onScroll办法,用Ref绑定滚动条组件范畴。用钩子生成onScroll监控滚动条变动时进行函数内操作。也就是说,每次检测到滚动条变动都会去判断是否达到顶部或者达到底部,进而进行申请和数据更新。如果是上一页的数据,须要将新数据增加到原有数据之前并从新进行排列和渲染,如果是下一页数据,须要将新数据增加到原有数据之后,只须要排列渲染新数据。 遇到的问题如果只在页面初始加载时生成一次onScroll,后续绑定事件不会更新,只会有限加载第二页,useEffect闭包问题。若每次检测到滚动条变动就生成一次onScroll就须要防抖计划。scrollTop + clientHeight 与 scrollHeight 达到底部时会呈现不出名的0.几的误差,问题临时不晓得是为什么。会导致经常出现滚动条到底部但未能触发到底部操作的问题。所以通过判断时scrollHeight - 1来解决,然而这样就有一个新问题。本来只有到scrollTop + clientHeight >= scrollHeight这个节点才会触发一次onScroll到底操作,当初因为这1高度的差值导致在这1高度中会呈现反复申请的问题,会呈现一次加载多页但加载不齐全问题,须要防抖或者管制申请完结前不会再次触发申请。在页面加载最初一页时,有可能会因为数据有余而导致渲染高度不够未呈现滚动条的状况,无奈进行滚动条触发申请。所以在判断当前页为最初一页时,判断列最大高度是否超过scrollHeight,如果未超过,则给他底部增加填充div用来撑起页面使滚动条显示。在页面初始渲染胜利时,不论是在哪一页,滚动条都默认是顶部。在不触发向下滚动操作时,无奈向上滚动,无奈进行加载上一页的申请。所以在页码非第一页时,给顶部填充10px的div并将滚动条设定在10px的高度。使得视觉上和原来没有区别,并且有肯定向上滚动区间去触发加载上一页操作。因为未留神,用index值来作为列的key值导致从新渲染页面时,会呈现上一次数据的残留冗余。其余办法间接在滚动条所在div中应用onScrollCapture来监控滚动条变动,不会有闭包问题,也没有呈现高度差问题。用现有的上拉加载下拉刷新组件(尝试、学习中)

June 23, 2022 · 1 min · jiezi

关于瀑布流:js-实现瀑布流排流

成果预览 //在所需应用瀑布流的页面监听resize window.onresize = function () { waterFall();};//触发计算函数// perItem 为瀑布流的 每个盒子function waterFall() { // await setTimeout(() => { var items = document.getElementsByClassName("perItem"); // }, 500); var gap = 10; //首先确定列数 = 页面的宽度 / 图片的宽度 var pageWidth = getClient().width; var itemWidth = 550; var columns = parseInt(pageWidth / (itemWidth + gap)); var arr = []; //定义一个数组,用来存储元素的高度 for (var i = 0; i < items.length; i++) { if (i < columns) { //满足这个条件则阐明在第一行,文章外面有提到 items[i].style.top = 0; items[i].style.left = (itemWidth + gap) * i + "px"; arr.push(items[i].offsetHeight); } else { //其余行,先找出最小高度列,和索引 //假如最小高度是第一个元素 var minHeight = arr[0]; var index = 0; for (var j = 0; j < arr.length; j++) { //找出最小高度 if (minHeight > arr[j]) { minHeight = arr[j]; index = j; } } //设置下一行的第一个盒子的地位 //top值就是最小列的高度+gap items[i].style.top = arr[index] + gap + "px"; items[i].style.left = items[index].offsetLeft + "px"; //批改最小列的高度 //最小列的高度 = 以后本人的高度 + 拼接过去的高度 + 间隙的高度 arr[index] = arr[index] + items[i].offsetHeight + gap; } }}function getClient() { return { width: window.innerWidth || document.documentElement.clientWidth || document.body.clientWidth, height: window.innerHeight || document.documentElement.clientHeight || document.body.clientHeight, };}

May 29, 2021 · 1 min · jiezi

关于瀑布流:四种常见研发模式及其优缺点对比-IDCF

一、瀑布模型1.1 模型介绍1970年温斯顿-罗伊斯提出。将软件生存周期的各项流动规定为按固定程序而连贯的若干阶段工作,形如瀑布流水,最终失去软件产品。 1.2 核心思想按工序将问题化简,将性能的实现与设计离开,便于分工协作,即采纳结构化的剖析与设计办法将逻辑实现与物理实现离开。将软件生命周期划分为制订打算、需要剖析、软件设计、程序编写、软件测试和运行保护等六个根本流动,并且规定了它们自上而下、互相连接的固定秩序,如同瀑布流水,逐级着落。 1.3 模型毛病各阶段齐全固定,输入大量文档,极大减少工作量;线性开发,减少我的项目延期危险;不适应用户需要的变动。 二、迭代模型2.1 模型介绍RUP(对立开发过程)举荐的周期模型,被定义为: 迭代包含产生产品公布的全副开发流动及外围因素,相似小型的瀑布模型。 2.2 模型长处(与瀑布模型相比)升高了增量的危险;升高产品无奈按既定进度投入市场危险;放慢了整个开发工作的进度;迭代过程适应需要变动更容易。2.3 模型毛病在我的项目早起开发可能有所变动,对于开发人员要求及我的项目管理者能力有较高要求。三、螺旋模型3.1 模型介绍1988年,巴利-玻姆正式提出”螺旋模型“,它将瀑布模型和疾速原型模型联合起来,强调了其余模型所漠视的危险剖析,特地适宜于大型简单的零碎。危险驱动的办法体系。 3.2 模型长处设计的灵活性,能够在我的项目的各个阶段进行变更;以小的分段来构建大型零碎,成本计算更简略;客户始终参加每个阶段的开发,保障了我的项目不偏离正确方向及我的项目的可控性。3.3 模型毛病该模型强调危险剖析,让客户承受和信赖这种剖析形式是不易的;如果执行危险剖析影响我的项目利润,那么进行危险剖析毫无意义;研发人员应该善于发现危险,精确剖析危险,否则将会带来更大的危险。四、麻利开发4.1 模型介绍以迭代模型为实践根底,1990年开始逐步引起关注,包含XP、Scrum、FDD、DSDM、Crystal、ASD、Kanban、Lean等。强调研发团队与业务团队严密单干、面对面沟通、频繁交付版本、紧凑而自我组织型的团队。 4.2 模型长处通过疾速而继续交付有用的软件来满足客户的需要;强调人员和互动,而不是过程和工具。客户、开发人员和测试人员常常互相交换;频繁交付工作软件(几周而不是几个月);面对面交谈是最好的交换形式;业务与研发之间日常亲密的单干;继续关注技术的卓越水平和良好的设计;常常适应一直变动的环境。4.3 模型毛病必要的设计和文档不足器重;大型项目,开发初期,很难评估工作量;如果业务或客户不分明他们想要的最终后果,我的项目很容易偏离轨道。 起源:云栈技术CSTC作者:IDCF社区 Geekwolf

March 3, 2021 · 1 min · jiezi