return ( Update {error &&

{error}

当 `<form>` Action 成功时，React 会自动重置[非受控表单组件](https://zh-hans.react.dev/learn/sharing-state-between-components#controlled-and-uncontrolled-components)。如果你需要手动重置 `<form>` ，可以调用新的 `requestFormReset` React DOM API。

> 译者注：没找到 `requestFormReset` 这个 React DOM API，可能是指 [form.reset()](https://developer.mozilla.org/en-US/docs/Web/API/HTMLFormElement/reset)？

更多详细信息，请参阅 react-dom 文档中的 [\<form\>](https://zh-hans.react.dev/reference/react-dom/components/form)、[\<input\>](https://zh-hans.react.dev/reference/react-dom/components/input) 和 `<button>`。

### React DOM: 新 hook：useFormStatus

在系统设计时，我们通常会设计，使得组件能直接访问当前所处的 `<form>` 的信息，而无需使用 props 逐层传递。这可以通过 Context 来完成，但为了简化该常见情形，我们添加了一个新的 hook `useFormStatus`：

jsx import {useFormStatus} from 'react-dom';

function DesignButton() { const {pending} = useFormStatus(); return }

`useFormStatus` 能读取父级 `<form>` 的状态，就如同 `<form>` 是 Context provider 一样。

### 新 hook：useOptimistic

执行数据变更（mutation）时的另一种常见 UI 模式是，在异步请求正在进行时，乐观地展示最终状态。在 React 19 中，我们添加了一个名为 `useOptimistic` 的新 hook，以简化此操作：

jsx {2,6,13,19} function ChangeName({currentName, onUpdateName}) { const [optimisticName, setOptimisticName] = useOptimistic(currentName);

const submitAction = async formData => { const newName = formData.get("name"); setOptimisticName(newName); const updatedName = await updateName(newName); onUpdateName(updatedName); };

return (

Your name is: {optimisticName}

Change Name:

); }

当 `updateName` 请求正在进行时，`useOptimistic` 会立即展示 `optimisticName` 。当更新完成或出错时，React 会自动切换回 `currentName` 值。

更多详细信息，请参阅 [useOptimistic](https://zh-hans.react.dev/reference/react/useOptimistic) 的文档。

### 新 API：use

在 React 19 中，我们引入了一个新的 API 来读取渲染中的资源：use。

例如，你可以使用 use 读取 Promise，React 将暂停（Suspend）直到 Promise resolves：

jsx {1,5} import {use} from 'react';

function Comments({commentsPromise}) { // use will suspend until the promise resolves. const comments = use(commentsPromise); return comments.map(comment =>

{comment}

); }

function Page({commentsPromise}) { // When use suspends in Comments, // this Suspense boundary will be shown. return ( Loading…}> ) }

> 注意
>
> `use` 不支持在渲染中创建的 Promise。
> 如果你尝试将在渲染中创建的 Promise 传递给 `use`，React 将发出警告：
>
> ![React warning when pass a promise created in render to use](https://cdn.16px.cc/public/2024-05-05/yi-zJ07gDpFL.jpg?r=1664x164)
>
> 要修复此问题，你需要从支持缓存 promises 的 suspense 库或框架中传递 Promise。将来，我们计划发布一些功能，以便更轻松地在渲染中缓存 Promise。

你还可以使用 use 读取 context，还可以有条件地读取 context，例如在 `early returns` 之后：

jsx {1,11} import {use} from 'react'; import ThemeContext from './ThemeContext'

function Heading({children}) { if (children == null) { return null; }

// This would not work with useContext // because of the early return. const theme = use(ThemeContext); return (

{children}

); }

use API 只能在 render 中调用，类似于 hooks。然而与 hooks 不同的是，use 可以有条件地调用。未来我们计划支持更多的方式，在渲染时使用 use 消费资源（consume resources）。

更多详细信息，请参阅 [use](https://zh-hans.react.dev/reference/react/use) 的文档。

## React Server Components

### Server Components

服务端组件是一个新选项，允许在打包（bundling）之前，在与客户端应用程序或 SSR 服务器分开的环境中，提前渲染组件。这个单独的环境是 React Server Components 中的“服务器”。服务端组件可以在构建时在 CI 服务器上运行一次，也可以使用 Web 服务器针对每个请求都运行。

React 19 包含 Canary 版本中的所有服务端组件功能。这意味着，随服务端组件一起提供的库，现在可以将 React 19 作为对等依赖项（peer dependency），同时带上 react-server [条件导出](https://github.com/reactjs/rfcs/blob/main/text/0227-server-module-conventions.md#react-server-conditional-exports)，以便在支持 React 全栈架构的框架中使用。

> 注意
>
> **如何支持服务端组件？**
>
> 虽然 React 19 中的服务端组件是稳定的，并且不会在 major 版本之间破坏性更新（break），但用于实现服务端组件的打包工具或框架的底层 API 不遵循 semver（语义化版本控制规范），并且可能在 React 19.x minor 版本之间破坏性更新（break）。

从打包工具或框架的角度考虑服务端组件，我们建议固定到特定的 React 版本，或使用 Canary 版本。我们将继续与打包工具和框架合作，以使底层 API 更加稳定。

更多详细信息，请参阅 [React Server Components](https://zh-hans.react.dev/reference/rsc/server-components)。

### Server Actions

Server Actions 允许客户端组件调用在服务器上执行的异步函数。

当使用 `"use server"` 指令定义 `Server Actions` 时，你的框架会自动创建对服务端函数的引用，并将该引用传递给客户端组件。当客户端调用该函数时，React 将向服务器发送请求以执行该函数，并返回结果。

> 注意
>
> 没有针对服务端组件的指令。
>
> 一个常见的误解是，服务器组件用 `"use server"` 表示，但服务端组件没有指令。 `"use server"` 指令用于 `Server Actions`。
> 更多详细信息，请参阅 [Directives](https://zh-hans.react.dev/reference/rsc/directives)。

`Server Actions` 可以在服务端组件中创建，并作为属性传递给客户端组件，也可以在客户端组件中导入及使用。

更多详细信息，请参阅 [React Server Actions](https://zh-hans.react.dev/reference/rsc/server-actions)。

## React 19 的改进

### ref 作为 prop

从 React 19 开始，你可以在函数组件的 props 中直接访问 `ref`：

jsx function MyInput({placeholder, ref}) { return }

//…

新的函数组件不再需要 `forwardRef`，我们会发布一个代码修改器（codemod）来自动更新你的组件，以使用新的 `ref` 属性。在未来的版本中，我们会弃用并删除 `forwardRef`。

> 注意
>
> 传递给类组件的 `refs` 不会作为 props 传递，因为他们引用组件实例。

### 水合（hydration）错误的 diff

我们还改进了 `react-dom` 中水合错误的错误报告。例如，不要“在 DEV 中打印多个错误，却没有提示哪里不匹配”：

![previous React log](https://cdn.16px.cc/public/2024-05-05/pW9D0qJGO-yb.jpg?r=1790x600)

我们现在会打印一条带有不匹配的 diff 的消息：

![optimized React log](https://cdn.16px.cc/public/2024-05-05/qP65Wh6DDwSI.jpg?r=1790x812)

### \<Context\> 直接作为 provider

在 React 19 中，你可以将 `<Context>` 直接作为 provider，而非 `<Context.Provider>`：

jsx {5,7} const ThemeContext = createContext('');

function App({children}) { return ( {children} );
}

新的 Context provider 可以使用 `<Context>`，我们会发布一个代码修改器（codemod）来转换现有的 provider。在未来的版本中，我们将弃用 `<Context.Provider>`。

### refs 的清理函数

我们现在支持从 `ref` 回调返回清理函数：

jsx {7-9} { // ref created

// NEW: return a cleanup function to reset
// the ref when element is removed from DOM.
return () => {
  // ref cleanup
};

}} />

当组件卸载时，React 将调用从 `ref` 回调返回的清理函数。这适用于 DOM 引用、类组件的引用和 `useImperativeHandle`。

> 注意
>
> 以前，React 在卸载组件时，会使用 `null` 调用 `ref` 函数。如果你的 `ref` 返回清理函数，React 现在将跳过此步骤。
> 在未来的版本中，我们将在卸载组件时弃用“使用 `null` 调用 refs”。

由于引入了 `ref` 清理函数，现在从 `ref` 回调返回任何其他内容，TypeScript 都会跑错。解决方法通常是停止使用隐式返回，例如：

jsx

• (instance = current)} />
• {instance = current}} />

原始代码返回 `HTMLDivElement` 的实例，TypeScript 不知道这是不是一个清理函数，或者说你想不想返回清理函数。

针对这种情况，你可以使用 [no-implicit-ref-callback-return](https://github.com/eps1lon/types-react-codemod/#no-implicit-ref-callback-return)。

### useDeferredValue 初始值

我们在 `useDeferredValue` 中添加了 `initialValue` 选项：

jsx function Search({deferredValue}) { // 初始化渲染时，value 值为 '' // 之后会使用 deferredValue 进行重新渲染 const value = useDeferredValue(deferredValue, '');

return ( ); }

当提供了 `initialValue` 时， `useDeferredValue` 会将之用于组件的初始渲染，并使用 `deferredValue` 安排在后台重新渲染。

更多详细信息，请参阅 [useDeferredValue](https://zh-hans.react.dev/reference/react/useDeferredValue)。

### 支持 Document Metadata

在 HTML 中，document metadata tags（例如 `<title>` 、 `<link>` 和 `<meta>` 被保留放置在文档的 `<head>` 部分中。在 React 中，生成元数据的组件可能距离 `<head>` 的位置很远，或者 React 根本没有渲染 `<head>` 。之前，这些元素需要在 effect 中手动插入，或者通过 [react-helmet](https://github.com/nfl/react-helmet) 之类的库插入，而且在服务端渲染 React 应用程序时需要小心处理。

在 React 19 中，我们新增支持组件中原生渲染 document metadata tags：

jsx {5-8} function BlogPost({post}) { return (

{post.title}

Eee equals em-see-squared…

); }

当 React 渲染这个组件时，它会看到 `<title>` `<link>` 和 `<meta>` 标签，并自动将它们提升到文档的 `<head>` 部分。通过原生支持这些元数据标签，我们能够确保它们与 `client-only` 的应用程序、流式 SSR 和服务端组件配合使用。

> 注意
>
> 你可能仍然需要元数据库（Metadata library）
>
> 对于简单的用例，将 Document Metadata 呈现为标签可能是合适的，但是库可以提供更强大的功能，例如使用基于当前路由的特定元数据覆盖通用元数据。这些功能使 [react-helmet](https://github.com/nfl/react-helmet) 等框架和库更方便地支持元数据标签，而非替换它们。

更多详细信息，请参阅 [\<title\>](https://zh-hans.react.dev/reference/react-dom/components/title)、[\<link\>](https://zh-hans.react.dev/reference/react-dom/components/link) 和 [\<meta\>](https://zh-hans.react.dev/reference/react-dom/components/meta)。

### 支持 stylesheets

由于样式优先规则，外部链接（`<link rel="stylesheet" href="...">`） 和内联样式（`<style>...</style>`）都需要在 DOM 中仔细定位。构建允许组件内可组合性的样式表功能很困难，因此用户最终通常：要么在距离组件很远的地方加载所有样式，要么使用样式库（样式库把这些复杂问题封装好了）。

在 React 19 中，我们正在解决这种复杂性，并更深入集成到客户端并发渲染和服务端流式渲染，并内置对样式表的支持。如果你在 React 中声明你的样式表的优先级（`precedence`），它将管理 DOM 中样式表的插入顺序，并确保，如果有内容依赖外部样式，会在先加载外部样式，然后展示那些内容。

jsx {4,5,17} function ComponentOne() { return (

{…}

) }

function ComponentTwo() { return (

{…}

<-- 会插入到 foo 和 bar 之间

) }

在服务端端渲染期间，React 将在 `<head>` 中包含样式表，这确保浏览器在样式加载完成之后再绘制。如果样式表是在我们开始流式传输之后才发现的，React 将确保在显示依赖于该样式表的 Suspense boundary 的内容之前，将样式表插入到客户端上的 `<head>` 中。

在客户端渲染期间，React 将等待新渲染的样式表加载，然后再提交渲染。如果你从应用程序中的多个位置渲染此组件，React 将仅在文档中包含一次样式表：

jsx {5} function App() { return <> … // 不会在 DOM 中重复加载 stylesheet link }

对于习惯于手动加载样式表的用户来说，这是一个将这些样式表与依赖于它们的组件一起定位的机会，从而可以更好地进行本地推理，并更轻松地确保你只加载实际依赖的样式表。

样式库和与打包工具的样式集成也可以采用此新功能，因此即使你不直接渲染自己的样式表，你仍然可以受益，因为你的工具升级为使用此功能。

更多详细信息，请参阅 [\<link\>](https://zh-hans.react.dev/reference/react-dom/components/link)和[\<style\>](https://zh-hans.react.dev/reference/react-dom/components/style)。

### 支持异步脚本（async scripts）

在 HTML 中，普通脚本 ( `<script src="...">` ) 和延时脚本 ( `<script defer="" src="...">` ) 按文档顺序加载，这使得在组件树深处渲染这些类型的脚本具有挑战性。然而，异步脚本 ( `<script async="" src="...">` ) 将以任意顺序加载。

在 React 19 中，我们对异步脚本提供了更好的支持，允许您在组件树中的任何位置、实际依赖于脚本的组件内渲染它们，而无需管理脚本实例的重排序和去重。

jsx {4,15} function MyComponent() { return (

… ```

这些 API 可用于将字体等其他资源移动到样式表外加载，以此优化页面首次加载。还可以通过预取（prefetch）将要导航到的页面资源列表，然后在单击甚至悬停时立即预加载（eagerly preloading）这些资源，从而加快客户端加载速度。

与第三方脚本和扩展的兼容性

考虑到第三方脚本和浏览器扩展，我们改进了水合（hydration）。

水合时，如果客户端渲染的元素与服务器 HTML 中找到的元素不匹配，React 将强制客户端重新渲染以修复内容。以前，如果由第三方脚本或浏览器扩展插入元素，则会触发不匹配错误和客户端渲染。

在 React 19 中，<head> 和 <body> 中的意外标签将被跳过，避免不匹配错误。如果 React 由于不相关的水合不匹配而需要重新渲染整个文档，它会保留由第三方脚本和浏览器扩展插入的样式表。

更好的错误报告

我们改进了 React 19 中的错误处理，以去重并提供处理捕获和未捕获错误的选项。例如，当渲染中出现错误并被 Error Boundary 捕获时，以前的 React 会抛出错误两次（一次是针对原始错误，然后在无法自动恢复后再次抛出错误），然后带上错误发生的信息，调用 console.error。

对于每个捕获的错误，这会导致三个错误：

在 React 19 中，我们打印一个错误，其中包含所有错误信息：

此外，我们添加了两个新的根选项来补充 onRecoverableError：

• onCaughtError：当 React 在 Error Boundary 中捕获错误时调用。
• onUncaughtError：当抛出错误且未被 Error Boundary 捕获时调用。
• onRecoverableError：抛出错误时调用并自动恢复。

更多详细信息，请参阅 createRoot 和 hydrateRoot。

支持自定义元素

React 19 增加了对自定义元素的全面支持，并通过了 Custom Elements Everywhere 的所有测试。

在过去的版本中，在 React 中使用自定义元素一直很困难，因为 React 把无法识别的 props 视为 attributes 而非 properties。在 React 19 中，我们添加了对在客户端和 SSR 期间使用的 properties 的支持，策略如下：

• 服务端渲染：如果传递给自定义元素的 props 类型是 primitive value（如 string、number 或 true），则它们将呈现为 attributes。具有非基本类型（如 object、symbol、function 或 false 的 props 将被忽略。
• 客户端渲染：与自定义元素实例上的属性匹配的 props 将被分配为 properties，否则被分配为 attributes。

感谢 Joey Arhar 推动了 React 中自定义元素支持的设计和实现。

如何升级

请参阅 React 19 升级指南，查看分步说明以及破坏性更新和 notable changes 的完整列表。

]]>https://16px.cc/blog/5i-mc5r1msfLhttps://16px.cc/blog/5i-mc5r1msfLMon, 06 May 2024 13:19:23 GMT

好吧，其实牛逼的是谷歌。

给别人做个官网，对方还没有买服务器，就先放我自己的三级域名下测试，没有任何外链链进来。竟然直接被谷歌收录了。搜公司名字简称，我的排第一。。。favicon还用的我主站的呢，惊得我赶紧先换上对方的favicon再说。。。

]]>https://16px.cc/blog/IH_4qx-9JzWfhttps://16px.cc/blog/IH_4qx-9JzWfThu, 02 May 2024 01:03:46 GMT

可以在 这个页面 先行体验这个全景控制器，试着拖拖拽拽以及缩放玩玩吧。

缘起

我们知道，全景展示的原理是，一个球或者一个正方体，内部贴上全景贴图，然后把摄像头放在正中间，转着看，就是全景图像了。需要转动时就改变相机的朝向，需要缩放时就改变相机的 fov，不能改变相机的位置，全景的相机必须要处于球体或立方体的中心，否则会畸变。

相机以及全景的示意图，图源 researchgate.net Qingyang Shen，如有侵权请联系删除

three.js 虽然有很多控制器，如map control、orbit control、trackball control，包括 r3f 的一大堆 controls，但几乎都是控制移动相机的位置，放大是把相机朝物体移动，缩小则是远离。不能满足我的需求，怎么办？

自己写一个吧。

刚好我们之前把用户交互抽象成了一个包，拿过来用吧。

那个包的作用，是把鼠标或触摸交互时，产生的结果（move / scale / rotate）变成事件，并把事件对应的结果（移动的距离、缩放中心和倍率、旋转中心和角度）在包内计算、作为事件的参数一起抛出来，免于调用者计算

```tsx {13-18,21-32} import { MouseFormatter, type InteractEvents } from '@zimi/interact'

function PanoControl() { const element = useThree((state) => state.gl.domElement) const camera = useThree((state) => state.camera as PerspectiveCamera)

useEffect(() => { // 这里只用 MouseFormatter 示意 // TouchFormatter 同理 const formatter = new MouseFormatter() formatter.attach(element)

const onScale = (e: InteractEvents['scale'][0]) => {
  updateCamera(camera, {
    // 按交互所声明的缩放倍率执行缩放
    fov: camera.fov / e.ratio,
  })
}

// 交互包中的“移动”，即是控制器中的旋转
const onMove = (e: InteractEvents['move'][0]) => {
  const prevState = getStateFromCamera(camera)
  const ratio = camera.fov / canvasSize.height

  // 鼠标(或手指触摸)移动的距离换算成旋转的角度
  // 此处用 h/v 是利于人工可读性
  updateCamera(camera, {
    h: prevState.h + e.x * ratio,
    // v (纵向的角度) 需要限制在 (0, 180)
    v: clamp(prevState.v - e.y * ratio, EPS, 180 - EPS),
  })
}

formatter.addListener('scale', onScale)
formatter.addListener('move', onMove)

return () => {
  formatter.detach()
  formatter.removeListener('scale', onScale)
  formatter.removeListener('move', onMove)
}

}, [])

return <> }

### 工具函数

接下来我们再来实现 `getStateFromCamera` 和 `updateCamera` 函数

> h / v 的 get & set 参考了 [OrbitControls](https://github.com/mrdoob/three.js/blob/master/examples/jsm/controls/OrbitControls.js#L28) （我四五年前做 [pano-controls](https://github.com/xiaomingTang/pano-controls) 的时候，参考他实现了 get & set，但他的代码实现貌似变了，乍一看找不到之前参考的点了，懒得找了）

ts {4-15,35-60} /**

• 返回相机的 h / v / fov */ export function getStateFromCamera(camera: PerspectiveCamera) { const direction = new Vector3() const spherical = new Spherical()

  camera.getWorldDirection(direction) spherical.setFromVector3(direction) return { h: (spherical.theta / Math.PI) * 180, v: (spherical.phi / Math.PI) * 180, fov: camera.fov, } }

/**

• means "is valid number" *
• 局部使用的函数，名字短一点，我感觉整体可读性会更好 */ function vn(v?: number): v is number { return typeof v === 'number' && !Number.isNaN(v) }

interface CameraState { h?: number v?: number fov?: number }

/**

• 根据 h / v / fov 更新相机状态 */ export function updateCamera(camera: PerspectiveCamera, state: CameraState) { const { h, v, fov } = state if (!vn(fov) && !vn(h) && !vn(v)) { return } if (vn(fov)) { camera.fov = fov } if (vn(h) || vn(v)) { const direction = new Vector3() const target = new Vector3() const spherical = new Spherical()

  camera.getWorldDirection(direction) spherical.setFromVector3(direction) if (vn(h)) { spherical.theta = (h / 180) * Math.PI } if (vn(v)) { spherical.phi = (v / 180) * Math.PI } target.setFromSpherical(spherical).add(camera.position) camera.lookAt(target) } camera.updateProjectionMatrix() } ```

OK，一个控制相机 fov & 朝向的控制器就写好了

如果不嫌弃掺杂了业务代码，也可以看看具体实现代码：PanoControls/index.tsx

]]>https://16px.cc/blog/3vBCXWg_HwO5https://16px.cc/blog/3vBCXWg_HwO5Tue, 30 Apr 2024 16:45:21 GMT我记得 Next.js 在 server action 刚出来的时候，在客户端调用 server action，一旦抛错，是 catch 不住的，页面直接 500 了。然后我搞了一揽子工具函数，用于避免 server action 抛错。结果刚刚再试的时候，竟然可以 catch 住了，心态崩了呀。。。

]]>https://16px.cc/blog/jc7kPKuJehzkhttps://16px.cc/blog/jc7kPKuJehzkWed, 24 Apr 2024 04:42:20 GMT数据库地址设置成了 localhost，本地构建一点问题没有，但是用 docker 构建的时候，不停地报错：

Can't reach database server at `localhost`:`3306`

我以为数据库连接数超了，或者构建时并发太大超时了，又是设置 connect_timeout，又是设置 pool_timeout；还以为是在 mac aarch64 上构建 linux/amd64 的问题，也换了，翻来覆去就是报错，心态炸裂了。

结果在某个灵光乍现的时候，突然发现，诶，怎么是 localhost……

在 docker 里面，鬼能连上你 host 里的 localhost 啊……

]]>https://16px.cc/blog/prCD1rrttsjWhttps://16px.cc/blog/prCD1rrttsjWWed, 17 Apr 2024 18:41:41 GMT好几年前就（给家人）买了《艺术的故事》，一直放在家里，没机会、也沉不下心来读，最近终于能沉下心来看一点了，在这里记录一下吧。

---

不过，我们圈外人通常为之焦虑的美和表现的观念，艺术家却很少谈起……部分原因在于：艺术家往往腼腆怕羞，说“美”这类大话觉得不好意思。谈到“表现他们的感情”，以及类似的讲法，更会觉得装模作样。他们把这些看作理所当然，讨论起来也没有益处。

羞于谈论一些在外界看起来高大上的概念，因为觉得是“理所当然”的。好像有点共鸣哦。

原始……部落人……不要以为他们的作品看起来不顺眼就认为他们的手艺不过如此。他们的作品与我们的作品不同不是由于技艺，而是由于观念。从一开始就认识这一点十分重要，因为整个艺术发展史不是技术熟练程度的发展史，而是观念和要求的变化史。

工作生活中是否也是这样呢？他人在某些技能方面不足，或许只是观念和所处环境的缘故。（但是慎用这个来解释自己）

]]>https://16px.cc/blog/LGxTWHTD5eDlhttps://16px.cc/blog/LGxTWHTD5eDlWed, 27 Mar 2024 15:56:38 GMT刚刚在清理邮箱，打开我收到的第一个前端 offer，才发现，它的 title 竟然不是前端，而是个什么鬼“VR设计师”

]]>https://16px.cc/blog/rWJFIwyxlJ_Xhttps://16px.cc/blog/rWJFIwyxlJ_XThu, 21 Mar 2024 15:07:42 GMT有时候，有些事，做了也不一定有好的结果。

但我不希望在以后的时光里，回忆起这一段时间，抱怨自己，“我怎么就没有xxx”。

---

P.S. 裸辞失败，老大说让我先别辞，给我放两个月假去处理事情。。。

]]>https://16px.cc/blog/xR6DClIS7mqDhttps://16px.cc/blog/xR6DClIS7mqDThu, 21 Mar 2024 14:18:19 GMT

注意，我们整篇文章都在讨论跨域，相同域下的资源访问是没有这些问题的。

前端很多时候，会需要请求跨域的资源（接口或图片等）。

你是资源提供方

你希望限制访问

这时候，你就需要用到跨域资源共享（CORS）了，你可以通过在 Response header 上添加 Access-Control-* 系列字段，明确声明你的资源的访问策略。如：

• Access-Control-Allow-Origin 限制仅某些域才能访问
• Access-Control-Allow-Methods 只接受特定方法（Get、Post 等）的访问
• Access-Control-Allow-Credentials 请求要不要携带Credentials（Credentials 可以是 cookies、authorization headers 或 TLS client certificates）
• 等等

此外，我们知道 Cookie 在网络传输中扮演着很重要的角色，你希望在各种请求中控制 Cookie 是否发送。

此时，虽然 Access-Control-Allow-Credentials 可以控制跨域请求是否允许携带凭据，但它只能在 CORS 请求方面起作用。

如果一个恶意网站用 iframe 嵌套了你的网站，恶意网站有可能会误导用户执行特定的操作。此时用户的操作携带 Cookie 的话，将会很危险。

别担心，有 SameSite Cookie。

SameSite Cookie 属性是一种更广泛的机制，可以控制在所有类型的跨站点请求（包括页面导航、图片加载、iframe 加载等）中是否发送 Cookie。

建议看看阮一峰的 Cookie 的 SameSite 属性，介绍得很清楚。

Chrome 默认的 SameSite 是 Lax，是比较严格的，只有一些通常意义上不会造成资源修改的操作才允许携带 Cookie，最大限度地保障了用户的网络安全。

你希望允许访问

我们在业务中经常碰到的问题是，两个域都是我自己的，为什么这个跨站请求没有携带 Cookie 呢？

此时，我们服务端需要在 Response header set-Cookie 字段中，声明 SameSite=None

set-Cookie: xxx=xxx;Domain=.your-target.site;SameSite=None;Secure

这样，*.your-target.site 就能附带 Cookie 访问你的资源了。

你是访问者

通常，服务提供者是不会随便对所有域设置 SameSite=None 的，通常只会对特定的几个域（他自己持有的或信任的域）设置 SameSite=None。

假设 third-party.site 是一个很牛哔的站点，它提供了网络基础设施，你今天访问了 A/B/C/D/E 各种网站，都引用了 third-party.site 的资源。

如果浏览器允许随便携带 Cookie，那就糟了，third-party.site 就知道你的访问记录了。这就叫跨站跟踪。

所以，Chrome 默认 SameSite=Lax，很多请求都不允许携带 Cookie，尽可能保护用户的隐私。

当然，你说如果 third-party.site 设置所有域都 SameSite=None，那不就能跟踪了吗？确实，这样是能跟踪了，但是它自身也冒着其他的一些安全风险，就不赘述了。

业务上的常见问题

1. 我本地开发，SameSite 有问题啊

   本地开发的时候，我们可能需要在其他设备上访问本机起的服务，通常是访问 http://192.168.x.x，这时候就有问题了：

• SameSite=None 必须要 Secure 才能生效，可是 http://192.168.x.x 不是一个安全的域

• SameSite=Lax 又会导致一些跨域请求被阻止

  这时候可以再起一个 https 服务，代理到 http 的端口上，其他设备上就能访问 https，SameSite=None 就能生效了。

推荐一个方便地起 https 的命令行工具：local-ssl-proxy

2. 我不是允许跨域了吗？怎么请求还是被阻止了？

   注意看看 Request header 是不是添加了一些自定义的字段，如果有，需要在 Response header Access-Control-Expose-Headers 中添加该字段。

注意看 devtool -> Network 或 devtool -> Console tab 中的报错信息，一般报错信息会详细地告诉你请求为什么被阻止。

---

P.S. 前段时间写的 《为什么 Chrome 要禁止跨域》 被我不小心误删了，才发现数据库备份脚本权限有问题，一直没有执行。删除也是物理删除，没有做假删除，直接找不回来了。尬了，只能重新写了。。。

]]>https://16px.cc/blog/OlxyhzZbRyUIhttps://16px.cc/blog/OlxyhzZbRyUISat, 16 Mar 2024 08:11:35 GMT发现问题

打算搞一个百度收录, 百度需要我在根目录放一个 baidu_verify_xxx.html 的文件, 用于验证。

我一想, 这不太简单了, 直接把 .html 文件扔到 public 目录下不就好了?

扔进去, 测试一下, 404… 当时就猜, 应该被 nextjs 拦截了, 一看源码, 果然…

瞄瞄源码

以下仅截取关键代码

class NextNodeServer extends BaseServer {
  /**
   * https://github.com/vercel/next.js/blob/canary/packages/next/src/server/next-server.ts#L642
   */
  protected async findPageComponents() {
    /**
     * https://github.com/vercel/next.js/blob/canary/packages/next/src/server/next-server.ts#L710
     */
    const components = await loadComponents({
      distDir: this.distDir,
      page: pagePath,
      isAppPath,
    })
  }
}

而 loadComponents 中:

function loadComponents() {
  /**
   * https://github.com/vercel/next.js/blob/canary/packages/next/src/server/load-components.ts#L135
   */
  const ComponentMod = await Promise.resolve().then(() =>
    requirePage(page, distDir, isAppPath)
  )
}

requirePage:

/**
 * https://github.com/vercel/next.js/blob/canary/packages/next/src/server/require.ts#L108
 */
function requirePage() {
  const pagePath = getPagePath(page, distDir, undefined, isAppPath)
  if (pagePath.endsWith('.html')) {
    return promises.readFile(pagePath, 'utf8').catch((err) => {
      throw new MissingStaticPage(page, err.message)
    })
  }
}

getPagePath:

/**
 * https://github.com/vercel/next.js/blob/canary/packages/next/src/server/require.ts#L93
 */
export function getPagePath(
  page: string,
  distDir: string,
  locales: string[] | undefined,
  isAppPath: boolean
): string {
  const pagePath = getMaybePagePath(page, distDir, locales, isAppPath)

  if (!pagePath) {
    throw new PageNotFoundError(page)
  }

  return pagePath
}

getMaybePagePath (此处完整截取了该函数代码):

/**
 * https://github.com/vercel/next.js/blob/canary/packages/next/src/server/require.ts#L25
 * 
 * 太直白了, 没什么好注释解释的了, 就是:
 * 1. 从缓存里取, 如果没取到:
 * 2. 构建的时候会生成 .next/server/app-paths-manifest.json 和 .next/server/pages-manifest.json, 看看这两个文件里面有没有这个路径, 并拼上 .next/server
 */
export function getMaybePagePath(
  page: string,
  distDir: string,
  locales: string[] | undefined,
  isAppPath: boolean
): string | null {
  const cacheKey = `${page}:${distDir}:${locales}:${isAppPath}`

  let pagePath = pagePathCache?.get(cacheKey)

  // If we have a cached path, we can return it directly.
  if (pagePath) return pagePath

  const serverBuildPath = path.join(distDir, SERVER_DIRECTORY)
  let appPathsManifest: undefined | PagesManifest

  if (isAppPath) {
    appPathsManifest = loadManifest(
      path.join(serverBuildPath, APP_PATHS_MANIFEST),
      !isDev
    ) as PagesManifest
  }
  const pagesManifest = loadManifest(
    path.join(serverBuildPath, PAGES_MANIFEST),
    !isDev
  ) as PagesManifest

  try {
    page = denormalizePagePath(normalizePagePath(page))
  } catch (err) {
    console.error(err)
    throw new PageNotFoundError(page)
  }

  const checkManifest = (manifest: PagesManifest) => {
    let curPath = manifest[page]

    if (!manifest[curPath] && locales) {
      const manifestNoLocales: typeof pagesManifest = {}

      for (const key of Object.keys(manifest)) {
        manifestNoLocales[normalizeLocalePath(key, locales).pathname] =
          pagesManifest[key]
      }
      curPath = manifestNoLocales[page]
    }
    return curPath
  }

  if (appPathsManifest) {
    pagePath = checkManifest(appPathsManifest)
  }

  if (!pagePath) {
    pagePath = checkManifest(pagesManifest)
  }

  if (!pagePath) {
    pagePathCache?.set(cacheKey, null)
    return null
  }

  pagePath = path.join(serverBuildPath, pagePath)

  pagePathCache?.set(cacheKey, pagePath)
  return pagePath
}

稍加分析

nextjs 对于 .html 后缀的访问, 直接去生成的 app 和 pages 目录里面找, 找不到就直接返回 404 了, 根本不管你 public 目录里面有没有

解决方案

虽然可以从源码中添加一个 baidu_verify_xxx 文件, 但我感觉这样挺烦的, 干脆, 我们原来的在 nginx 中的做法不是把所有的东西都扔给 nextjs 处理嘛, 现在不了, nginx 先去 public 目录里面找一找, 有就直接返回, 没有再交给 nextjs。

server {
+  try_files    /public$uri @nextjs;

-  location / {
+  location @nextjs {
    proxy_pass    http://nextjs_upstream;
  }
  # ...
}

---

p.s. 其实, 像这种情况, nginx 直接返回文本省事多了🙃 但我要是不用 try_files, 前面的源码不是白分析了吗 [狗头] 这样一搞, 什么 html 静态文件都能用了 [正色]

~~再 p.s. 其实, 不适合一股脑 try_files, 因为如果是图片, 交给 nextjs 处理, next/image 会做优化, 直接由 nginx 丢出去, 优化就无效了~~

题外话

配置好后, 页面仍然报 404, 哪里出了问题呢?

1. 看看 nginx 是谁执行的

• 执行 ps aux | grep '[n]ginx'
• 哦, 原来是 www-data 用户

1. 看看 www-data 用户能不能访问到相应的文件

• 执行 sudo -u www-data stat /path-to-target-file
• 也可以执行 sudo -u www-data namei /path-to-target-file, 这个命令能更清楚地看到是在哪一目录才 denied 的
• md permission denied

哦哦, 查一下, 发现 nginx 需要 x 权限, 而我的项目放在 /home/xxx 目录下, 权限是 750…

教训就是, 项目别放到 /home 目录下!

warning

chatgpt 说:

对于普通的Web服务器，try_files 的影响通常是可以忽略不计的。但是，在高性能要求的环境中，需要谨慎使用，并进行性能测试以确保不会成为性能瓶颈。如果性能成为问题，可能需要考虑其他优化策略，如缓存、负载均衡等。

]]>https://16px.cc/blog/bUTsjruylOsOhttps://16px.cc/blog/bUTsjruylOsOSun, 17 Mar 2024 16:27:07 GMT说在前面

本文所有前缀以 CUSTOM_ 的字段, 都表示你需要改为你自己的值,
如 CUSTOM_YOUR_PASSWORD, 表示你需要替换为你自己的密码;

本文所有前缀以 mysql> 的命令, 都表示该条命令处于 mysql 环境, 输命令时是不需要输入 mysql> 的

安装及启动

sudo apt install mysql-server

sudo systemctl start mysql

[可选] 配置 root 用户密码

最开始 root 用户是没有密码的, 我们给它配置一个密码, 当然不配置密码也无所谓, 密码强弱也无所谓, 因为 root 的 host 是 localhost, 外网访问不了

sudo mysql

mysql> ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'CUSTOM_YOUR_PASSWORD';
mysql> exit;

[可选] 配置公网可访问

如果你不需要公网访问, 可以忽略该段

添加/编辑 bind-address, 以使公网可访问;

sudo vim /etc/mysql/mysql.conf.d/mysqld.cnf

# 在文件 "/etc/mysql/mysql.conf.d/mysqld.cnf" 中, 添加/编辑 bind-address, 设置为 0.0.0.0
bind-address = 0.0.0.0

创建数据库

sudo mysql -u root -p

mysql> CREATE DATABASE CUSTOM_YOUR_DATABASE;

创建用户, [可选] 配置外网访问权限

@'%' 表示 host 为 %, 即任意地址可访问 (如需配置特定地址/禁止外网访问, 可另查资料)

仅内网可访问是 @'localhost'

只有 host 为 % 的用户, 才能外网访问;

# 这个密码必须很强, 因为这个用户是外网访问的 (如果你仅内网可访问, 那就无所谓了)
mysql> CREATE USER 'CUSTOM_USER'@'%' IDENTIFIED BY 'CUSTOM_YOUR_PASSWORD';
mysql> GRANT ALL PRIVILEGES ON CUSTOM_YOUR_DATABASE.* TO 'CUSTOM_USER'@'%';
mysql> FLUSH PRIVILEGES;
mysql> exit;

# 重启 mysql
sudo systemctl restart mysql

常见问题与排查

如果外网访问不了, 你可以检查:

• 域名/用户名/密码/数据库名 是否正确
• 用户 host 是否为 %
• 检查用户 host 的命令是 mysql> select user, host from mysql.user;
• 腾讯云/阿里云 防火墙端口是否开放
• 用户等杂七杂八的东西配置完后, 是否忘了重启 mysql

外网客户端可以连上, prisma 死活连不上

执行 npx prisma db push 报错:

Error: P1001: Can't reach database server at `xxx.xxx.xx.xx`:`3306`

可以先执行 npx prisma db seed (嗯嗯, 也会报错), 然后再执行 npx prisma db push, 就 OK 了

设置密码抛错

有时候不小心将密码强度设置有误, 修改密码的时候抛错:

ERROR 1819 (HY000): Your password does not satisfy the current policy requirements

可以修改密码策略:

# 列出当前密码校验的策略
mysql> SHOW VARIABLES LIKE 'validate_password%';

+-------------------------------------------------+--------+
| Variable_name                                   | Value  |
+-------------------------------------------------+--------+
| validate_password.changed_characters_percentage | 0      |
| validate_password.check_user_name               | ON     |
| validate_password.dictionary_file               |        |
| validate_password.length                        | 8      |
| validate_password.mixed_case_count              | 1      |
| validate_password.number_count                  | 1      |
| validate_password.policy                        | MEDIUM |
| validate_password.special_char_count            | 1      |
+-------------------------------------------------+--------+

# 然后就可以调整密码策略了, 例如不要特殊字符:
mysql> SET GLOBAL validate_password.special_char_count = 0;

]]>https://16px.cc/blog/w9Sg9JLGnyf2https://16px.cc/blog/w9Sg9JLGnyf2Sat, 27 Jan 2024 17:37:17 GMT问题

当我们有一个类型Color，其能接受如#123456这样普通的string，你又希望编辑器能提示你诸如red、blue这样特定的string literal时：

// 不合理
type Color = 'red' | 'blue' | string

上述写法不合理，Color类型会被编译器缩减为string，失去智能提示。

解决方案

下面的写法，编辑器能正确地提示我们 red 或 blue，也能接受普通的字符串如#123456

// https://azukiazusa.dev/blog/shorts/4Tq3csJ5BwAXPR4OBuJvIo/
// 能达到目的
type Color = 'red' | 'blue' | (string & {})

存在的不足及优化

但上面的写法仍然存在不足[^1]：这样的Color能接受任何字符串，即使笔误写成bluu或者invalid-color，编辑器/编译器也不能给我们任何提示。

[^1]: Type-safe alternatives: https://stackoverflow.com/a/73753173

因此，在一些条件允许的情况下，我们可以写出更严格的类型：

// 当然，如果你认为不必要这么严格，或者还不够严格
// 可以按自己需求/喜好来调整，此处只作示例
type Color = 'red' | 'blue' | `#${string}` | `rgb(${string})`

效果展示

]]>https://16px.cc/blog/cUrQcu5f4fDchttps://16px.cc/blog/cUrQcu5f4fDcThu, 18 Jan 2024 16:55:30 GMT前言

业务中存在一个逻辑：

如果接口响应 401，就清空前端用户信息

貌似是一个很合理的逻辑，401 肯定是登录态有问题，当然需要清空登录态。

碰到问题

线上偶现部分页面业务逻辑异常，顺着业务梳理排查：

其他地方传过来 token，前端凭 token 调登录接口，拿到了登录态，存起来了，可突然转个身，登录态没了。。。

排查

检查代码逻辑没问题，检查现场请求发现，登录请求前面紧挨着有几个 401，请求时间比较长。

原来是：

• 页面顺序发了几个请求： api: x + api: login；
• api: login 后发，但提前响应回来了，前端保存了登录态；
• api: x 先发，发的时候没有登录态，但之后才响应 401，触发了 401 的逻辑，清空了刚刚保存的登录态。。。

修复

最合理的解决方案是：记录请求的发送时间，记录最后一次登录成功的时间，在触发 401 清空登录态时，判断请求发送时间是否早于登陆成功的时间，如果是，就忽略（不执行清空登录态）。但由于有历史包袱，改动过大，没法搞。

裱糊匠有办法：记录最后一次登录成功的时间 T，忽略 T + 1s 时间内的 401 清空登录态的调用。

什么，你说万一前面的请求超过 1s 了呢？2s 够不够？3s 够不够？

不够？那就只能牺牲我的头发，用上面那个难搞的方案咯。（你说 10s？你是真不让别人退出了呗。。。）

]]>https://16px.cc/blog/v9ZXgueczXLNhttps://16px.cc/blog/v9ZXgueczXLNThu, 18 Jan 2024 17:44:52 GMT问题

我们在使用 zustand 的时候，总会遇到需要自定义函数：

// 定义
const useCounter = create((set) => ({
  count: 0,
  inc: () => {
    set((prev) => ({
      count: prev.count + 1,
    }))
  },
}))

// 使用
function App() {
  const { count, inc } = useCounter()

  return <button
    onClick={inc}
  >
    {count}
  </button>
}

这样有几个问题：

1. 函数污染了 store，我们在使用 useCounter 的时候，inc 函数总是在提示列表里面碍眼；
2. 当我们需要在 hook 里面使用函数时，平白增加了依赖

   function App() {
     const { count, inc } = useCounter()

     useEffect(() => {
       console.log(count)
       inc()
       // inc 是一个静态函数，按理来说是可以不用放在依赖里面的
     }, [count, inc])
   }

3. 没有类型限制，无法阻止别人无意间修改 inc 函数：

   // 在一些场合下，我们希望使用 replaceFlag，这时候就出问题了，把 inc 函数丢了
   // replace flag: https://docs.pmnd.rs/zustand/guides/immutable-state-and-merging#replace-flag
   const replaceFlag = true
   useCounter.setState({
     count: 3,
   }, replaceFlag)

这个怎么样？

如果能这样呢：

function App() {
  const { count } = useCounter()

  return <button
    // 将 inc 变成 useCounter 的静态函数
    onClick={useCounter.inc}
  >
    {count}
  </button>
}

直接上代码

/* eslint-disable @typescript-eslint/no-explicit-any */
import type { StoreApi, UseBoundStore } from 'zustand'

interface StaticFuncs {
  [key: string]: (...args: any[]) => any
}

type WithStatic<
  T extends UseBoundStore<StoreApi<any>>,
  S extends StaticFuncs
> = T & S

export function withStatic<T, S extends StaticFuncs>(
  useStore: UseBoundStore<StoreApi<T>>,
  staticFuncs: S
) {
  const protectedKeys = Object.keys(useStore)
  const result = useStore as WithStatic<UseBoundStore<StoreApi<T>>, S>
  Object.keys(staticFuncs).forEach((key) => {
    if (protectedKeys.includes(key)) {
      if (isDev) {
        throw new Error(`protected key: ${key}`)
      } else {
        console.error(`protected key: ${key}`)
      }
      return
    }
    result[key as 'setState'] = staticFuncs[key]
  })
  return result
}

Usage

const useRawCounter = create(() => ({
  count: 0,
}))

export const useCount = withStatic(useRawCounter, {
  inc: () => {
    useRawCounter.setState((prev) => ({
      count: prev.count + 1,
    }))
  },
})

// 调用
function App() {
  const { count } = useCounter()

  return <button
    onClick={useCounter.inc}
  >
    {count}
  </button>
}

]]>https://16px.cc/blog/ZAk6vW7UmNIFhttps://16px.cc/blog/ZAk6vW7UmNIFFri, 12 Jan 2024 01:30:12 GMT今天不谈 SEO，我们梳理前端的发展历程，来看看我们为什么需要 react server component。

以下代码基本是伪代码

刀耕火种：html + js 一把梭

<html>
  <body>
    <header>xxx</header>
    <main>xxx</main>
    <footer>
      <div id="time">loading...</div>
    </footer>
    <script src="index.js" />
  </body>
</html>

// index.js
const timeElem = document.querySelector("#time")
const now = new Date().toLocaleString()
timeElem.innerText = now

html + js + css三剑客的时候，我们通常会把 js 放到 html 最底部，防止阻碍页面的加载。

这时候，运行很快，但不便于前端组织代码。

鸟枪换炮：单页面一把梭

<html>
  <body>
    <div id="app" />
    <!-- 构建时会将 js 注入到这里 -->
  </body>
</html>

单页面的时候，所有的页面内容和逻辑都在 js 里，html 只包含一个 js 入口和一个根元素（div#app），js 加载完成后运行，渲染出所有内容，插入到根元素（div#app）中。

这时候，路由一般由前端来控制，组织代码是方便了，但是由于所有内容都在 js 中，用户加载完一个 html 完全白屏，什么也看不到，必须要等到 js（size 通常 1M+）加载完成并执行后，才能看到内容，用户体验很糟糕。

再快一点：服务端渲染

tsx 源码（示意）

function Time() {
  const now = new Date().toLocaleString()
  return <div id="time" onClick={xxx}>
    {now}
  </div>
}

function App() {
  return <>
    <header>xxx</header>
    <main>xxx</main>
    <footer>
      <Time />
    </footer>
  </>
}

构建后的代码（示意）

• index.html

  <html>
    <body>
      <header>xxx</header>
      <main>xxx</main>
      <footer>
        <!-- js 执行后将会替换掉下面这个 div -->
        <div data-id="time" />
      </footer>
      <script src="index.js" />
    </body>
  </html>
  

• index.js js const timeElem = document.querySelector("[data-id='time']") const now = new Date().toLocaleString() timeElem.innerText = now // 为元素绑定事件，即 hydrate 水合 timeElem.onclick = xxx

服务端渲染和单页面类似，但是考虑到 js 中有一些逻辑并不依赖客户端（浏览器），所以可以先在服务端执行，渲染出尽可能多的内容，直接写到 html 中，再发送给客户端。

客户端接收到的内容不再是空的 html 了，而是包含部分 DOM 结构，用户能立即看到东西，只是不能交互，等到客户端加载完 js，完成水合过程，就能执行相应交互了。

精益求精：server action

诚然，服务端渲染能让我们立即看到东西，但是需要等到 js 加载完了才能交互。有没有办法在 js 没加载的时候就能交互呢？server action 可以。

function App() {
  const serverAction = async (formData: FormData) => {
    "use server"
    const name = formData.get("name")
    // do something
  }

  return <form action={serverAction}>
    <input name="name" />
    <button type="submit">提交</button>
  </form>
}

react 会将 serverAction 代码放在服务端执行，即使尚未加载 js，或用户禁用了 js，浏览器也原生支持表单提交，具体可查看 react 文档 server-actions-and-mutations

More

我们平时写代码的时候，可以：

• 适当多地让代码在服务端执行（少用 "use client"）
• 适当多地拆分粒度，客户端组件尽量出现在 DOM 树的叶子部分
• 这样可以降低需要向客户端传输的 js 的尺寸
• 尽可能使用浏览器原生支持的功能
• 使用 <a> 标签而非 onClick + route
• 使用 form + action 而非 onClick

]]>https://16px.cc/blog/AO0XPQwqZb0Uhttps://16px.cc/blog/AO0XPQwqZb0UTue, 25 Jun 2024 04:06:44 GMT今天逛 V 站发现一个 nginx 中 location 优先级的问题，有位用户 Hopetree 总结得挺好，图也很易懂，特此记录

作者个人博文展开讲了这个问题: 🚀终于理解了Nginx配置中location规则的优先级问题

p.s. 记录一个 nginx 配置在线匹配网站: https://nginx.viraptor.info/

]]>https://16px.cc/blog/S1PucL-ErJFJhttps://16px.cc/blog/S1PucL-ErJFJFri, 29 Dec 2023 06:40:34 GMT表盘来自 https://free-dxf.com/public/vectors-doors/free-download?search=clock

• 《如果我是___，你会爱我吗》

• 《爱你》，但是骂你

]]>https://16px.cc/blog/Xo1SmCzkTxsbhttps://16px.cc/blog/Xo1SmCzkTxsbSat, 02 Dec 2023 05:51:55 GMT全剧最令我感动的是，下面这个片段，时隔七十多年后，麻美和真里向小夏和小美发出邀请，一起喝茶聊天

麻美的表情满溢着惊喜、不敢置信、兴奋，让人动容。

---

上个月看的，看完就把观后感起了个头，本来想着构思构思多写点的，结果转个身忘了，今天后台翻列表才发现这篇未发表，可惜现在已经写不出什么了，只是强烈推荐没看过的可以看看，再次感叹日本人真是擅长拍友情、拍人生，之前的《小偷家族》也是，不像国内，拍什么东西都要往里面塞烂大街的爱情。

]]>https://16px.cc/blog/W4rl8iCkoFyLhttps://16px.cc/blog/W4rl8iCkoFyLFri, 15 Dec 2023 21:07:03 GMT介绍一个学习 CSS 的网站, https://www.cssportal.com/, 站内涵盖了众多 CSS 现成、可配置的实践案例, 整个网站有一些广告, 但是不太影响使用。

推荐示例

1. 各种贝塞尔曲线动画效果演示

你还可以一键查看不同曲线的效果动画

2. clip path 实现代码及效果

3. 各种精美的 loading 图

下图可以看到只有一个 dom 元素, 很简洁, 也便于我们定制化

目录

]]>https://16px.cc/blog/SWnQrBVd8y7yhttps://16px.cc/blog/SWnQrBVd8y7yWed, 08 Nov 2023 14:11:07 GMT今天看到知乎上一条提问: 如何看待「成都恶犬撕咬女童」事件家属发起200万募捐?, 里面有一条评论是:

没问题啊，我看孩子可怜捐点钱怎么了？你觉得不行你不捐不就行了。至于孩子家里有钱没钱什么的关我捐钱的什么事？

那么, 看待募捐, 能简单地说 我看孩子可怜捐点钱怎么了？你觉得不行你不捐不就行了 吗? 我认为不行。

注意, 本文并不表示我赞同或者不赞同此次募捐, 本文并不是针对此次募捐的评论, 而是对 "募捐" 这一行为/概念的讨论。

募捐, 对于整个社会来说, 并不仅仅事关 "发起募捐者" 和 "愿意捐款者" 两者, 同时, 还会消耗整个社会的 "同情心" 和 "注意力"。

一方面, 募捐的泛滥, 会导致热心人士以及普通人(中立者)注意力的分散, 会导致真正迫切需要帮助的信息被淹没, 从而更难从社会得到妥善的帮助;

另一方面, 每一次不合理的募捐, 都是对社会热心人士泼的一盆凉水, 是对同情心的消费。

因此, 对于不必要(不合理)的募捐行为, 我们应该理直气壮地抵制。

---

顺便, chatgpt 牛啊, 我把这篇文章发给他帮我润色, 下图左边是我原文, 右边是经过润色后的, 可以发现确实通顺了不少。(但是我就是不改, 诶, 就是玩儿)

]]>https://16px.cc/blog/MpgeqGBS893zhttps://16px.cc/blog/MpgeqGBS893zThu, 19 Oct 2023 03:12:40 GMT对于一些活动页, 有时候设计那边会出一些奇思妙想的设计稿, 对于一些需要支持动态修改的、含有特殊效果的文本, 如果 css 不能实现, 我们也可以考虑拼接 svg. 如下图:

产品需要动态配置活动起止日期, 而设计稿中有描边, css 中的 text-stroke 效果不好, 太生硬, 我们就可以在 react 中拼接 svg, 文本可以使用变量

const svg = <svg
  xmlns="http://www.w3.org/2000/svg"
  viewBox="0 0 180 24"
  width={`${180 * 6}px`}
  height={`${24 * 6}px`}
  fill="#BB7A09"
  style={{
    fontSize: "16px",
    lineHeight: "1.5",
    fontWeight: "500",
    textAnchor: "start",
  }}
>
  <text
    x="4"
    y={24 / 2}
    stroke="white"
    strokeWidth="4.5px"
    strokeLinecap="round"
    strokeLinejoin="round"
    // dominantBaseline 需要设置到 text 上, safari 不会从父节点继承该属性
    dominantBaseline="central"
  >
    活动截止日期：11月31日 {/* 这儿可以按需使用变量 */}
  </text>
  <text x="4" y={24 / 2} dominantBaseline="central">
    活动截止日期：11月31日 {/* 这儿可以按需使用变量 */}
  </text>
</svg>

需要什么效果, 就可以拉着 UI 一起配合写出相应效果, 主打的就是一个灵活。更多的 svg 的奇思妙想, 可以看看 tympanus.net/codrops, 里面有很多花里胡哨天马行空的交互、UI.

P.S. svg 当然也有劣势, 排版/换行什么的需要手动计算。但是我们只是在少量的地方自己写 svg, 大部分的 svg 直接从设计软件中导出来就能用, 所以无所谓。

]]>https://16px.cc/blog/5-4WU7eliMEdhttps://16px.cc/blog/5-4WU7eliMEdWed, 18 Oct 2023 03:45:44 GMT我们知道, Date 实例有一些 set 方法, 如设置月份 setMonth, 设置日期 setDate, 设置时分秒 setHours, 他们都可以接收零或者负数。

