布景
在移动端页面中，由于屏幕空间有限，导航条扮演着十分重要的角色，提供了快速导航到不同页面或功用的方法。用户也一般会在导航条中寻找他们感兴趣的内容，因而导航条的曝光率较高。在这样的布景下，提供一个动态灵敏的导航条，为产品赋能，变得特别重要。
运用原生导航栏现状
拿iOS原生导航条为例，导航条作为页面进出栈的根视图连接器，以及生命周期的管理器。特别是在作为webView Controller的父容器的时分，面对webview中h5页面灵敏的的路由特点，以及一些难料的反常情况，原生很难也不便于频繁操作根试图容器，因而也产生了一些功能差、体会差、开发本钱高、测验场景难掩盖等问题。安卓也有相似情况。
1、功能问题
•ssr预烘托时，无法对原生导航条进行预加载。对于百亿，廉价包邮等运用ssr预烘托的频道，由于原生导航栏无法进行预加载，导致上屏较慢等问题。
2、开发/测验本钱高
•原生导航条生命周期耦合。原生导航条作为webviewController的根容器，一旦操作时机不妥，很可能影响到线上页面，而且最大的问题在于这种场景测验很难掩盖。比方：window.href.url运用这种方法更新当时页面时，由于不同频道操作同一根导航条，会引发不可预知的问题；
•场景有限。站外场景无法运用原生导航条，一些事务方往往需求独自处理站内外，形成开发资源糟蹋。
3、体会差
•webview初始化时会预置一个默许的导航条，然后依据前端装备，再去设置导航条的不同样式，无法避免的存在一个过渡期，体会较差。
•window.location.reload()刷新当时页面的时分，即便是在js中躲藏了导航条，webview为了兼容一个线上问题，履行reload时此刻会先展现原生导航条，直到履行了js的躲藏逻辑，才会被躲藏，体会较差。
4、难扩展形成营销资源糟蹋
•无法扩展交互动效。得益于移动端页面中，导航条得天独厚的方位，产品往往期望有更生动的交互性，来进步曝光、粘性、活动触达率等。比方导航栏上挂载搜索框、以及吸顶、延伸动画、沉溺式、炫酷的营销icon等等。遗憾的是原生体系导航条不能全部支撑，其实无论从视图层级上来说，仍是从导航条职责上来说，apple并不期望过多操作导航栏上的元素。也就形成了高曝光方位的资源糟蹋。
5、依靠性强
•由于要依靠原生JS桥，就一定会存在版别约束问题。形成需求迭代慢，甚至随着时刻的推移，版别卡口原因无迹可寻，代码调整战战兢兢，版别审阅慢、周期长等问题。
解决方案
依据原生导航条现状，百亿补助频道沉淀出了通用H5导航条组件@pango/navigation-bar，具有以下优势：
1、功能好
•支撑ssr预烘托，上屏较快。
2、开发/测验本钱低
•人力节省百分之90%以上，以plus 95折为例，对接只需0.5/人日。
•无场景约束。可用于站内外，ssr以及csr场景，无需站内外多次开发。
•可装备。 @pango/navigation-bar运用config的形式装备item，这么做的好处是一旦事务需求改动，只需调整装备，无需调整组件逻辑，极大下降开发和测验本钱。另外假如你运用主站的webview而且装备了config，那么只需求简略的改动config，代码迁移本钱低。
•导航条在频道内和其他一般楼层无异，生命周期阻隔清晰，不会影响别的页面，测验本钱低。
•单向数据流规划，外部数据改变，组件UI及时响应，不存在原生的操作窗口问题，开发体会佳；
3、用户体会好
•生命周期和其他楼层保持同步，规避了原生容器和H5页面天然的生命周期无法同步的问题，也就不存在两者之间的过渡问题，体会佳。
4、灵敏定制
•选用左、中、右、状态栏、导航栏分层规划的形式，支撑传入React.ReactElement，比原生定制性更强，可灵敏定制现在站内绝大部分导航条样式以及交互动画，合理高效运用导航条资源；
5、机型、体系兼容性好
•参阅原生导航栏异形屏适配方案，参阅原生绝对布局思路，完美适配折叠屏、异形屏。
•iOS9 – 最新 、Android5 – 最新均兼容性杰出，未发现线上兼容反常。
6、不对外依靠
纯手工打造，未运用第三方库，不会对宿主形成依靠冲突，随时改动随时发布不存在版别控制，最大程度的下降和隔断对原生容器的版别依靠。
反常处理
原生导航条作为根试图容器，容器内人视图反常不会影响根试图的展现，所以不必特别处理html下载失利，js履行反常，服务挂掉等反常情况。但是H5导航条遇到这些反常情况，也要确保用户能够点击回来按钮回来上一页。
百补方案
现在方案已和通天塔以及hybrid团队打通，方案如下：
反常场景1：事务js履行反常。
• @pango/navigation-bar组件运用a标签烘托回来按钮，确保js履行反常时仍然展现回来按钮，而且能正常响应回来事情。
•事务展现兜底过错页时，会运用导航条兜底数据烘托导航条确保可回来上一级。
反常场景2：webview加载html失利。
为了消除上面说到的过渡问题，事务链接中新增了qurey参数hideNavi=1 ，原生webview会经过该字段在webview呈现之前躲藏导航条。但是因而也引发了一个风险：html加载失利时，会形成无头的问题。因而需求webview合作改造，一旦监测到html加载失利，原生webview要展现原生导航条。
反常场景3：通天塔服务反常。
同样是场景2中的问题，需求通天塔合作改造通天塔服务反常的场景：依据链接中hideNavi字段增加回来按钮或许通知webview展现默许导航条。
竞品和兄弟频道对比
调查多个竞品以及兄弟频道，发现在上述的反常场景2、3下，均未做特别处理，展现无头过错页。假如此刻原生禁用了右滑回来手势，页面将无法回来上一级，这无异是一个十分严峻的缺点（事实上有些竞品页面以及咱们某些频道的确无法回来上一级）。
线上项目
现在运用该组件的项目：百亿补助、月黑风高、PLUS95折。
线上效果展现
规划思路
参阅原生navigationBar的规划思路，把整个导航栏分为左、右、中三个区域，左、右区域依据内容自适应宽度，剩下空间为中心区域。左右区域接受items数组，可依据item接口协议设置左右的items，协议可自定义图片、尺度、事情、间距、下拉菜单、是否动画响应等，已默许包含了关注、回来、更多、频道logo等常用元素，当然如有需求也能够自定义一个React.ReactElement。中心区域只接受React.ReactElement，你能够自由定制元素，传入navigation-bar即可，一张图片一段文字，或许是一个搜索框……不管是伸缩或许是上滑吸顶，都可自定义。
@pango/navigation-bar
该组件运用react + ts开发，大小只要4.1K。
文件结构：
运用方法
安装
npm i @pango/navigation-bar --registry=http://registry.m.jd.com
装备
你能够自由装备items除了”follow", "more","back","logo"，这些已知的元素外还能够设置type:"common"，是一个通用类型的item;
scrollCallBack会回调上滑比例，可依据该比例做交互动画；
import {
BACK_ICON,
FEEDBACK_ICON,
FEEDBACK_URL,
INavigationParams,
MORE_ICON,
RULE_ICON,
SHARE_ICON,
} from "@pango/navigation-bar";
setH5NavigationButton = (headerData) => {
const extend = headerData?.navigationBar?.extend;
const followInfo = headerData?.navigationBar?.followInfo;
const follow = {
type: "follow",
collectionId: String(followInfo?.themeId),
gapWidth: 12,
width: 55,
height: 22,
};
const moreItem = {
type: "more",
menuBackgroundColor: "white",
img: MORE_ICON,
title: "更多",
menuList: [],
};
moreItem.menuList.push({
icon: RULE_ICON,
title: "规矩页",
menuEventData: extend?.guideUrl,
});
moreItem.menuList.push({
icon: SHARE_ICON,
title: "共享",
type: "share",
menuEventData: extend?.share,
});
const backItem = {
type: "back",
img: BACK_ICON,
canClick: !margicWindow,
title: "回来",
};
const backLogo = {
type: "logo",
img: DEFAULT_LOGO,
isAnimation: true,
gapWidth: 5,
width: 176,
height: 34
};
const navBarParams: INavigationParams = {
leftItems: [],
rightItems: [],
backgroundColor: "#FD4D00",
navHeight: this.status.navHeight,
};
navBarParams.leftItems.push(backItem， backLogo);
navBarParams.rightItems.push(moreItem, follow);
navBarParams.titleImgItem = TitleSearch({});
navBarParams.scrollCallBack = (scale) => {
this.setStatus({
navigationBarParams: Object.assign(this.status.navigationBarParams, {
titleImgItem: TitleSearch({ isCollapse: scale === 1 })
})
});
}
return navBarParams;
};
titleImgItem
特别注意titleImgItem，这个特点是导航条中心区域的展现内容，TitleSearch是百亿补助的搜索框，你能够参阅该元素自定义中心区域。
挂载
import { INavigationParams, NavigationBar } from "@pango/navigation-bar";
import "@pango/navigation-bar/lib/navigation-bar.scss";
css
.nav-bar {
width: 750px;
z-index: 1;
top: 0px;
}
<NavigationBar
className="nav-bar"
params={data.navParams}
barHeight={200} //自定义导航栏高度
event={do somethings}
/>
遇到了哪些问题
Q:若原生导航条躲藏，此刻反常怎么办？
反常分为以下3类：
反常场景1：事务js履行反常。
• @pango/navigation-bar组件运用a标签烘托回来按钮，确保js履行反常时仍然展现该标签，而且能正常相应出栈事情。
•事务展现兜底过错页时，会运用导航条兜底数据烘托导航条。
反常场景2：webview加载html失利。
为了消除上面说到的过渡问题，事务链接中新增了qurey参数hideNavi=1 ，原生webview会经过该字段在webview呈现之前躲藏导航条。但是因而也引发了一个风险：html加载失利时，会形成无头的问题。因而需求webview合作改造，一旦监测到html加载失利，原生webview要展现原生导航条。
反常场景3：通天塔服务反常。
同样是场景2中的问题，需求通天塔合作改造通天塔服务反常的场景：依据链接中hideNavi字段增加回来按钮或许通知webview展现默许导航条。
若发现其他反常，麻烦提醒我。
Q:折叠屏怎么适配？
折叠屏适配一直是前端适配的噩梦，噩梦的根本原因在于：宽度于高度的比例十分值，前端布局是往往会把px转换成vw，因而形成了异形屏适配难的问题。
•参阅原生体系导航栏的绝对布局方案：@pango/navigation-bar把导航条拆分为状态栏和导航栏上下两部分， 导航条宽度屏幕自适应，导航条高度跟随设备改变，并选用大写的PX单位来固定元素尺度。依据协议item宽高、间距仍可自定义，但是大写的PX确保了item不会随着屏幕宽度而反常改变。
navigation-bar {
width: 750px; // 会转换成vw
height: 44PX; // 不会转换成vw
display: flex;
position: absolute;
.left-items-bg {
margin-left: 16PX; // 不会转换成vw
height: 22PX;
margin-top: 11PX;
width: fit-content;
display: flex;
align-items: center;
justify-content: center;
}
}
Q:原生导航条优化？
现状中的几个反常场景，仍需求webview合作一同整改，所以现在整改方案为：
事务链接中新增qurey参数hideNavi=1，此刻 webview经过该字段在webview 呈现之前躲藏导航条。由webview担任整改，跟版12.1.4。
开源方案
经安全部分审阅之后，会向外开源。
迭代方案
•导航条在移动端页面中的重要性无需多言，咱们最终的意图是面向全集团，和通天塔以及hybrid团队，一同打造一根标准通用的H5导航栏，假如你在运用过程中发现一些咱们没有考虑到的反常场景或许规划标准，请与我联系，咱们一起完善。
•现在该组件下拉刷新仍是要依靠原生的下拉刷新事情，后期会定制H5自己的下拉刷新。
•一个标准的UI组件应该是一个有严格UI规划标准的，比方间距，字体大小、图片标准等。但是一期的规划中咱们为了灵敏，经过协议把UI把控留给了用户，也期望后面的迭代开发中融入更多标准的规划语言。
作者：京东零售 张松超
来历：京东云开发者社区 转载请注明来历
