山维空间

标签： react

  • React Native + Expo 入门级实战开发多平台应用 WhiteScreen：3. 深入开发，完成应用主体

    React Native + Expo 入门级实战开发多平台应用 WhiteScreen：3. 深入开发，完成应用主体

    感谢剪辑同学的努力工作，第三集上线。

    油管地址：https://youtu.be/0Ix-Y-MPQY0

    B站地址：https://www.bilibili.com/video/BV1CxnJzfEAk/

    继续分享 React Native+Expo 应用开发，帮大家补上全栈开发的最后一块拼图：移动应用开发。

    在这个系列视频里，我会用一个入门级小应用 WhiteScreen 作为范例，介绍如何使用 React Native+Expo 开发移动应用，并上传到应用商店。虽然国内市场基本被几个超级应用垄断，但是海外的广阔天地仍然大有可为。而 React Native 可以最大限度的利用我们已有的技术积累，让我们快速完成原型开发与需求验证，是全栈开发的不二之选。

    这期是第三次课，主要介绍：

    1. 使用 Zustand 管理状态，在页面间同步数据
    2. 使用原生组件进行布局
    3. 实现简单动画
    4. 实现本地数据存储于使用

    希望能给大家带来更多的可能性，在这个不那么容易的年代，让大家都有更多的选择余地与发展空间。

    希望大家留下宝贵的一键三连分享收藏，让更多的人能看到我的视频。

    有任何问题和建议，欢迎留言弹幕一起讨论。

    谢谢大家！

  • 近期 React Native + Expo 研发笔记

    近期 React Native + Expo 研发笔记

    整理一下近期开发 React Native App 的经验，以 tips 为主，写下来确保将来不会掉在同样的坑里。能够直接从官方文档查到的我就不写了，这里主要记录我踩到的坑。

    技术栈

    先说技术栈，我们目前的技术栈主要是：

    1. React Native v0.74.5，版本受 Expo 限制
    2. Expo v51.0.38
    3. NativeWind 用来写样式，蛮舒服的
    4. Supabase + expo-sqlite + AsyncStorage 用来做各种存储
    5. expo-apple-authentication + @react-native-google-signin/google-signin 用来 SSO
    6. expo-av 用来录音
    7. react-native-sse 用来流式传输

    选择 Expo 是因为 React Native 官方推荐，搭起来环境才发现没那么必要……不过配都配好了，就懒得重新搞了。实际用了之后，感觉还不错，大部分功能都更好用，尤其是各种组件比原始组件要好很多。所以推荐大家需要新组建时先看 Expo SDK：docs.expo.dev/versions/latest/sdk/ 大部分都比原生组件好。实在没有再去找其它 React Native 组件。

    Expo

    Expo 不是必须的，但还是蛮值得使用的。尤其是对 App router 这种基于文件系统的路由体系很熟悉的开发者来说，Expo 很值得。

    Expo 提供构建体系 eas，不过免费版每个月只能构建 15 次 iOS，不够用。所以大部分时间还是本地构建。构建之后，无法直接右键安装，但是可以通过 XCode Devices 安装。

    使用 Expo 需要注意环境变量和组件配置。因为对 .env 的修改、环境配置（app.json）、Logo、字体等的配置不一定会实时生效。所以修改这些不受 React Native 控制之后的东西，都先 prebuild + clean cache，然后再打包。或者直接在项目里手动搜索并修改也可以。

    手机上安装 Expo App 之后可以在 React Native 和 Expo 的网站上预览效果。其中 Android App 可以直接启动摄像头扫二维码；iOS app 没有启动摄像头的选项，我一直以为没法用，后来才发现，直接用照相机扫描二维码，就可以在 Expo 里打开了。

    NativeWind

    NativeWind 让我们可以在 React Native 里使用 TailwindCSS 和 className，非常舒服，非常推荐。

    不过 NativeWind 也有问题。有些组件的 className 不会直接应用在外层容器上，比如 expo-image。而如果不设置 width、height 的话，<Image> 就不会显示，这会导致我们无法正常使用这个组件。

    还有一些组件，它们由多个视觉组件组成，所以样式也需要分层配置，就有一些诸如 containerWrapperStyle 的属性。这样的组件也无法通过 className 来配置样式。所以我们使用的时候还是要多小心。如果组件渲染不符合预期，那么就看看组件如何应用样式。

    Expo Image

    Expo Image 比起 React Native Image 强很多：

    • 支持 WebP
    • 支持缓存
    • 支持 object-fit 和 object-position 填充
    • 支持一些我还没有用到的新特性

    非常推荐。但是不支持 NativeWind，请大家记得直接操作其 style 属性。

    FlashList

    <FlashList> 是 Shopify 开发的列表组件，针对大量内容高速滚动做了优化。它提供兼容 <FlatList> 的接口，可以无痛替换，推荐使用。

    使用的时候，需要注意滚动方向。比如 Twitter 这种最新的在上面，就是默认滚动；如果是聊天窗口这样最新的在下面，就要 inverted=true。同时还要注意，inverted=true 之后，Header Footer 的位置也要对调。

    Expo AV

    Expo AV 可以用来录音和播放音频。我们用它来实现 STT。将来会尝试原生 STT。

    需要注意的点不多，主要就是切换应用时，录音会自动停止，并且无法继续。所以我们需要侦听事件，并且做出相应的处理。

    渲染效率

    React Native 不支持非常高频的渲染，比如 Streaming output。在网页上没问题，在 RN 里就会报错：too many renderings。所以，我们需要适当缓存数据，减少渲染频率。我目前是 32 token 渲染一次。

    将来会尝试用 reanimate 之类的库来渲染文字，看看能否得到更好的效果。

    总结

    其实最近遇到的问题很多都跟 React 有关，不过考虑到 React 开发者恐怕不会认为这些“问题”是问题，所以还是写一些文档里找不到但是可能会踩到的坑吧。

    希望对大家有用，如果大家对 React，React Native，React Native Expo 开发感兴趣、有问题的话，欢迎留言讨论。

  • 小教程：React 创建支持切换效果的导航组件

    小教程：React 创建支持切换效果的导航组件

    需求

    需求不复杂，如上图所示：

    1. 导航栏，里面有若干个链接按钮
    2. 点击切换的时候，会有一个高亮标记随着选中的按钮移动
    3. 按钮尺寸不确定，高亮标记的尺寸随着选中的按钮变化

    选择技术方案

    我的第一想法是 CSS 纯原生，这样使用起来会非常简单。但是考察之后，发现不太可行，难点在于：

    1. 高亮标记如果跟着按钮走，无法处理按钮间切换
    2. 如果放在父容器里，可以在按钮间切换，但是尺寸没法跟着按钮走

    所以短暂思考之后，我只能退而求其次，选择和框架结合的开发方式：高亮标记使用绝对定位来控制位置；当用户切换导航（点击按钮）的时候，使用 JS 获取目标按钮的位置和尺寸，并且赋给高亮标记；使用 CSS 变量控制动画，以提升代码的复用性，确保 CSS 规则不要太死硬。

    这个过程并不复杂，我们可以利用事件冒泡机制，获取被点击的按钮，然后利用 getBoundingClientRect() 计算坐标。

    CSS

    CSS 部分比较简单，我们用一个伪元素作为高亮标记，然后配合 CSS 变量移动它即可。唯一需要注意的是，伪元素要跟按钮重合，所以必须用到 z-index，按钮也必须手动设置成 position: relative。

    （WP 代码高亮插件挂了，大家将就看……）

    .slide-navigator {
      --highlight-x: 0; /* 标记的 x 坐标 */
      --highlight-width: 0; /* 标记的宽度 */
      position: relative;

      &::before {
        content: '';
        position: absolute;
        z-index: 0;
        bottom: 0;
        left: var(--highlight-x);
        width: var(--highlight-width);
        background: #ffd850;
        transition: all 0.2s;
      }
      
      > * {
        position relative;
      }
    }

    这里暂时没考虑响应式，如果要切换横纵，可以增加一个 Y 坐标。如果需要定制样式，可以将高亮标记的样式抽出来单独处理。

    React JSX 组件

    作为组件，导航里面的按钮要跟着业务逻辑走，最好在业务组件里生成，然后通过 props.children 传进来。点击事件可以直接交由父容器，也就是本组件侦听，然后利用 event.target 来判断选中的是哪个按钮。

    这里还有一个抉择，即怎么确定高亮按钮是哪个。我考虑了一下，觉得将这个逻辑一并放在业务组件里比较好，然后通过 props.currentIndex 传进来使用。这样能确保本组件的复用性。坏处就是每个用到这个组件的地方都要写一个函数来判断，略嫌麻烦。

    最终组件代码如下：

    （WP 代码高亮插件挂了，大家将就看……）

    import {
      CSSProperties,
      FC,
      MouseEventHandler,
      useEffect,
      useRef,
      useState
    } from 'react';

    interface SlideHighlightProps {
      children: React.ReactNode;
      className: string;
      currentIndex: number;
    }

    type SlideNavigatorHighlight = CSSProperties & {
      '--highlight-x'?: string;
      '--highlight-width'?: string;
    };

    const SlideHighlight: FC<SlideHighlightProps> = function (props) {
      const { className, children, currentIndex } = props;
      const root = useRef<HTMLDivElement>(null);
      const [navStyle, setNavStyle] = useState<SlideNavigatorHighlight>();

      /* 处理按钮点击事件，找到被点击的按钮，并将其位置和宽度赋给高亮标记 */
      const onClick: MouseEventHandler<HTMLDivElement> = (event) => {
        if (!root.current) return;

        const target = Array.from(root.current.children).find((v) =>
          v.contains(event.target as Node)
        ) as HTMLElement;
        const { left } = root.current.getBoundingClientRect();
        const { left: l, width } = target.getBoundingClientRect();
        setNavStyle({
          '--highlight-x': `${l - left}px`,
          '--highlight-width': `${width}px`
        });
      };

      /* 组件初始化时，或者导航切换时，改变高亮标记的位置 */
      useEffect(() => {
        if (!root.current) return;

        /* 如果导航不应该高亮，就把标记隐藏起来 */
        if (currentIndex === -1) {
          setNavStyle({
            '--highlight-width': `0px`
          });
          return;
        }

        const { left } = root.current.getBoundingClientRect();
        const target = root.current.children[currentIndex] as HTMLElement;
        const { left: l, width } = target.getBoundingClientRect();
        setNavStyle({
          '--highlight-x': `${l - left}px`,
          '--highlight-width': `${width}px`
        });
      }, [currentIndex]);

      return (
        <div ref={root} className={'slide-navigator ' + className} style={navStyle} onClick={onClick}>
          {children}
        </div>
      );
    };

    export default SlideHighlight;

    总结

    我的 React 经验不太多，不考虑项目结构倒也问题不大，但是抽象组件的经验比较少，这次也是在 ChatGPT 帮助下才写好，所以赶紧趁热发一篇笔记。

    如果你对 React 经验比较丰富，发现我上面的代码有问题，欢迎指出。如果你对 React 开发有问题，对组件开发有疑问，也欢迎留言讨论。

  • Turbopack 发布后的各方反应：Vite/Webpack/围观群众

    Turbopack 发布后的各方反应：Vite/Webpack/围观群众

    上周整理了一下 Turbopack 发布后的各方反应，以便让自己和各位同学下一步做决策的时候能有所参考。接着忙碌的一周过去，我发现博客这周还没更，于是赶紧来补一下。

    0. TL;DR

    1. Turbopack 的宣传语更多还是“宣传”，实际效果提升并没有那么巨大。
    2. Turbopack 目前只支持 Next.js + React，且没有建立健全插件机制，所以没有生态可言，如果我们的主要开发环境不一致，可能暂时用不到。
    3. Turbopack 基于 Rust 开发，性能提升主要来自 SWC，所以有时间、有兴趣的话，直接使用 SWC 替换编译工具就好。
    4. 非目标开发者群体建议先不考虑迁移。
    5. Turbopack 对于打包过程有不小的改进，值得持续关注。
    6. 如果你日常使用 React，且想在新技术出现时斩获先机，早点动手也挺好。

    2022-10-26

    首先，10月26日，Vercel 发布了 Turbopack，自命 Webpack 继任者，号称速度比 Wepback 快 700 倍，比 Vite 快 10 倍。

    这些是官推亮点：

    • ~700x faster than Webpack -> 比 Webpack 快 700 倍
    • 10x faster than Vite -> 比 Vite 快 10 倍
    • Native incremental architecture built with Rust -> 基于 Rust，具备原生可增长架构
      ◆ Support for React Server Components -> 支持 React 服务器组件
      ◆ Support for TS, JSX, CSS & more -> 支持 TS、JSX、CSS，以及更多

    尤大观点

    很快，Vite 作者 @youyuxi 就跟进表达反驳：

    “10x faster than Vite” isn’t entirely accurate

    “‘比 Vite 快 10 倍’并不完全准确”，他说。

    然后他进一步介绍了自己的理由：

    1. Vite’s default React HMR is still babel-based, while Next/turbopack use swc/rust-based transform, so the HMR performance difference is a bit of apples to oranges.

    因为 Vite 默认的 HMR 仍然基于 Babel，而Next/Turbopack 使用的是基于 Rust 平台的 SWC，所以这里 HMR 的性能差异是关公战秦琼（这个 thread 后面还有若干理由，我就不一一翻译了）：

    Vite can switch to the swc/rust transform if necessary, we currently chose not to do that because adding swc to the deps list is extra weight, and even without it HMR is fast enough.

    Vite 当然可以在必要时切换到 swc/rust，但 Vite 开发团队并不想这样做，因为即使只用 Babel（不那样做），HMR 也足够快。使用 SWC 替换 Babel 只是平添开发负担。

    1. turbopack does address Vite’s request congestion issue on large apps. On Vite side we are also exploring how we can solve this via upcoming browser features like web bundles.
    1. Turbopack 确实解决了 Vite 在大型应用上的请求拥塞问题。我们 Vite 团队这边，也在探索如何解决这个问题，比如，是否可以借助即将推出的浏览器功能（Web Bundles）。

    In the long run we may also consider using turbopack under the hood to replace esbuild/Rollup (where suitable), due to its strong caching capabilities.

    1. 从长远来看，由于 Turbopack 强大的缓存能力，我们也会考虑在底层使用 Turbopack 来替换 esbuild/Rollup。如果合适的话。
    1. I’m glad vercel is investing its resources into a proper native-speed successor to webpack (as it should), and that our work on Vite has pushed this to happen. It’ll be interesting to see how it evolves – my hope is it can be made truly framework agnostic, not Next-first.
    1. 我很高兴 Vercel 愿意投入资源，打造 Webpack 的继任者，并着力提升它们的速度表现（应该如此），我们在 Vite 上的努力也达到了这样的目的。我对它们未来的演变很感兴趣——我希望它不要和框架捆绑在一起，不要 Next-first。

    Sean Larkin 观点

    （Sean Larkin 是 Webpack 的核心团队成员。目前好像在 LinkedIn 工作，好像。）

    Sean Larkin 也表达了自己的观点：

    Few thoughts: 几点想法：

    1. Love the innovation but it looks moderately SWC powers and wish there was some more callout there.
    2. Disappointed how entangled this is with next/turborepo. But Vercel needs to make.
    3. The path of migration from webpack for the avg user will be hard.
    4. I like that the dev server is still bundling modules because ESM slower than raw ESM. I need to peel back more layers to try and get a standalone implementation working.
    5. It’s all in alpha so we need to still look at the broader view but I hope we’re selling less going fwd
    1. 我喜欢创新。但看起来，Turbopack 更多是借力于 SWC，希望对方能表达得清楚一些。
    2. 我对 Turborepo 与 Next 的绑定程度感到失望。但是 Vercel 需要挣到更多的 （天使资金），没办法。
    3. 普通用户想 Webpack 迁移过去，会很艰难。
    4. 我倾向于开发服务器上的模块仍然是打包后的，因为 ESM 比原始 ESM 慢。我需要剥离更多层，才能让独立的实现工作。
    5. 目前它还处于 alpha 阶段，所以我们要看开一点，但我仍然希望，销售手腕少一些，好好干开发。

    2022-10-27 ～ 2022-10-28

    这段时间，@youyuxi 觉得 Turbopack 的数据有问题，因为 Vercel benchmark 的设计有问题，于是他尝试调整测试方式，给出了一些数据。不过后来他删除了这些推文，因为数字不太对。

    2022-10-27

    Vite 核心成员之一，@antfu7 在知乎上表达了自己的观点：

    他认为 Vite 更吸引人的是其插件系统，和构建在上面的生态系统。这样才能将改进快速带给其他领域。Turbopack 方面，静观其变吧。

    https://zhihu.com/question/562349205/answer/2733040669
    如何评价Vercel开源的使用Rust实现的Turbopack? – Anthony Fu的回答 – 知乎

    2022-10-29

    经过几天实验，Vite 作者 @youyuxi 发表了新的推文，新推文介绍了他进一步比较 Turbopack 和 Vite 之间性能之后，得到的新结论。

    I updated the vite vs next/turbo benchmark by using swc to transform React refresh for vite. To avoid confusion, I have deleted the previous two tweets with outdated numbers.

    Latest numbers:

    • root: vite 338.2ms / next 334.6ms
    • leaf: vite 141.8ms / next 84.4ms

    我通过搭配 Vite+SWC，重新评测 React 转换之后，更新 Vite vs Next/Turbopack 的基准测试。为避免混淆，我删除了前两条带有过时数字的推文。

    最新的对比数字：

    • 根：Vite 338.2ms / Next 334.6ms
    • 叶：Vite 141.8ms / Next 84.4ms

    The swc transform helps a lot in the root component case because the file is big, and previously cost 300ms in babel transforms alone. This makes vite almost exactly the same speed with turbopack.

    SWC 转换在根组件时候提供了很大帮助。因为文件很大，以前仅在 Babel 中转换就要花费 300 毫秒。替换之后，Vite 的速度几乎与 Turbopack 完全相同。

    Interestingly, in leaf scenarios turbopack is still 69% faster – this entails that Vite HMR actually caught up with turbopack as the file gets bigger, potentially scaling better in larger apps.

    有趣的是，在叶子场景中，Turbopack 的速度仍然更快，提升约有 69%。——这意味着随着文件变大，Vite HMR 实际上赶上了 Turbopack，在较大的应用程序中可能会有更好的扩展性。

    测试用仓库：https://github.com/yyx990803/vite-vs-next-turbo-hmr

    Because we are now testing the HMR of the same framework with the same set of transforms, the result is more relevant for other frameworks compared to previously posted numbers.

    现在，因为我们使用相同的转换集测试同一框架的 HMR，与之前发布的数字相比，结果的相关度更高。

    Just to add a bit of context – in this benchmark, even before using swc for React transforms, turbo is only 2x compared to vite (compared to marketed 10x). So the difference wasn’t that drastic to begin with.

    顺便讲点相关前提：这套基准测试，甚至在替换使用 SWC 转换 React 之前，与 Vite 相比，Turbo 也会仅 2 倍（他们市场宣称要快 10 倍）。所以其实一直以来，差异都没有那么大。

    2022-10-31 及之后

    本文主体整理于 10 月 31 日，之后 @youyuxi 还在孜孜不倦的跑 benchmark，与各路支持、反对、吃瓜者或讨论或争论。但是他的观点变化不大，所以我也就偷懒不继续翻译了，相信大家看完都能做出自己的判断。

    N 神有一些观点，摘录于此：

    vite 为了提升速度，利用了浏览器的特性，在 dev 阶段不打包而用 esbuild 预编译 esm 小包投送给浏览器， 在 build时候用 rollup 再打包。这样 dev 就会非常快(因为无需打包)，但写插件就很分裂，要考虑 dev 和 build 两种情况。并且理论上如果依赖小包过多会肯定会遇到浏览器并发瓶颈减慢速度。

    按 Turbopack 的说法，他 dev 和 build 同样走打包流程，还能比 vite 快，那么铁定是更好的。只是太早期了，现在还没有开放插件生态。而且自命 webpack 继任者没毛病，看 github 上就是 webpack 作者主力搞的。

    但另一方面如果未来 non-bundler 成为主流，前端不再需要打包。turbopack就没用了。vite 抛弃 rollup，build 也走 dev 流程就更美了。

    https://twitter.com/nshen121/status/1587333382362763264

    SWC 作者和 Webpack 作者

    这二位目前都在 Vercel 工作，可能受公司公关限制，都只转发了官推，并没有发表更多意见。

    总结

    Turbopack 可能不如官方所说的那么好。它的确带来了 HMR 的提升，但代价是不健全的插件机制和生态环境，以及难以被前端团队掌握的 Rust 平台。

    未来一段时间，我们还要继续坚持在 Vite 平台上。

  • 近期要学习实践的新技术

    近期要学习实践的新技术

    众所周知，程序员是一个必须随时更新知识技能的职业。这其中，前端程序员尤甚。虽然我自称全栈，多半也要依赖前端技术作为小无相功驱使内力，方能打出少林寺七十二绝技写出其它平台的产品。所以，主动学习，更新知识技能是我必须坚持的。

    同时，在前端这个充满变革的领域，我不能把各种新奇的东西都放到实际生产中去。所以，不定期的集中学习就不可避免。

    那么，近期要学习实践的新技术有哪些呢？

    1. Bootstrap 4
    2. gulp
    3. Angular 2 直接从2开始吧，计划做个Todo
    4. React + React Native 要不做鸡血君？
    5. Polymer
    6. Material Design Lite
    7. Phonegap 5 自然是迁移游戏泡泡
    8. Eletron 结合别的技术做个写博客的工具。
    9. socket.io
    10. browserify

    希望能在年底前搞定。

  • 未命名文章 1978

    React Native开始支持Android了，看来近期有必要去学学看了。做个什么好呢？