我们知道, setMonth(0) 表示将 Date 实例的月份设置为第 0 个月, 即 "1月"

const d = new Date('2023-06-06 06:06:06')
d.setMonth(0)
// 2023/1/6 06:06:06
console.log(d.toLocaleString())

我们也知道, setHours(0) 表示将 Date 实例的 hour 设置为第 0 小时, 即 "0点钟"

const d = new Date('2023-06-06 06:06:06')
d.setHours(0)
// 2023/6/6 00:06:06
console.log(d.toLocaleString())

但, setDate(0) 并不会将日期设置为本月第 0 天(1 号), 而是上月的最后一天…

const d = new Date('2023-06-06 06:06:06')
d.setDate(0)
// 2023/5/31 06:06:06
console.log(d.toLocaleString())

或许是因为 getDate() 返回值是 1-31?

同理, 参数为 -1 就显然了

]]>https://16px.cc/blog/fYj4OYafYbOkhttps://16px.cc/blog/fYj4OYafYbOkSun, 29 Oct 2023 06:40:54 GMT

• 不是支付宝的问题, 是我们自己业务的问题;
• 由于 xss 风险出在桌面端支付宝, 下面就只说桌面端支付宝的情况了;

前因后果

目前业务上接入第三方支付的流程是, 前端把商品 id 给后端, 后端返回订单 id 和第三方支付 (支付宝) 相关信息: 一个字符串, 内容为 <form>xxx</form><script>form.submit()</script>, 需要注入到页面内并执行 form.submit(), form.submit() 会将当前页面跳转到支付宝的支付页面; 伪代码如下:

