上午 Umi 周会的分享内容，做规划前可以看看社区发展，思考新技术与「你」的关联。
Umi 4 之后的新功能。
Remix 的加载策略
https://remix.run/blog/react-server-components
路由级请求有两种处理方式，「先渲染再请求瀑布流」和「先请求再渲染」，swr、react-query、use-request 属于前者，Remix 属于后者。后者最大的好处是 UX，不仅快，而且没有屏闪，此外还无缝支持 SSR。
「先请求再渲染」的原理是啥？以 Remix 为例。在路由组件中，定义 loader 函数用于请求数据，然后 useLoaderData hook 使用数据。由于 loader 定义在路由层，所以请求过来后匹配路由时就知道要发起哪些请求。
对于 Umi 来说，两种都需要，但推荐「先请求后渲染」。
Turborepo 的 Remote Caching
https://vercel.com/blog/vercel-acquires-turborepo
结合 OSS 等服务，Remote Caching 让本地缓存活起来，变单人模式为多人模式，对于性能提升是个很好的思路。提升的点包括团队协作、CI & CD。
对于 Umi 来说，目前想到有两点，1）MFSU 的缓存 2）monorepo 应用。
React 18
React 18 有不少新特性，包括 Suspense、Streaming SSR with Suspense、RSC（React Server Component）、Automatic batching、useId、startTransition、useTransition、useDeferredValue、useSyncExternalStore。值得思考的是，「这些点如何用于框架和业务开发？」
对于 Umi 来说，1）Umi 4 默认使用 React 18，2）对于 API 的使用需要趟一遍并给出最佳实践，比如如何使用 Suspense 做精细化 Loading 处理 3）我们的 useModel 数据流方案尝试用 useSyncExternalStore 简化实现
Sandpack
https://codesandbox.io/post/sandpack-announcement
In Browser Bundler、Browser FS，类似内网的 Gravity + Riddle 服务，能想到的点更多还是和 Demo 有关，但可以展开想下，比如能否直接上生产。
对于 Umi 来说，1）用于 dumi 的代码演示 2）尝试 umi PlayGround，在线跑 umi。
用户体验的困境与破局
GMTC 张鑫旭
作者的观点是「前端应该是体验技术负责」。然后体验的点非常多，可能有 1000+，这些点如果要开发者逐个去对照和优化，是件成本极高的事，结果可能是 UX 好了，但 DX 很糟糕 😰。所以，有没有两全其美的办法？
对于 Umi 来说，可以畅想下「体验工程化」。用工程化的方式去解体验问题，比如 autoprefixer 导致尺寸大的问题，browserslist 就是他的解。
Rails 7
https://rubyonrails.org/2021/12/15/Rails-7-fulfilling-a-vision
https://github.com/rails/importmap-rails
Rails 7 默认方案无 node 工具依赖，直接用 es-module-shims 上生产。
对于 Umi 来说，1）可以畅想下「bundler-none」，不走任何构建工具 2）对于内网中台应用来说，兼容不是问题，尝试用 esm + shims 直接上生产。
UnoCSS
https://antfu.me/posts/reimagine-atomic-css-zh
对于 Umi 来说，先不管原子化 CSS，至少我们可以有更好的 Icons 方案。基于编译时分析，让 @ant-design/icons 实现按需使用。
Astro
暂没想到结合点。