@kbapp/js-bridge 0.4.8-alpha.0 → 1.0.0-alpha.0

package/LOGIN.MD

@@ -0,0 +1,79 @@
+
+### 登录设计
+
+核心提供
+
+1. 静默登录方法, 如果用户未注册, 不引导注册
+2. 强制登录, 如果用户未注册, 引导注册
+
+页面打开的时候, 默认执行静默登录, 获取用户信息
+
+1. 某些点击事件需要登录才能执行, 提供 decorateTryLogin
+
+```js
+const onTapSomeButton = decorateTryLogin(() => {
+    // Todo someting
+})
+```
+
+该装饰器执行逻辑为如果未登录, 则执行登录操作(比如跳转到登录页面), 并直接抛出异常, 不做 _监听登录成功后执行回调函数_ 操作
+
+> 那岂不是用户登陆完成后回到当页面还需与再点一下
+
+没错, 的确要这么设计, 原因是为了解 如果点击了 2 个通过装饰器包装的按钮, 登陆成功后, 2 个按钮的回调事件将会全部执行(其实也有办法解决, 只是多点代码) 这种情况, 测试较真的话, 真是个问题
+担心一个动作触发累计多个回调事件, 导致逻辑混乱
+
+---
+
+A 页面 业务逻辑简单, 监听登录成功后, 自身处理重新触发登录请求
+B 页面 业务复杂, 需要登录成功后原地刷新
+C 页面 需要登录成功后才能看
+
+---
+
+1. uniapp 网页 适配 开吧 app 方案 (不采用中间件)
+
+A,B,C 均需要考虑停留一点时间后, 页面登录成功了
+
+A 页面 通过 onLoginReady 替代 onMounted
+
+```js
+onLoginReady(() => {
+    <!-- todo 业务代码 -->
+})
+```
+
+B 页面需要
+
+监听页面登录成功后执行刷新页面
+
+```js
+onLoginIfNotLoggedIn(() => {
+    <!-- 当页面登录后, 执行刷新页面 -->
+    window.reload()
+})
+```
+
+C 页面
+
+当页面没有登录的时候, redirectTo 登录页面, 登录页面有个按钮, 点击唤起开吧登录, 页面加载的时候也立刻唤起开吧登录, 登录成功后 redirectTo 回来
+
+---
+
+2. 纯小程序架构
+
+A,B,C 均需要考虑页面加载一段时间后, app 登录完成了或者登录失败, 页面主动点击触发登录
+
+A 页面
+监听登录成功执行操作
+
+B 页面
+监听登录成功后, 刷新页面
+
+C 页面
+页面打开的时候，如果未登录
+redirectTo 登录授权页面, 登录成功后 redirectTo 返回当前页面
+
+我建议 B 和 C 的分享链接改为 有个公共的前缀页面, 该页面静默登录或者强制登录成功后再进入 B/C, 这样子可以避免页面刷一下的体验
+
+执行登录是前往一个登录页面