``typescript {1,9} // 商品页面 // 先有的后端接口, 后有的业务流程; 后端接口和业务流程没有前端参与评审; const { orderId, aliHtml } = await post(/api/order/${goodsId}) // 由于当前页面需要保留, 所以只能新页面打开, 并在新页面中处理 form.submit() 相关逻辑 window.open(/pay-redirect?aliHtml=${aliHtml}`, '_blank') // 监听订单状态 (后续在页面中提示订单状态) const result = await listenOrder(orderId)

// 支付页面 (即 /pay-redirect) const { aliHtml } = searchParams injectIntoHtml(aliHtml) ```

相信大家能看出来了, xss 漏洞就发生在 /pay-redirect 页面, 直接从 url 中提取字符串并作为 html 注入到页面中, 是不安全的, 恶意用户可以在参数中添加恶意代码, 并作为钓鱼链接发布, 普通用户点击后就会执行恶意代码。

解决方案

1. 也是最优方案: 修改业务流程 (后端修改接口), 将获取业务订单和发起支付订单分为两个接口, 前端先获取业务订单, 再凭借业务订单来发起支付订单 (由于时间关系, 该方案没有被采纳);
2. 先修改前端流程, 后续有时间再说: typescript {3} const subWindow = window.open('/pay-redirect', '_blank') const { orderId, aliHtml } = await post(`/api/order/${goodsId}`) // 接口获取到 aliHtml 后, 再通知 /pay-redirect 页面 notice(subWindow, { aliHtml }) // 监听订单状态 (后续在页面中提示订单状态) const result = await listenOrder(orderId)

经验教训

没有, 因为方案评审压根就没拉前端 [卑微]

开玩笑啦, 不是吐槽, 其实还好, 之前一直都是这样, 后端自己内部评一下后端技术方案, 然后出接口文档, 然后前端按接口文档搭页面; 由于 90% 都是再常见不过的业务需求, 张三李四王二麻子谁来写都差不多, 接口文档也都大差不差, 所以一直没有什么问题, 只不过这次的支付可能就是那 10% ?

所以可能经验教训是: 夜路走多了, 总会碰到鬼?

]]>https://16px.cc/blog/lKUa2x0AJV0Rhttps://16px.cc/blog/lKUa2x0AJV0RMon, 25 Sep 2023 08:20:00 GMT

个人最终选择的方案是, 买了个腾讯云轻量服务器, 3 年 288 元，1 核 2G，硬盘 60 GB, 送宝塔镜像, 本地构建 Next.js 项目, 再推送到服务器, 最后执行 ssh 重启。为什么如此选择? 那就要说说其他方案为什么不合适了。

尝试一: 云上构建

云上构建, 最开始我试了 github action 监听 push 后自动触发宝塔 webhook, webhook 执行 git pull 从 github 拉取最新的镜像, 执行构建。结果第一步就折戟了, 服务器拉不到 github, gfw 挡住了。。。

