有了这个组件之后,小程序可以很好的嵌入一些页面,可以环境小程序 size 告急的问题,同样也使开发更加便捷,毕竟小程序开发者基本都对前端开发较为了解。
说再多还是需要去看官方文档, web-view文档 ,
首先就需要注意:兼容问题, 版本库和对应版本比例
目前而言,基本 80% 的用户会升级微信,所以其实不必担心版本问题,官方截止 2017-12-01 提供的数据也说明 88% 的用户支持 web-view 。
web-view 组件是一个可以用来承载网页的容器,会自动铺满整个小程序页面;
属性: src 是 String 类型,是一个网站的 url ,默认值是 none , webview 指向网页的链接。需登录小程序管理后台配置域名白名单。
可以配合 Page 实例的 onLoad 方法来获取 url 的具体值,也就是一个微信小程序页面中只有一个 web-view ,但是这个 web-view 的内容可以根据上一个页面传递的参数来获取页面 URL ,后面会讲如何实践,
官方提供如下接口:
1. 由小程序到 web-view ,其实本质上 WEB-VIEW 也是小程序的一个页面,所以小程序到 web-view 是正常的小程序间的通信,通过 wx.navigateTo 、 wx.redirectTo ,带上 url 参数, query 参数就像正常 url 的参数一样跟着后面,然后在 web-view 的页面的 Page 实例里面通过 onLoad 的方法的参数来获取 url 的值,设置给 web-view 的 src 属性为改值即可。
2. 由 web-view 到小程序,由于在 web-view 的跳转通常是在 src 对应的网页中的 *** 作来处理的,所以需要结合 jssdk 来处理,不需要 wx.config 配置,直接通过 script 标签来引入 [https://res.wx.qq.com/open/js/jweixin-1.3.0.js](http://link.zhihu.com/?target=https%3A//res.wx.qq.com/open/js/jweixin-1.3.0.js) ,就可以使用 wx.miniProgram.navigateTo 、 wx.miniProgram.navigateBack 、 wx.miniProgram.switchTab 、 wx.miniProgram.reLaunch 、 wx.miniProgram.redirectTo 接口,就像小程序之间的跳转一样,单是只能在当前小程序页面内跳转。
// web-view下的页面内 console.log(window.__wxjs_environment === 'miniprogram') // true
在目前实践了部分 web-view 的功能,
在这个 web-view 中,指向的就是 https://test.com 的内容,所以在在 https://test.com 中跳转出回到小程序,需要修改 https://test.com 中的 JavaScript ,
如果需要使用一些其他的的 jssdk 的方法,那就需要参照公众号的开发配置了。
由于很多使用中的一些问题
第一次写文章,希望有错能指正。
最近boss突然说要把一套web上的系统做成小程序。还好之前有过接触小程序,不过都是自己照着api和demo瞎写的,只能硬着头皮上了。
不出意外写了没多久就卡住了,原因是web页是利用cookie来保持登录信息,而小程序中并没有cookie这种东西。
一般的cookie都是浏览器生成放在Request Headers 中当做信息传给后端的,然后后端返回Set-Cookie给客户端浏览器设定之前拿到的cookie,使浏览器在cookie失效之前都拥有登陆者的信息。前端发送的cookie就像一张身份z,只要是携带了这个cookie的请求都会被认为是同一个请求源。
但是小程序中的登录请求并没有向后端发送cookie。
下图是正常浏览器端的登录请求
这是小程序中的
同一个接口cookie的差异就导致了小程序中无法使用cookie来保持登录信息。
不过好在登录请求不管前端是否发送cookie,后端都会有一个sessionId计算器(存在于使用cookie免登录的项目),请求的Response Headers中肯定会有一个Set-Cookie信息,通过response.header['Set-Cookie']拿到Set-Cookie的整条信息后,自然就可以得到其中的SESSION了。
然后通过自带的setStorage方法存储在本地,之后想要看登录之后的各种页面只要在请求的头中加入Cookie(和web端请求登录参数名一致)参数即可。
wx.setStorage({
key: "sessionId",
data: sessionId
})
wx.getStorage({
key: 'sessionId',
success: function (response) {
wx.request({
url: '请求url',
method: 'GET',
data: {
},
header: {
'content-type': 'application/json',
'Cookie': response.data
},
success: function (res) {
}
})
}
})
每个接口都要多传一个参数,麻烦是麻烦了一点,不过算是马马虎虎地解决了问题,之后应该还会遇到很多问题,只能边学边做了。
在这之前,如果有人问我,在微信中做一个产品,是用小程序还是 Web 页面 (严谨,既不是 HTML5 更不是 H5…) 的时候,我会这么说:
产品上,Web 上能做的,小程序中大部分都能做。小程序上能做的,Web 上不一定能做。
营销上,Web 能用到的入口,除了朋友圈以外,小程序都可以用。小程序能用到的若干入口,Web 不能使用。
关于后一点,朋友圈分享现在普遍会用海报来做,在这点上 Web 和小程序的能力其实是一样的,都是只能帮你保存图片到相册,再请用户手动发送到朋友圈。而小程序独有的发现 - 小程序、搜索框快捷方式等对用户回访特别重要的入口,Web 页面是不能使用的。
那么,昨天的发布意味着什么?简单地说,小程序的开发成本有了很大的下降。
微信小程序刚刚上线的时候,由于小程序使用类似 HTML、CSS 和 JavaScript 等 Web 语言的方式进行开发,让一些媒体误以为小程序就是 Web 开发,欢呼将「迎来 Web 开发的春天」。我自己的第一份工作就是 Web 开发工程师,Web 开发入门确实比较容易;可是尽管小程序使用了 Web 语言,那只是语法上的一致,整个开发模式完全不同,更接近于原生 App 的开发而不是 Web。打个比方,对在看这篇文章的大多数人来说,读中文要比读英文更容易,但假如你看不懂英文版的《量子力学导论》,翻译成中文版你也不一定能看懂。开发小程序,需要有专门的、独立于 Web 团队之外的团队,按小程序的规范重新设计、重新开发,不能将已有的产品直接迁移过来。
可以理解微信当初做这个决定,是希望开发者按照微信的要求,为微信的用户重新去思考、设计一套全新的用户体验,而不是将已有的 Web 页面搬进来。历史上,包括 Microsoft 的 Windows Phone 平台、Google 的 Chrome Packaged App 都冒过类似的险,而其实 Apple 也做过类似的决定——Steve Jobs 2010 年 4 月亲笔写过一篇文章,解释为何 iPhone 不支持 Flash (Thoughts on Flash),其中最重要的原因是,Apple 不希望第三方开发者将已有的产品直接搬过来,而是希望开发者能直接在 iOS (当年还叫 iPhone OS) 进行开发,为 iPhone 的用户提供最好的体验。这些决定赌的是,新平台 (小程序或 iOS) 带来的商业上的好处,最终会让开发者们愿意付出这个成本。
那时候的 iPhone 还很弱小,但后来的历史证明 Steve Jobs 赌对了——Adobe 公司今年 7 月宣布,将在 2020 年最终停止 Flash 的更新和分发。
微信,则在昨天支持了开发者直接嵌入已有网页。
所以,如果你已经有一个网站,可以直接在小程序中套个壳,把网站中的 Web 页面摇身一变成一个小程序。至于这和直接分发 Web 页面有什么区别——
产品上,Web 上能做的,小程序中大部分都能做。小程序上能做的,Web 上不一定能做。
营销上,Web 能用到的入口,除了朋友圈以外,小程序都可以用。小程序能用到的若干入口,Web 不能使用。
细心的你可能已经注意到了,上面这两条并没有任何变化… 对,在小程序的用法上其实没有任何变化,只是开发成本下降了。
那么,在今天之后,使用微信小程序框架开发的「原生」小程序,和嵌入已有的 Web 页面的「Web」小程序,在用户感受上会有什么区别呢?
「原生」小程序,整个小程序是提前下载的,不会有 Web 页面打开时的页面加载感。我们过去的可用性研究表明,这是用户对一个界面是「Web」还是「原生」的最主要判断标准。对于偏工具型的小程序,「原生」的感受应该会更好。
「原生」小程序对体验的控制更完整,自己要做的事情也更多。例如 Web 页面中用户可以选择页面上的文字复制,而在「原生」小程序界面中,这是需要单独添加的功能。
「原生」小程序提供了一些专属的控件和 APIs(接口),如展示群信息、发送推送等,这些只有使用小程序框架开发才能使用。
所以,如果需要和微信生态整合得更紧密,可以使用「原生」方式开发;如果追求快速迁移已有 Web 产品,嵌入 Web 页面更快。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)