如何增强单页应用的体验 about blog HOT 24 OPEN

断线重连跟应用重新打开的过程, 简聊做过尝试, app 关闭时把内存 store 完整状态存储下来, 然后网络连上的一刻, 其实就是一样的抓取全部依赖的数据然后更新界面, 就是一致的代码了, 感觉已经到比较好了.

热部署的问题感觉比较难, 不管怎样, 加载两份代码, 有些内存总是没法回收掉的, 参考开发过程热替换代码的样子, 很可能代码本身占用的内存不断增加. 我觉得如果只是想优化对于用户而言的体验, 也许模仿 App 更新倒是跟好办法, 比如说用户从当前页面离开, visibility 变成 hidden, 这个时候自动刷新页面, 然后打开同样的路由.

from blog.

谈谈个人的看法

路由规划

路由是 url => data，但我遇到的大多数场景中 url 与 data 之间往往难以直接进行匹配。

就体验效果来说，SPA 提升最大的应用场景大都是交易型网站（应用），其目标是给用户桌面型应用的体验。

桌面应用和网站的区别是什么，个人感觉较为重要的一点是：桌面应用是封闭型的，已经规定好用户的使用方式，仅暴露特定的操作路径；而网站是开放型，其运行依赖于浏览器，得充分考虑到用户使用浏览器时的随意性，比如 后退 按钮，一个事务型交易结束后或者退出后，用户点击浏览器的 后退，这时该如何处理？

所以在做路由规划时，需要考虑各种偶然性，这点可以从原生 APP 的视角来考虑，可以应用类似 storybook 的形式去思考。即：每一个分支走下去都有一个回环，最终落在路由栈的栈底。

SPA 的未来

单页面应用是现在的主流趋势，而且愈发火热。不仅在 PC 端，在移动开发领域，React Native、Weex、小程序何尝不是另一种形式的 SPA ？ 而且 Google 的 PWA 也着重强调了民工大大提到的几点问题：推送、本地缓存、热更新 ...

from blog.

这篇是近期做的分享，在讲的过程中，针对第二点：服务端推送，有过一些展开。

我最近大半年时间，没有像以前一样在视图层框架上花较多精力，而是着重于关注数据层解决方案。后面，会在这个层面分享一些东西

from blog.

这篇里面的每个点都可以展开很多话题，精力有限，无法一一述及。今年下半年的侧重点应该还是在数据层解决方案上。

from blog.

赞，前端和交互设计都需要了解的单页面体验

from blog.

使用本地缓存还有一个好处就是页面初始化的时候可以直接先拉本地数据渲染对DOM结构有要求的数据，然后异步请求后端同步数据，这样可以让首屏渲染的更快

from blog.

听大哥娓娓道来~

from blog.

坐等详细的讲解 👍

from blog.

好多都跟 stateless 和 immutable data 有关

from blog.

内存管理方面，感觉 backbone 要哭哈。backbone 没有提供组件的管理，很容易出现 zoombie view 。 而使用 vue ，angular ，react 这些，框架都做好了。所以感觉组件销毁这一块，需要手动处理的场景不多。

from blog.

好文，很多点值思考

from blog.

学习

from blog.

经验告诉我，单页应用要做好各种loading动画。
如果没有seo需求，可以用加载动画替代服务端渲染。
就目前来说，服务端渲染对服务器的性能开销很大。

from blog.

学习了

from blog.

关于热更新有什么实现方案吗？现在采用的方式是通过更新入口 HTML 的资源引用来进行应用版本更新的操作，意味着每次发版后，都需要用户手动刷新一下，更新 HTML 文件才能引用到新的资源。

from blog.

看了数值关联计算的文章之后，觉得 Rx 处理操作补偿的场景，应该也很方便。每个操作都描述成一个任务，或者事务并依赖 “父任务” 的操作补偿完成。 感觉像是 saga 的概念。

from blog.

@jiyinyiyong 再想的细一点。这个刷新的操作要考虑一下，如果还有任务在跑，需要等待优先级比刷新（更新）更高任务的完成。比如连续几步的操作补偿， 上传文件等任务还在执行的时候，需要等待这些完成之再执行更新。

from blog.

@Hanruis 确实. 不过这样的话就要求升级页面的代码要和各种逻辑耦合, 挺有风险的事情. 可能还是想想别的办法比较好.

from blog.

@jiyinyiyong 要是 Rx 支持这类型的场景的话，就容易了（因为飞叔他们在用 Rx）：声明一个任务，该任务依赖于当前 Rx 中正任务队列（仅当前，而不是特定的任务）的完成。

from blog.

@jiyinyiyong 热更新总感觉没有一个很合理的方案。
倒是从交互方面去考虑，这里的前提是做好路由方案以及存储方案等等，让用户已友好的方式去刷新页面。毕竟刷新页面的成本是十分十分低的。

from blog.

@Galen-Yip 是的. 在代码层面做 GC 很难控制好, 不如刷新来得明确. 而且刷新过程其实可以考虑把路由, 草稿, 等等的信息存储在 localStorage, 以便做到对用户而言尽可能使无痕的.

from blog.

要是有一个简单的demo把这些东西都实现了，并且加上注释该多好。。。

from blog.

Meteor 的 Optimistic UI 是增强 SPA 用户体验一个挺好的解决方案吧，特别是操作补偿，这个对用户体验的提升实在太关键了，不只是 SPA，原生应用也是这样，现在都是用各种 Loading 来缓解这个问题。

Optimistic UI with Meteor

Consistent ID generation and optimistic UI

When you insert documents into Minimongo from the client-side simulation of a Method, the _id field of each document is a random string. When the Method call is executed on the server, the IDs are generated again before being inserted into the database. If it were implemented naively, it could mean that the IDs generated on the server are different, which would cause undesirable flickering and re-renders in the UI when the Method simulation was rolled back and replaced with the server data. But this is not the case in Meteor!

Each Meteor Method invocation shares a random generator seed with the client that called the Method, so any IDs generated by the client and server Methods are guaranteed to be the same. This means you can safely use the IDs generated on the client to do things while the Method is being sent to the server, and be confident that the IDs will be the same when the Method finishes. One case where this is particularly useful is if you want to create a new document in the database, then immediately redirect to a URL that contains that new document’s ID.

from blog.

mark

from blog.