既然 github 拉不到, 那 gitlab 总可以吧? 毕竟 gitlab 不需要梯子的。确实可以, 结果倒在了第二步: 服务器跑不动 Next.js 的构建。我重新试了一下, 空的 Next.js 项目可以 build 完成, 但是随便写点什么东西, 内存就爆了, 直接飙到 100%。

尝试二: 本地 windows 构建

我个人电脑是 windows, 云上是 centos, 其实这个方案我没尝试, 因为肯定失败: 项目依赖 sharp 进行图片相关优化, sharp 是需要在 install 的时候执行跟平台有关的 build 的, windows 上执行的 build, 放到 linux 上运行必然抛错。

尝试三: 本地构建+推送云端

所以我就 ~~本地装了一个跟服务器同一版本的 centos 镜像~~ 用 docker 搭了一个 跟服务器同一版本的 ubuntu 容器, 在里面执行构建, 构建完成后上传到服务器, 然后 ssh 执行项目 reload, 显然这样是可行的, 已经稳定运行了个把月了。部署脚本感觉没什么好说的, 愿意看的可以点 deploy.sh

Q & A

Q: 干嘛要脱裤子放屁，直接本地构建推云上不就好了？干嘛还要 docker 里面构建？

A: prisma binaryTargets 构建和系统有关，& Next.js 图片优化需要 sharp，sharp 跟 install 及 build 时的系统有关，本地构建没用；

Q: 你都用 docker 了，干嘛不直接把 docker 推到云端呢？

A: docker 里面带了一个 node 环境，300多M，即使 base node:alpine 也有200+M；我把里面构建的内容拿出来，才30多M，上传到腾讯云很费劲的好吗，轻一点不好吗

]]>https://16px.cc/blog/lOIqZGcuWRJphttps://16px.cc/blog/lOIqZGcuWRJpTue, 16 Apr 2024 08:19:57 GMT选择 aws 包

我们去 google awa upload from browser, 总能看见一个包的身影 —— @aws-sdk/s3-request-presigner, 以及一些关键字 —— getSignedUrl or presign, 我遇到了各种各样的干扰:

干扰一: deprecated

如果我们搜这个包 @aws-sdk/s3-request-presigner, 会发现 google 第一条就是 This API Documentation is now deprecated, 经过测试, 要用的就是这个包, 估计那个 deprecated 只是说那个文档 deprecated…

干扰二: 过时文档

还有一些干扰文档, 如:

// aws-sdk 已经过时了
const AWS = require('aws-sdk')

const s3 = new AWS.S3()

const url = s3.getSignedUrl(/* ... */)

aws-sdk 已经过时了, 我们应该用 @aws-sdk 系列包。

排除干扰, 然后照着 @aws-sdk/s3-request-presigner 文档抄就可以了

然而

即使照着抄, 如果你使用的是 pnpm, 仍然会报 warning(虽然并不影响运行), 看 log 会发现它缺少一个包 @aws-sdk/signature-v4-crt, install 就好了。

上码

代码放这, 以供参考

server side

// server side
import { getSignedUrl } from "@aws-sdk/s3-request-presigner";
import {
  S3Client,
  PutObjectCommand,
  ObjectCannedACL,
} from "@aws-sdk/client-s3";

import type { PutObjectCommandInput } from "@aws-sdk/client-s3";

const s3Client = new S3Client({
  region: process.env.AWS_REGION,
  // 所需其他参数请参考 S3Client 文档
});

type RequestUploadConfig = Pick<File, "type" | "size">;

export async function requestUpload(f: RequestUploadConfig) {
  // 我们可以在这里做鉴权及其他一些限制逻辑
  // ...

  const uploadParams: PutObjectCommandInput = {
    Bucket: process.env.AWS_BUCKET,
    /**
     * Key 实际上是上传的 pathname,
     * 但有一点需要注意, 不包括前缀 '/',
     * 即: 如果你的目标路径是 '/public/dir/file.txt',
     * 那 Key 应该是: 'public/dir/file.txt';
     */
    Key: uploadKey,
    // 我们可以限制用户上传的 type & size, 其他更多限制可以看文档
    ContentType: f.type,
    ContentLength: f.size,
    // 权限任选 public or private
    ACL: ObjectCannedACL.public_read,
  };

  const command = new PutObjectCommand(uploadParams);

  // 把预签名的 url 返回给客户端就好了
  return getSignedUrl(s3Client, command, { expiresIn: 3600 });
}

client side

// client side
const url = await requestUpload({
  type: f.type,
  size: f.size,
});

await fetch(url, {
  // 注意是 PUT, 而非 POST 或其他
  method: "PUT",
  body: f,
}).then((res) => {
  if (!res.ok) {
    throw new Error(`上传失败: ${res.statusText}`);
  }
});

// ok 上传成功

补充 Key 的问题

上面说了 Key 不能带前缀 '/', 因为当你调用 aws 删除命令时, 带 '/' 的话不能成功删除, aws 也不会抛错, 会静默地失败。

await new DeleteObjectCommand({
  Bucket: process.env.AWS_BUCKET,
  // 错误, 这样是删不掉的, 不能带 '/' 前缀
  Key: "/public/dir/file.txt",
  // 正确的 Key 应当是 'public/dir/file.txt'
});

]]>https://16px.cc/blog/ztv4GbGwZZcthttps://16px.cc/blog/ztv4GbGwZZctThu, 31 Aug 2023 16:46:49 GMT

"前端是个娱乐圈, 成天发明各种概念。"
"现在搞的服务端渲染, 那不就是炒 php 的冷饭?"
"前端千辛万苦爬到山顶, 却发现 phper 早已等候多时。"

本篇代码均为伪代码, 且不严谨不完善, 仅为示例

0. 纯静态 html

   XXX 博客欢迎你

1. 通用网关接口 CGI

• 服务器上实现动态网页的通用协议。
• 一次请求对应一个 CGI 脚本的执行，生成一个 HTML。
• 不限语言, Perl、Shell 脚本、C 都行。

   print("""
     XXX 商城欢迎你

     <form onsubmit="/buy">
        <input name="count" />
        <button onclick="buy">买买买</button>
     </form>
   """)

2. js & php

• js: 客户端执行一些脚本, 一方面节约服务端资源, 另一方面提高用户体验 (不用刷新整个页面);
• php: 更便捷地混排 server data + html + js;

   欢迎 <?php echo $_POST["fname"]; ?>! <br>

   <script>
   function plus(a, b) {
     alert(`和为 ${a + b}`)
   }
   <script>

   <input name="a" />
   <input name="b" />
   <button onclick="plus">相加</button>

---

在此之前, 前端大多不能独立部署, 代码组织也受限于后端, "戴着镣铐跳舞"。

3. ajax

js 能从服务端动态获取数据; 标志着前端有能力从代码层面脱离后端独立部署, 独立完成需求;

   <script>
     function buy(count) {
       fetch(`/buy?count=${count}`)
     }
   </script>

   <input name="count" />
   <button onclick="buy">买买买</button>

4. MVVM: react / vue / angular 等

• 原则: 数据驱动视图;

   const unitPrice = 10
   const count = 0

   // 之前
   function onClick(newCount) {
     count = newCount
     const total = unitPrice * count
     countElement.innerText = `个数: ${count}`
     totalPriceElement.innerText = `总价: ${total}`
   }

   // 之后
   const total = unitPrice * count

   function onClick(newCount) {
     count = newCount
   }

   return (
     <div>
       <div>个数: {count}</div>
       <div>总价: {total}</div>
     </div>
   )

5. (4.1) 前端路由 (单页面)

前端越来越简单, 能做的事情越来越多, 干脆一把梭, "路由也交给前端处理吧"; 前端统一组织代码, 切换页面本质上是组件替换, 能保留子组件状态, 能实现页面转场动画, 跳转还很快, 简直"一本万利"。

   if (pathname === '/a') {
     return <PageA />
   }
   if (pathname === '/b') {
     return <PageB />
   }

6. 服务端渲染 ssr

• 单页面的问题: 首次渲染很重 (懒加载可以解决)、SEO 不友好;
• (Node) 服务端渲染优点:
  • 有些东西在服务端就可以决定, 不需要发送给客户端, 降低传送的体积;
  • 服务端直出 html, SEO 友好;
  • 客户端、服务端语言一致, 类型可以共用;

   // server
   const config = await fetch('/config')

   if (config.aaa) {
     return <div>aaa</div>
   }
   if (config.bbb) {
     return <div>bbb</div>
   }

7. rsc (react server component)

即使如 ssr, 也需要生成一整个 html, 然后发给客户端, 如果我们能流式传输, 服务端一边处理, 一边响应客户端呢? 那速度不得起飞?

   // 真实代码远不是这样, 这写法甚至是错误的, 只为简述, 理解概念
   const aaa = await fetch('/api/aaa')
   const bbb = await fetch('/api/bbb')
   const ccc = await fetch('/api/ccc')

   return (
     <div>
       <div>{aaa}</div>
       <div>{bbb}</div>
       <div>{ccc}</div>
     </div>
   )

]]>https://16px.cc/blog/E_J4g1pSNTg2https://16px.cc/blog/E_J4g1pSNTg2Wed, 30 Aug 2023 03:54:29 GMT

服务器内存使用率 90%+, 我一个 2G 的服务器就运行一个 Node 和一个 mysql, 不可能占用那么多啊, 平时都是 40% 不到的, 所以需要排查问题

查看内存占用

首先应该查看是谁占用了那么多内存, top -c -o %MEM 可以查看当前系统实时视图

• -c 表示显示完整信息, 不截断
• -o %MEM 表示以 %MEM 排序

一看就发现问题了 (忘了截图), 排最前面有六七个 next-render-worker-app / next-render-worker-pages, 每个都占用了 %5 左右的内存, 加起来占了一半多, 原来内存都被你们吃了! 应该是 命令行重启 node 项目 的时候, 需要额外清理这些进程

解决方案

重启项目之前清理掉相应的进程: kill -15 $(ps aux | grep '[n]ext-render-worker-' | awk '{print $2}')

• [n] 是为了 Remove grep command while grepping using ps command

]]>https://16px.cc/blog/7qvCFp-jBGQghttps://16px.cc/blog/7qvCFp-jBGQgSun, 27 Aug 2023 06:34:14 GMT问题

今天改了 manifest.json, 推到服务器上后, 一直不生效。看了一下缓存头, Cache-Control: max-age:31536000, must-revalidate, 糟糕。。。

原因

• 下列所述 "过期" 是指 stale: 客户端综合计算 age + max-age + Date 得出的当前资源是否"新鲜 (fresh)"的状态;
• 源服务器综合考虑 If-Modified-Since 或 If-None-Match 后, 回复客户端是否过期 (如果已过期, 会在 body 中返回 200 + 新的资源; 如果没过期, 就返回 304);
• 下列所述 "不能" / "必须" / "应该" 都是指服务器如此要求, 但是否执行取决于客户端的实现, 你完全可以自己编译一个浏览器, 忽略请求头, 应该不犯法;

• no-store 表示不能缓存
• no-cache 表示可以缓存, 但客户端每次使用都必须与源服务器验证是否有变
• must-revalidate 表示可以缓存, 但一旦过期, 就不能继续使用该资源, 而是必须与源服务器重新验证才能使用, 如果连不上源服务器, 那你就别用了 (注意, 平时没过期的时候, 客户端是不会去找服务端验证的)
• stale-while-revalidate 表示即使缓存过期了也还能用, 只要你用了之后重新验证并更新缓存就好了, 但是如果验证出错了 (500 或 404 或其他什么错误), 那你下次就不应该再用那个过期的资源了 (非标准值, 预期浏览器兼容性差)
• stale-if-error 表示即使缓存过期了也还能用, 之后重新验证并更新缓存就好了, 万一重新验证出错 (500 或 404 或其他什么错误), 你下次还能用旧的缓存 (兼容性差, 约等于没有)
• immutable 表示只要还没过期,你就尽管用, 不要来问我服务器, 肯定不会变 (兼容性差, 约等于没有)

不应变化的静态资源可以适用 must-revalidate, 例如不会变化的文件如 vconsole.min.js, 自带版本号的文件如 sensorsdata-20110513.min.js, 这类文件无需打包, 可以直接放在 public 静态目录中, 内容长期不会变化, 如果有变, 我们也会修改版本号, 所以可以适用长期缓存, 且客户端每次使用都无需重新验证。(这种情况其实也能用/更适合用 immutable)

但是像一些可能有变、且不能随便修改文件名的文件, 千万不要使用 must-revalidate (即使要用, 也设一个短一点的 max-age)。如 favicon.ico, manifest.json 等, 应该用 no-cache, 每次用的时候必须验证是否有变。

解决办法

没什么好办法, 只能庆幸这是一个没人访问的私人站点。。。

1. 手动清理浏览器缓存, 发现还是没用, 然后发现 Response Headers 中有另一个 header: X-Cache: HIT, 所以:

2. 清理 nginx 缓存

OK, 勉强搞定

后记

最后, 如果真的有用户访问的项目遇到了这样的问题, 我们没办法一个一个去清理用户的浏览器, 那么我们能怎么做呢?

1. Deleting stored responses 说, 可以给服务器发个同 url 的 POST 请求

One of the methods mentioned in the specification is to send a request for the same URL with an unsafe method such as POST, but that is usually difficult to intentionally do for many clients.

2. 同样是 1 中的链接说的, 使用 Clear-Site-Data: "cache" 标头 (但是并非所有浏览器都支持该标头, 且该方法只能清空浏览器缓存, 无法处理中间缓存 intermediate caches)

总结来说, 就是谨慎点, 别搞出这样的事, 给自己找麻烦。

]]>https://16px.cc/blog/tIUWujf42LL0https://16px.cc/blog/tIUWujf42LL0Sun, 12 May 2024 03:18:50 GMT1. 终止进程

见 linux 一步到位解除端口占用

# {PORT} 指项目运行的端口号
kill -15 `lsof -t -i:{PORT}`

---

2023-08-27 append: 需要额外清理旧的进程, 详见 记一次排查服务器内存占用爆满

kill -15 $(ps aux | grep '[n]ext-render-worker-' | awk '{print $2}')

2. 重新启动项目

见 宝塔问答: 如何重启可视化 node 项目

# {PROJECT_NAME} 指你自己待重启的项目名
bash /www/server/nodejs/vhost/scripts/{PROJECT_NAME}.sh

]]>https://16px.cc/blog/LXf9GP8BHrb9https://16px.cc/blog/LXf9GP8BHrb9Sun, 27 Aug 2023 06:39:20 GMT查看占用端口的进程 id (即 PID)

# 此处的 {PORT} 指你需要查看的端口号
lsof -t -i:{PORT}

# 示例
lsof -t -i:3000

终止进程

# kill -15 让进程正常退出
kill -15 {PID}

# kill -9 表示强制中断, 不推荐使用, 只有当进程发生异常, 自身无法正常退出时, 才使用
kill -9 {PID}

一步到位

kill -15 `lsof -t -i:{PORT}`

如果你想终止某个命令

假定命令名是 next-render-worker-xxx

kill -15 $(ps aux | grep '[n]ext-render-worker-' | awk '{print $2}')

• [n] 是为了 Remove grep command while grepping using ps command

]]>https://16px.cc/blog/9FyGrXBK__jJhttps://16px.cc/blog/9FyGrXBK__jJSun, 27 Aug 2023 06:47:01 GMT

都是闲聊, hr 可以不用浪费时间在这里

我是谁

• 一个写了几年前端的人
• 稍微了解一丢丢的后端和运维
• 只想写 ts / react
• 不喜欢 vue，不喜欢小程序。个人爱好，没有原因

我是怎么走上前端的

2017 年 (也可能 16 年底? 不记得了) 我开始自学前端, 那时候一股脑扎进来, 什么都不懂, 甚至都不懂找教程。那时候的目的甚至不是工作, 只是感觉要学点什么, 恰好前端写了就能看到结果, 就学了。

当时买了一本红宝书《JavaScript 高级程序设计》, 照着敲, 忘了敲了多久了, 反正差不多敲完了一本书, 然后就到处找 demo 做, 其中有 2 个印象最深刻的, 一个是阿里某位大佬 (后来才知道是阿里的, 名字忘了) 的网站 http://www.fgm.cc/learn/ , 现在已经闭站了, 里面有很多入门级例子, 可以实现。另一个是 百度前端技术学院, 这是我唯一高度评价的百度的产品, 里面也有很多实战的项目, 并且由浅入深, 十分友好, 17 年及之前的题目都可称得上十分精良。可惜自从 vue 火了以后, 百度也想蹭一把热度, 强推自己的 mvvm 框架 san, 18 年 (也可能是 17 年年中?) 的整个站点项目全都跟 san 有关, 其后也慢慢消亡了。

17 年 4 月份的时候实现了我的第一个博客, 可以说标志着我从此走上前端这条路

现在来说十分粗糙, 生成文章是靠"批处理"来做的, 也没有服务端的概念, 全部都是一股脑 html + css + js, 也几乎没有用库的概念, 几乎全部功能都是 js 手写的, 所以里面的 复制本文链接 其实是没用的, 因为我当时不知道怎么复制文本, 也没想过去网上搜索答案…

我的前端路线摸索

17 年 vue 刚开始火, 那时候就开始学 vue + webpack, 那时候到处是 webpack 的脚手架, 就尝试着自己从零搭脚手架, 用以学习 vue 和 webpack。但是我比较笨, vue 的 slot 总是搞不明白怎么用 (我的我的, 才知道 slot 是 web component 规范的一部分), @click="func" 还是 @click="func()" 总是搞混, 我这人很不喜欢背东西, 可是 vue 总是有层出不穷的东西让我背…

后来 (忘了什么时候了) 接触到了 react 之后, 立刻就被 react 俘虏了, 这就是 js 啊, 没有任何新东西, 都是 js, 都是函数, 只有入参和出参。然后我就只做 react 了。

18 年入职了第一家公司, 做 3d 相关的, 想搞一点 webVR, 把我招进去了, 那时候学上了全景, 开始用 krpano, 我用得很不爽, 根本就没有一点 js 的风格。我就寻找替代品, 找上了 three.js, 这才是前端该用的东西嘛。但是那家公司不喜欢 three.js, 所以次年我离开了那家公司, 入职了我的第二家公司, 做汽车全景内饰改装的。(顺带一提, 第一家公司在我离开后三四个月就倒闭了, 当然跟我的离开没有关系 hhh)

19 年入职的第二家公司, 在我入职之前也是用 krpano 做全景, 我入职后也做了几个, 由于需要使用 xml 来书写 krpano 私有的语言, 也没有自动化工具, 效率奇低, 一天只能生成几辆车, 我入职之后, 自然就"不能惯着他们"了, 花了 2 个月重新实现了一整套, 从 three.js 前端到 python 自动化工具, 然后就舒服了, 只要电脑跑得过来, 车子随便你上, 三四个设计忙不过来了 hh

说实话, 自从我实现了那一整套之后, 我的工作就变成了优化前端界面和 "自动化工具操控者", 收收文件, 点点鼠标, 无聊得紧, 我感觉他们不需要我了, 我的工作, 随便一个运营的同学来也能搞定, 还能比我搞得更精细更好。只是自那之后是"不可言说的三年", 所以 20 年我又在那家公司呆了一年, 混日子的一年。在那一年, 我意识到 three.js 其实不是前端, 而是数学, 而我, 承认我的数学不足以驾驭它, 因此, 转向普通前端吧。

21 年, 入职了第三家公司, 普通的前端工作, 职责是为公司内部提供营销的技术支持。说得好听, 其实就是开发一些活动页, 无聊, 但有钱… 做的过程中, 我就意识到, react 很好, 可是貌似不太适合活动页, 单页面太重了… 可是没等我做什么, 仅仅呆了 4 个月, 公司裁员, 把我裁了, 因为 "双减", 而公司是当时青少年编程培训的领头羊, 首当其冲…

被裁了之后, 跟着公司另一个项目组, 另立门户, 成为了现在这家公司的一员。基于之前的认识, 我决定用 next.js, 做服务端渲染, 并一直做到现在。

我对前端的看法 (大言不惭)

下面谈论的都是传统的前端 (像我这样的页面仔), 其他如编辑器/web 3d 等, 我搞不来, 就不妄言了。

前端的现状 (我看到的)

• 随着前端越来越复杂, 前端人员也需要掌握一定的部署知识 (不用太多, 太多就成运维了hh)。

• 低代码在未来或许会吃掉一 (小) 部分低端岗位, 但不是现在。

• 社会上仍然存在大量前端基础岗位 (月薪 20k 以下), 也就是传说中的 "页面仔 (指我自己)", 虽然面临了一定的 ai 带来的冲击, 但较为微弱, 大多是开发者出于提高自身效率的自发行为, 未有颠覆性的效率工具冲击现状。但同时由于前些年前端培训的大力发展, 人员供应过于充沛, 且受当前经济形势影响, 因此基础岗位竞争较为激烈。

• 仍处于基础岗位上的开发者需要有危机意识, 一方面需要提高自身技术水平, 另一方面建议积极寻求跨界的机会, 如智能家居、车机等。

前端的未来 (我认为的)

• 短期 (未来 5 - 10 年) 来看, 社会发展、技术水平应该不会发展到, 不需要前端花力气优化、网页尺寸/性能无关紧要的地步。基于我个人的体验, 服务端渲染的页面性能、用户体验远好于传统单页面, 尤其是首屏体验。因此, 服务端渲染会在之后的几年越来越流行, 并成为顶峰时期的 jquery/php。(很难说是好还是坏)

• 一方面服务端渲染对开发者的综合能力要求更高, 包括需要了解服务端和客户端的差异 (虽然是基础知识, 但之前其实不了解也能写前端), 包括组织代码也会比之前更复杂; 另一方面 ai 飞速发展; 两方综合之下, 未来几年将会减少大量前端基础岗位。

• 随着社会的发展, wasm 将不再如现在这么 "重"; 同时随着语言的发展, 前端的门槛将越来越低, 其他语言的使用者将会更容易地 "侵入" 前端。"纯粹" 的前端将会在服务端渲染技术到达顶峰后, 面临长期的下坡路。未来是综合开发者的天下 (此处的 "综合" 并非是说技术上的 "全栈", 而是说综合性的、跨行业的)。

联系方式

"关于我" 是不是得留个联系方式？邮箱 MTAzODc2MTc5M0BxcS5jb20=

]]>https://16px.cc/blog/3EpPJTM2LwB_https://16px.cc/blog/3EpPJTM2LwB_Mon, 06 May 2024 16:29:43 GMT背景: 书接上文

上文说到, 如果页面上多个弹窗并存时, popstate 事件会在所有弹窗中触发, 导致一个 popstate 事件关闭掉所有弹窗, 那我们的问题就是, 如何管理 history 栈, 让其逐个触发呢?

实现思路

既然所有的弹窗都在监听 popstate, 那我们维护一个队列, 弹窗出现时往队列放入一个特征值, popstate 事件时, 弹窗根据队列尾部的值, 决定自身是否需要响应 popstate;

show me your code

首先我们实现一个管理 index 的机制

export class IndexManager {
  private stack: number[] = []

  get latest() {
    // 是最大值 而非 最后一个元素, 因为 stack 不一定是 有序的
    return Math.max(...this.stack) ?? 0
  }

  push(n = this.latest) {
    this.stack.push(n)
  }

  drop(n = this.latest) {
    this.stack = this.stack.filter((k) => k !== n)
  }

  has(n: number) {
    return this.stack.includes(n)
  }
}

然后就是最终实现了:

import { useListen } from './useListen'

import { IndexManager } from '@/utils/IndexManager'

import { useEventCallback } from '@mui/material'
import { useRef } from 'react'
import { useEvent } from 'react-use'

let ignoreIdx = -1
// 这个 manager 既非 stack, 也非 queue,
// 叫 stack 只是随便叫的
const stack = new IndexManager()

/**
 * 该 hook 可用于任何需要物理返回键的地方;
 * 注释中的所有 modal 或 弹窗 都不仅限于 "弹窗",
 * 任何需要的地方都可以用,
 * 如 Dropdown/Drawer/Tooltip 等, 任何有 visible change 的地方都可以用;
 * (其实没有 visible change 的地方也可以用, 毕竟该 hook 只负责管理 history, 不干涉 ui)
 */
export function useInjectHistory(
  open: boolean,
  /**
   * 如果需要在用户物理返回时关闭弹窗, 就在该方法中手动调用 modal.hide();
   * 如果拒绝关闭弹窗, 就别 hide() 并 throw Error;
   */
  onPopState: (e: PopStateEvent) => Promise<void>
) {
  // 弹窗维护各自的 index
  const IndexRef = useRef(-1)

  const finalOnPopState = useEventCallback((e: PopStateEvent) => {
    // 轮到我了吗? 没轮到就返回
    if (IndexRef.current !== stack.latest) {
      return
    }
    // 是上一个弹窗关闭而触发的 popstate 吗? 是就返回;
    // (并且把 ignoreIdx 标志位清掉, 使得下次 popstate 能正常生效)
    if (IndexRef.current === ignoreIdx) {
      ignoreIdx = -1
      return
    }
    stack.drop(IndexRef.current)
    onPopState(e).catch(() => {
      // 抛错时, 恢复 stack
      stack.push(IndexRef.current)
      window.history.pushState(null, '', window.location.href)
    })
  })

  useEvent('popstate', finalOnPopState)

  useListen(!!open, () => {
    if (open) {
      // modal index 初始化
      IndexRef.current = stack.latest + 1
      stack.push(IndexRef.current)
      window.history.pushState(null, '', window.location.href)
    } else {
      if (stack.has(IndexRef.current)) {
        // stack 内有该 modal index, 说明是其他地方手动调用 modal.hide, 而非物理返回所触发
        stack.drop(IndexRef.current)
        // 此时需要先清理 stack, 然后根据新 stack 设置标志位
        ignoreIdx = stack.latest
        // 设置标志位是为了避免下一个 modal 被此处触发的 popstate 关闭
        window.history.back()
      }
      // 不管怎么样, modal close 的时候都需要还原该 modal index
      IndexRef.current = -1
    }
  })
}

usage

``` typescript {4-6,14-16} function TempA() { const modal = useModal()

useInjectHistory(modal.visible, () => { modal.hide() })

return <> }

function TempB() { const [open, setOpen] = useState(false)

useInjectHistory(open, () => { setOpen(false) })

return { setOpen(false) }} > body } ```

]]>https://16px.cc/blog/CLc499WyaT7Khttps://16px.cc/blog/CLc499WyaT7KWed, 08 Nov 2023 14:22:38 GMT背景介绍

我们知道, 对于 app 端的弹窗, 物理返回键可以关闭弹窗, 但是在 web 端, 按物理返回键, 直接就返回上一页了。

返回键关闭弹窗, 无疑交互体验更好, 那么怎么实现呢？

首先向大家推荐一个好用的弹窗管理库: NiceModal, 下列代码都是基于该库以及 mui (大多是伪代码, 当然可以不用库或者使用其他库)

利弊分析及思路分析

基本实现思路

因为返回键会改变 history, 所以我们的实现思路肯定是通过监听 popstate 来关闭弹窗:

• 打开弹窗时 history.pushState()
• popstate 事件发生时关闭弹窗
• 同时当我们手动关闭弹窗时, 需要 history.back() 恢复 history 栈

好处

• 交互体验更好

坏处

• 由于需要 history.pushState() 和 history.back(), 会破坏用户的浏览记录
• 用户本来的浏览记录从 A 页面跳转 B 页面, 再返回 A 页面, 此时用户本来可以通过浏览器的 "前进 (forward)" 按钮回到 B 页面的, 如果我们在 A 页面执行 history.pushState() 的话, 用户就无法通过 back / forward 回到 B 页面了

期望的调用方式

暂且将我们的方法命名为 useInjectHistory

// 声明
const TestModal = NiceModal.create(() => {
  const modal = useModal();

  useInjectHistory(modal);

  return <Dialog>test modal</Dialog>;
});

// 调用
NiceModal.show(TestModal);

但是调用方需要有阻止弹窗关闭的能力, 也就是说 "弹窗关闭" 需要放在外部, 即:

// 声明
const TestModal = NiceModal.create(() => {
  const modal = useModal();

  useInjectHistory(modal, () => {
    modal.hide();
  });

  return <Dialog>test modal</Dialog>;
});

// 调用
NiceModal.show(TestModal);

实现思路

export function useInjectHistory(
  modal: NiceModalHandler<Record<string, unknown>>,
  /**
   * 如果需要在用户物理返回时关闭弹窗, 就在该方法中手动调用 modal.hide();
   * 如果拒绝关闭弹窗, 就别 hide() 并 throw Error;
   */
  onPopState: (e: PopStateEvent) => Promise<void>
) {
  // mui 的 useEventCallback
  const finalOnPopState = useEventCallback((e: PopStateEvent) => {
    isTriggeredByPopStateRef.current = true;
    // 当 popstate 发生时, 如果 onPopState 抛错 (即调用方拒绝关闭弹窗),
    // 那么此处重新 history.pushState, 以恢复 history 栈
    onPopState(e).catch(() => {
      window.history.pushState(null, "", "#dialog");
    });
  });

  // react-use 的 useEvent (也可自行使用其他方法, 反正就是监听 popstate, 然后执行 onPopState)
  useEvent("popstate", finalOnPopState);

  // useListen 见下文所述
  useListen(modal.visible, () => {
    if (modal.visible) {
      // 弹窗打开时, push history
      window.history.pushState(null, "", "#dialog");
    } else if (!isTriggeredByPopStateRef.current)
      // 其他地方 (非 popstate 事件) 触发弹窗关闭时, 恢复 history 栈
      window.history.back();
  });
}

useListen 见本站文章 一个监听变量变化的语法糖

---

2023-08-10 更新:

上面的实现有一个问题: 如果我页面上多个弹窗并存时, popstate 事件会在所有弹窗中触发, 导致一个 popstate 关闭了所有弹窗, 如何解决这个问题呢? 且听下回分解

]]>https://16px.cc/blog/njC-AH0TX131https://16px.cc/blog/njC-AH0TX131Thu, 10 Aug 2023 08:20:12 GMT由来

在实践中, 我们(我)经常会遇到, 当某变量变化的时候, 执行其他方法(副作用), 通常我们使用 useEffect:

function useHook() {
  const [varA] = useState();

  useEffect(() => {
    // do something
  }, [varA]);
}

但是如果执行的方法中包含其他响应式变量 varB, 我们需要 varB 的最新值, 但却不希望 varB 变化时触发 useEffect 重新执行, 那我们可能需要 hack:

function useHook() {
  const [varA] = useState();
  const [varB] = useState();

  // mui 的 useEventCallback
  const effect = useEventCallback(() => {
    doSomething(varB);
  });

  useEffect(() => {
    effect();
  }, [varA, effect]);
}

实现

因此我们可以写一个小小的语法糖来简化这一目的:

import { useEventCallback } from '@mui/material'
import useEnhancedEffect from '@mui/material/utils/useEnhancedEffect'
import { useRef } from 'react'

/**
 * @example
 * ``` tsx
 * function Component() {
 *   const [count, setCount] = useState(0)
 *
 *   // will be triggered when count changed
 *   useListen(count, (next, prev) => {
 *     console.log(prev, next)
 *   })
 * }
 * ```
 */
export function useListen<T>(
  value: T,
  callback: (next: T, prev: T | undefined) => void
) {
  const isFirstCallbackRef = useRef(true)
  const prevRef = useRef<T | undefined>(undefined)
  const callbackRef = useEventCallback(callback)

  useEnhancedEffect(() => {
    // useEffect 在 dev 环境会执行 2 遍, 此处避免该行为造成的影响
    if (value === prevRef.current && !isFirstCallbackRef.current) {
      return
    }
    isFirstCallbackRef.current = false
    callbackRef(value, prevRef.current)
    prevRef.current = value
  }, [value, callbackRef])
}

用法

``` typescript {4} function Test() { const [varA, setVarA] = useState()

useListen(varA, (next, prev) => { console.log({ next, prev }) })

// … }

### 利弊分析

#### 优势

- 语义明晰
   - 就是为了监听变量变化而生

- 免除各种冗余的格式代码

#### 不足

- 不应用于添加事件监听等

typescript useListen(varA, () => { // 错误用法, 因为没有消除副作用 (removeEventListener) window.addEventListener('event-name', callback) }) ```

]]>https://16px.cc/blog/QGMtI1cUUbNBhttps://16px.cc/blog/QGMtI1cUUbNBThu, 11 Jan 2024 05:18:40 GMT我们有时候使用 setTimeout 会简单粗暴地使用外部传入的值, 如下:

async function sleepMs(ms: number) {
  return new Promise((resolve) => {
    setTimeout(resolve, ms);
  });
}

这样通常情况下没问题, 但是如果输入的数值过大, 会出现意想不到的 bug.

我们知道 js 中, Number.MAXSAFEINTEGER 是 2^53 - 1, 但是 setTimeout 并不支持那么大的数。

https://developer.mozilla.org/zh-CN/docs/Web/API/setTimeout#%E6%9C%80%E5%A4%A7%E5%BB%B6%E6%97%B6%E5%80%BC

浏览器内部以 32 位带符号整数存储延时。这就会导致如果一个延时大于 2147483647 (即 2^31 - 1) 毫秒（大约 24.8 天）时就会溢出，导致定时器将会被立即执行。

所以, 如果数值是外部传入的, 建议函数内做一个简单的判断 (过滤):

async function sleepMs(ms: number): Promise<void> {
  // 至于如何处理 NaN, 则可以根据业务, 自己决定是抛错还是赋默认值
  if (Number.isNaN(ms)) {
    throw new Error("invalid input: NaN");
  }
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve();
    }, clamp(ms, 0, 2 ** 31 - 1));
  });
}

]]>https://16px.cc/blog/IClO74MRNFmShttps://16px.cc/blog/IClO74MRNFmSThu, 27 Jul 2023 17:02:53 GMT这儿是工具函数

async function sleepMs(n: number) {
  return new Promise((resolve) => {
    setTimeout(resolve, n);
  });
}

async function asyncFunc() {
  await sleepMs(500)
}

async function randomAsyncFunc() {
  await sleepMs(Math.random() * 1000)
}

忠告一: 异步函数如果有顺序要求, 则最好 await 之

// 此处, 你能幸运地得到顺序打印的 1 2
async function main() {
  asyncFunc().then(() => {
    console.log(1)
  })

  asyncFunc().then(() => {
    console.log(2)
  })
}

// 此处, 只有老天才能知道 1 2 的打印顺序了
async function main() {
  randomAsyncFunc().then(() => {
    console.log(1)
  })

  randomAsyncFunc().then(() => {
    console.log(2)
  })
}

// 因此: 如果对顺序有要求, 最好 await 之
async function main() {
  await randomAsyncFunc().then(() => {
    console.log(1)
  })

  await randomAsyncFunc().then(() => {
    console.log(2)
  })
}

忠告二: 谨慎在异步函数中操作引用变量

async function anotherAsyncFunc() {
  const arr = []

  sleepMs(500).then(() => {
    // 在异步函数中操作引用变量需要谨慎 (这是错误用法)
    arr.push(42)
  })

  return arr
}

async function main() {
  const res = anotherAsyncFunc()

  // 这儿打印的结果是 []
  console.log(res)

  await sleepMs(1000)
  // 这儿打印的结果却是 [42]
  console.log(res)
}

先解释一下上面的代码, 就是由于 arr 是引用变量, 所以, 返回值 res 开始是空数组, 等睡了 500 ms 后, arr.push(42) 被执行, 导致返回值被修改, 此后 arr 变成了 [42]

你可能会说, 谁会写出这么傻的代码, 我只能说有则改之无则加勉, 操作异步函数需要谨慎, 最好是等待其 await, 如果特殊场合不允许, 则尽量别在其内操作指针或执行有顺序要求的动作, 一定要这么做的话, 确保自己能 hold 住

]]>https://16px.cc/blog/xhh7Oqi2-JXRhttps://16px.cc/blog/xhh7Oqi2-JXRFri, 28 Jul 2023 16:18:01 GMT移动端-首页

移动端-博文页

桌面端-首页

桌面端-博文页

]]>https://16px.cc/blog/-hg7STBVhTqthttps://16px.cc/blog/-hg7STBVhTqtThu, 18 Jan 2024 15:59:41 GMT一些说明

• ~~网站这么慢的原因~~

• 不存在了, 搬到国内了, 速度上来了

• 懒得搞 api, 直接使用的 rpc 形式的 server action, 导致页面 cache-control 用不上, 始终是 no-store, 页面没法静态化, revalidate 失效;

  • 这个问题不想解决, 因为没人给我写后端, 而 next api 太孱弱, 新开一个 nest 项目又太麻烦, rpc 又太香了。。。

• 选用了 aws 海外版, 只部署了首尔一个节点, ssl 握手就要花好几秒。穷就一个字, 我只说一次;

  • 这个问题理论上换到国内部署就能解决, 而由于 aws 有 amplify 便于部署, 所以也不想解决。。。

• 偶尔会显示 服务器错误 是什么鬼

• 大概率是超出了数据库最大连接数;

• 数据库免费时长只有 750小时, 所以只开了一个实例;

• 因为选用了免费的 aws mysql db.t3.micro 数据库, 1gb ram, 2 vCPUs, 最大连接数为 60, 而 Next.js Link viewport prefetch 导致并发请求, 由此导致数据库并发连接过高, 超出 max_connections;

• 服务端对 5xx 错误做了过滤, 统一显示 "服务器错误, 请稍后再试";

• ~~待采取的措施是: unstablecache + 一个很长的过期时间 + 修改内容后自动更新相应的 unstablecache 的 tag;~~

• 已采取措施: 前台页面加 unstable_cache + 一个适当的过期时间, 以减少访问数据库;

• 参考 prisma 的建议, connection_limit 改成 1

• 取消使用 next/link prefetch

todos

• [ ] ~~通知从钉钉机器人改到电报机器人 (本来白嫖的公司的钉钉机器人，可是不知道是不是钉钉收紧了，直接 over limit 了。。。)~~ (傻乎乎的，没有梯子，怎么用电报机器人。。。)
• [ ] 架一个梯子
• [ ] 自动生成描述文本 (真的需要吗?)
• [ ] 编辑的缓存
• [ ] 账号过期机制
• [ ] pre > code 添加复制按钮
• [ ] api 日志
• [x] bf cache not working
• [x] 全站音乐(页面跳转音乐不断)
• [x] 全站字幕(页面跳转字幕不断)
• [x] ~~tagList 加个背景，与其他部分分隔开~~(不需要)
• [x] 在自己的博文加上"编辑"按钮
• [x] sitemap
• https://nextjs.org/docs/app/api-reference/file-conventions/metadata/sitemap#generate-a-sitemap
• https://claritydev.net/blog/nextjs-dynamic-sitemap-pages-app-directory
• [x] 添加 robots
• [x] 添加 rss (参考: https://taoshu.in/webfeed/lets-webfeed.html)
• [x] 标题(h1-h6)增加 hash & id, 支持点击修改 url
• [x] ~~新增 TODO/road map 页~~ (不需要了, 放在这个博文里)
• [x] 优化深色模式的实现逻辑(现在初次渲染时闪屏太严重了)
• [x] 部署问题 (用了 aws, 一键解决了)
• [x] ~~nginx~~(不需要了)
• [x] ssl
• [x] 优化 a11y 及键盘导航
• [x] 上传功能
• [x] 非 admin 用户限制上传数量和文件大小 (注: 不支持非注册用户上传文件)
• [x] 文件上传支持图片预览 (因为上传的主要内容就是图片)
• [x] 支持粘贴式上传文件 (全站任意地方粘贴文件触发上传)
• [x] 支持拖拽式上传文件 (全站任意地方 drag and drop 触发上传)
• [ ] 优化上传的交互 (如上传时的空状态等)
• [x] 上传弹窗的关闭按钮改为完成
• [x] react server component streaming with suspense
• [x] ~~pwa 消息订阅与推送~~ (不用 pwa 了)
• [x] 前端路由时, 页面 title 不会变化; ( 这儿说解决了, 解决个毛线… )
• 解决方案: 额外添加了前端修改 title
• [x] 内容页的编辑按钮直接打开编辑弹窗
• [x] 博文编辑完成后 revalidateTag
• [x] 需要配置 next-image config, 考虑下是否需要 next/image
• [x] 尝试把 title 放到article 中 (主要是考虑 UI)
• [x] 401 默认弹出登录弹窗
• [x] 统一弹窗 UX (存在部分弹窗关闭按钮在左侧)
• 目前统一在右上角, 除了博文编辑, 右上角放保存和预览按钮, 放不下关闭按钮了
• [x] media 新增 loading 态
• [x] 弹窗支持物理返回键 (物理返回键功能实现见 我给弹窗添加了支持物理返回键 一)
• [x] 图片预览 (也支持物理返回键)
• [x] 考虑一下网站搬到国内服务器
• [x] s3 上的资源加缓存头
• [x] 自动生成博文目录
• [x] 固定图片尺寸 (可选方案: 尺寸信息放在 url 上)
• [x] ~~添加谷歌收录 (国内域名本来就做了)~~
• [x] 自动评估阅读时长
• [x] ~~新增 about me 页 (不需要, 直接放博文里吧)~~
• [x] 全站搜索功能 (当前支持博文搜索)
• [ ] 待支持功能搜索、页面搜索
• [x] 新增 404 500 页面
• [x] ~~回复功能 (站点在国内, 估计上不了这个功能了)~~
• [x] 一次性链接 (支持访问密码 + 访问时间限制 + 访问次数限制)
• [x] 文章底部统一展示版权声明
• [x] ~~资源管理页 (管理个毛线, 不需要了)~~
• [x] 添加友链页面
• [x] 添加留言页面 (单向, 给站长留言, 其他人看不到)

bugs

• [x] !!! 高危 !!! server action 缓存和 service worker 发生了化学反应, 具体原因待查; 表现是, 版本更新后, 本地访问到了旧的页面, 旧的页面引用旧的 js, 然而旧的 js 资源已经失效了, 导致页面崩溃
• 不用 pwa 了, html 也不用缓存了, 所以不会有这个问题了
• [x] tags 上面的数量，需要仅计算 published 的博客
• [x] 不可见博客的推荐阅读，第一条就是它自己
• [x] 博客编辑中，默认没有填充标签
• md mui Autocomplete 自己有 bug, Chip 没加 key, 导致控制台一直报红色 warning, 很烦
• [x] tag/hash 页 tagName 颜色有误
• [x] mui Stack 注意换行问题
• [x] 在 pwa 应用中通过 target _blank 打开站内链接偶现直接展示出了 post response
• 原因: 不是 post response, 是 get response, 因为在 next.config.js 中为页面设置了 cache-control, 浏览器直接读取了本地缓存…
• 解决方案: 页面不缓存了…
• [x] ~~pwa 封面图背景色有误~~ (不用 pwa 就不管了)
• [x] revalidateTag 更新内容后, 本地 pwa 没有更新, 导致刷新页面和前端路由切换页面时的数据不统一
• 不用 pwa 了
• [x] /blog/[hash] 页面缓存仍有问题
• unstable_cache 博客修改之后要更新一堆的东西, 考虑一下别用了
• 国外接口耗时太久, 站点放到国内就没有这个问题了
• [x] 登录过期导致的 401 未能弹出登录弹窗
• [x] 更新博客后的 router.refresh() not work
• 国外接口耗时太久, 站点放到国内就没有这个问题了

解决方案

• dark mode 解决方案:

• 使用 CSS theme variables

• nextjs 13 dev 模式下特别慢

• https://github.com/vercel/next.js/issues/46756#issuecomment-1478038089

• 改 import { XXX } from '@mui/icons-material' 为 import XXX from '@mui/icons-material/XXX'

• 避免 barrel files, 如果一定要, 建议 https://github.com/vercel/next.js/issues/12557#issuecomment-696749484

疑问

• 数据库的连接是怎么回事? 是不是我只要从数据库取一次东西, 就会占用一个连接?
• 答: 部分正确, 查询完成后, 会将连接释放到连接池中可供后续请求使用; 所以当有并发请求时，数据库连接可能会过高','博客问题汇总','PUBLISHED','本博客待新增的 feature、待解决的 bug、已解决问题的解决方案的一个汇总

]]>https://16px.cc/blog/MlShKQJhLUEThttps://16px.cc/blog/MlShKQJhLUETThu, 29 Feb 2024 03:16:21 GMT让我们想象一个场景：

“下班顺路买一斤包子带回来，如果看到卖西瓜的，买一个。”

现在，让我们用 react 来实现一下：

```tsx {2,5,17} function GoHome() { const [loading, setLoading] = useState(false)

const goForward = async () => { setLoading(true) const stuff = await lookAround() switch (stuff) { case '包子': await buy(2, '斤', '包子') break case '西瓜': await buy(1, '个', '包子') break default: break } setLoading(false) }

// do something with loading }

这样显然是不行的，因为异步方法可能会抛错，导致 `setLoading(false)` 被跳过，那么我们可能会：

tsx {2,6} const goForward = async () => { setLoading(true) try { // … } finally { setLoading(false) } }

这样实在是不够优雅。

what about this:

tsx {2,4} function GoHome() { const [loading, withLoading] = useLoading()

const goForward = withLoading(async () => { const stuff = await lookAround() switch (stuff) { case '包子': await buy(2, '斤', '包子') break case '西瓜': await buy(1, '个', '包子') break default: break } })

// do something with loading }

以此延伸，我们通常会有这样的需求：点击按钮时发送请求，如果请求超过 500 ms, 再展示 `loading`

tsx {2} function HelloWorld() { return

点我一刀 999 }