当前位置: 首页 > Web前端 > HTML

IOING开发大型SPA应用需要哪些技术条件?

时间:2023-04-03 00:41:46 HTML

前言在公众号《前端早读课》推文之前(在此感谢),很多同学在下方留言,问我Ionic和IOING是什么关系?从名字上看,虽然都是以IO开头,但是彼此没有任何关系,一点关系都没有。IOING是一个高性能的前端开发引擎。提供了创建大型应用的一整套解决方案,如页面模块化拆分、分层路由控制、可编程CSS、热插拔组件、双向数据绑定、DOM语法扩展、自动兼容处理等。IOING的历史大概已经使用了5年,一直作为私有项目使用,最近也发布了使用文档。之前我用其中的两个功能点作为推广的测试,所以收到了很多朋友的邮件和微信表达了对这个项目的兴趣,所以我觉得IOING的用户接受度很高,所以就有了这篇文章讨论了IOING的独特性。SPA申请应具备的技术条件。条件一:作为一个应用,自己的滚动应该和WEB体验有明显的区别。首先,主要体现在布局上。从外观上看,它更像是一个App。例如,您的WebApp应该有页眉和页脚。当然,这些技术实现起来都比较简单。稍微复杂一点的例子是多个滚动嵌套视图,比如下面的效果(例子:1-1)这个例子中有3个可滚动区域,一个是最外层的父滚动,另外两个是tab的子滚动页面,子滚动和父滚动有交互传递事件(例子:1-2)比如1-2,比较复杂。首先,最外层是页面滚动,组件的父级是水平滑动。左右滑动时,切换不同的标签。当鼠标上下滑动到底时,也需要切换卡片。有很多子滚动,那么多层嵌套的滚动效果,对于前端开发来说无疑是一个很大的工作量,但是抽象出来需要什么呢?我们需要一个强大的滚动API,而浏览器并没有提供。除了可怜的body滚动,我们可用的滚动还可以使用overflow-scrolling:touch来支持区域滚动。body滚动仅限于window,scrollbar会覆盖header和footer,在不同设备上非常难看。滚动惯性也不一致,效果很差。除了兼容性问题外,overflow-scrolling基本没有自己的API,只能放弃以上方案,自己造轮子。js滚动库也有很多问题。iscroll.js是一个著名的滚动库。先简单说一下js滚动库的缺点。CSS布局不当会导致其性能急剧下降,无法通过设置0s动画来停止当前CSS3动画的兼容性问题内容更新时,滚动对象的大数据列表无法及时更新,导致资源不足GPU内存,导致严重卡顿。Android中触摸反馈动画掉帧严重。嗯,好像问题很多。要解决这个问题,必须要从很多方面入手,这里就不细说了,只是简单说一下IOING中与这里相关的另一个魔法:DOM引擎,通过它可以解决很多问题自动处理,比如创建一个像下面这样的滚动控件模块控制和沙箱机制作为一个App,功能模块之间的切换必须保持状态是的,即各个模块的浏览痕迹不能被破坏。比如你在A列表页面浏览,看到有一段内容吸引了你,就点击B内容页面。当你点击时,会用一个动画来连接A列表页面和B内容页面。同时在内容页面上进行动画过渡。这时,两个模块都必须有自己的滚动控件。返回时,A列表页面要停留在历史位置。上面已经解决了滚动控件的问题。除了历史位置的问题,完成模块切换还有更多的问题:加载的模块越来越多,所有人都堆在同一个DOMTree下,这必然会带来高耦合,同时庞大的DOM树也造成了严重的性能问题。当这些功能模块的CSS、Js、html放在一起时,将难以避免相互影响,导致难以测试的bug。高耦合下,模块卸载时很难卸载。剩下的全局变量或者僵尸事件总会影响后续的操作。直接访问任何路由页面时,返回时应能回到程序主界面。应根据应用程序级别返回历史记录。例如访问历史:商品列表页-详情页-订购页-支付页-支付完成页,此时如果用户完成交易后点击返回,不应进入订单页和支付页,而应进入直接进入详情页或者列表页,所以一定要有路由控制的解决方案。模块不能直接操作,要有通信规范。模块在缓存时应该有生命周期管理,保证模块正常更新。模块数据资源也应该有生命周期管理。为了保证数据的正常更新,模块的更新操作要保证新旧数据之间不会出现白屏。模块应该有自己的资源管理、数据管理、事件管理、配置管理等方案。模块智能预加载方案模块类型方案:嵌入式模块、系统模块、独立模块、不同类型模块的转场,并提供动画接口保证动画性能。需要建立一个动画队列,统一封装所有的动画操作。以上部分都是当你决定做模块页面转换的时候。除了这些主要问题之外,还有很多细节需要考虑,比如如何在动画之前快速渲染指定的加载模块等等。在模块中,可以为模块配置自定义函数动画,也可以使用内置的默认动画实现如下效果:animation:'fade'animation:'flip'animation:'zoom'animation:'slide'对于模块管理,IOING设计了很多解决方案,比如资源管理,IOING通过一个配置文件(moduleconfigurationfile)进行统一管理。模块配置文件描述了模块的资源库、类型、事件、级别、运行方式、转场动画,其中sandbox项允许模块运行在沙盒下,即保证模块有自己的独立的运行空间。条件三:可插拔组件和组件通信其实在webComponent技术规范出现之前,我们就一直在使用web组件。最常见的Web组件就是input,那么如何实现一个input这样的组件呢?浏览器需要支持以下功能:1.自定义元素2。模板3。影子DOM4。5。浏览器本身需要为这些功能实现HTML导入。当满足这些条件时,就需要找到一个完美的降解方案。例如,在IOING中使用标签可以新建一个ShadowDom,保证新增元素不会增加外部高耦合(例3-1)。这个例子中的一个组件在浏览器中呈现的结构涉及到一个问题,当你在一个或多个模块中对同一个组件有多个引用时:组件通信。比如每个组件副本需要获取一份数据,如果每个组件单独获取数据源显然是不正确的,那么就需要一个主控制器来进行数据管理。另一个例子是你有一个开关。组件在多个模块中被引用。这时,当你关闭其中一个开关组件时,数据应该同步到所有其他开关组件。条件四:可编程的CSS和物理像素做过手机h5开发的同学应该都有体会,尤其是在ios上,1px总是比想象中的粗,因为很多前端用户都抱怨过这个问题。那么为什么会出现这样的问题呢?这是因为手机的分辨率越来越高了。如果你把iphone的1px像素和普通pc显示器的1px进行比较,你会发现iphone的1px要小很多,这个比标准像素小的倍数就是我们常说的devicePixelRatio,因为像素变小了,同样的页面在iphone上看应该更小,也正是因为这个问题,viewport诞生了。视口的作用就像按比例拉伸图片。最终图像中的1px细节受到明显影响,包子线效果丢失。因此,我们首先要做的就是把视口特征干掉,干掉之后我们需要一个新的单位来解决适配问题,所以我们就有了一个新的单位dpdp=densitypx=devicePixelRatio*px当然,dp是不够的,我们还需要结合vm,vh,vw等来做更多的适配工作,但是并不是所有的设备都支持这些单位,所以我们还需要一个CSS引擎来处理这些问题,比如calccalculationdiv{width:calc(50vw-20dp+1px)}多个单元联合计算的场景在App设计过程中很常见,如果不兼容,会极大影响开发效率再比如,高度你的应用程序中的标题等于60dp,它也有1px边框,所以在DPI为3的设备上应该等于181px,在DPI为2的设备上应该等于121dp。在CSS中另一个模块,当我们想知道header的高度时,也应该有一个模块之间共享数据的机制,在IOING/*mainmoduleCSSfile*/@global{header-height:calc(60dp+1px);}/*模块CSS文件*/div{top:[header-height];}有时候仅仅满足CSS中的变量替换是不够的,我们还需要支持在CSS中引入模块数据源,就像模板语法一样,CSS也应该有自己的逻辑语法@if(device.os.ios){header{背景滤镜:模糊(20dp);}}更多用法,关注这里http://ioing.com/#docs-css-scope/华丽的分割线什么是QAIOING?IOING是一个高性能的前端开发引擎。提供一整套创建大型应用的解决方案,如页面模块化拆分、分层路由控制、可编程CSS、热插拔组件、双向数据绑定、DOM语法扩展、自动兼容处理等。IOING项目还需要SASS、LESS、Stylus等?不必要。IOING是一个纯前端引擎,所有的服务都是前端运行的结果。IOING与React、Vue和Angular之间有什么区别?IOING从容器层解决很多web开发问题,目的是提供一套完整的SPA开发解决方案,而不是解决某些方面的问题。结束IOING的文档目前还不完善,但完全可以满足必要的开发。后续我会持续更新文档,欢迎对IOING感兴趣的同学关注我的公众号或者star我的项目地址:https://github.com/ioing/IOING公众号请扫码: