纯前端npm项目

发表于 分类于 评论数：
  • 项目目的: 之前的”纯flask前后端+个人项目”已经不够用了, 需要尝试”前后端分离+用户系统+npm工作流”玩法
  • vercel官方的flask+next.js教程
  • shadcn, daisyui
  • 关于弃用next.js的原因
    • 服务端渲染（SSR）、静态站点生成（SSG）、集成的 API 路由、开箱即用的优化（如图像、字体）。这些特性都是为了解决​​大规模、高要求的生产级网站​​所面临的 SEO、性能、开发规范问题
    • 无需 SEO、用户极少、页面极少。Next.js 的核心卖点你一个都用不上
    • Next.js 的 App Router 概念（Server/Client Components, Streaming 等）有一定的学习曲线。你只是想写个简单的 React 页面，却要先理解这些复杂概念，这无疑是巨大的、不必要的开销
    • 业界确实有人用 Next.js 但关闭 SSR 做纯前端项目，但这就像买辆跑车只在市区代步，不仅浪费，还开得憋屈
  • 关于部署到vps而非vercel的原因
    • vendor lock-in 的风险
    • ​​架构统一​​、​​管理方便​​、​​没有额外费用
  • 关于额外库
    • （TanStack Query/React Query, Zustand, Redux）都是为了解决特定复杂度的问题的。你的项目规模根本触及不到那些问题
    • ​​数据获取​​：直接用 fetch 或 axios 在 useEffect 里获取数据就足够了。对于 10 个用户，完全不需要复杂的缓存和同步策略
    • 状态管理​​：useState 和 useContext 足以在三个页面之间共享任何必要的状态。引入 Zustand/Redux 纯属过度设计
    • ​​路由​​：这是​​唯一一个你可能需要引入的库​​。因为三个页面肯定需要路由。但别怕，react-router-dom 非常轻量且简单
  • 技术栈
    • react: 确定喜欢+好用
    • tailwind: 确定喜欢+好用
    • vite: 构建
    • react router dom: 路由
    • tanstack query
  • 状态管理: useState, useContext

实际开发

跑题: 前端与后端

  • Create React App 早已被官方淘汰（2023年弃用），Vite 是 React 团队推荐替代品
  • ​​npm create​​: 这是 npm init 的别名（完全等效），但语义更清晰
  • --: –template react​​: 第一个 – 是 npm 参数终止符. 后面的内容会传递给 create-vite 作为参数
    • pnpm 不需要额外的 –
  • 创建工具的演进:
    • npm install -g create-react-app
    • npx create-react-app my-app: 避免下载临时包
    • 2025年最新用法: 遇到 create-xxx 类工具时，永远优先用: npm create xxx@latest name -- [参数]
    • npm create 本质是 npx create- 的语法糖，两者在 2025 年完全等效
    • npx <包名> # 自动完成：下载->执行->清理
    • 以上局部安装/毫不缓存的原因: 前端更新迭代比后端快得多, 且都是破坏级更新/毫不兼容
  • 关于对前端的厌恶:
    • 1, 前端工具像外卖——随叫随用，吃完就扔; Python 工具像厨房设备——装好后长期使用
    • 2, 必须兼容各种浏览器引擎（Chrome/Safari/Firefox）vs 完全控制服务器环境
    • 3, 用户侧/感官侧 vs 吞吐量/稳定性
    • 4, chrome完全主导 vs linux开源社区
    • 关于npm create vite实际调用create-vite这个”语法糖”(实质设计缺陷)的历史缘由:
      • 2023年的”语法糖”：试图模仿yarn/pnpm: npm create react-app my-app
      • ​诡异转换逻辑​​：当你输入 npm create xxx，npm 会：
        • 1.自动查找 create-xxx 包
        • 2.如果找不到，再尝试查找 @xxx/create 包
        • 3.最后才报错
      • 这种设计是为了兼容历史遗留包（比如 create-react-app 和 @angular/create 并存），结果导致更混乱的局面
    • 前端生态的混乱本质上是​​过度民主化​​的恶果
    • Babel + PostCSS + ESLint 等层层转译
  • 对于前端生态的态度:
    • 彻底无视前端生态的噪音​, 锁定最小最基础技术栈
  • 后端 (Backend) -> 逻辑与数据
    • 传承​​：源于计算机科学本身，与操作系统、数据库、网络协议这些稳固的基石紧密绑定。开发者更像传统的“工程师”，崇尚稳健和长远规划
    • 后端是​​基石​​，追求不变的正确；前端是​​界面​​，追求常新的体验。两者的核心使命决定了其技术气质和开发者文化
    • ​​Linux / 后端OS​​：它的稳定在于其​​内核接口的极度保守​​。一个几十年前编译的二进制程序，在今天的主流 Linux 发行版上大概率还能运行。它的发展是​​向后兼容的、累积式的
  • ​​前端 (Frontend) -> 交互与表现​​
    • ​​核心价值​​：​​用户体验、感官表现、交互反馈​​。处理的是如何将数据以最直观、最美观、最流畅的方式呈现给用户，并响应用户的操作。它的核心是心理学和设计学，追求的是“体验”。
    • 传承​​：源于“文档”和“设计”。早期网页是纯文档（HTML），后来加入了样式（CSS）和交互（JS）。它确实有从“美工”演变而来的历史痕迹。这种使命要求它必须不断适应新的交互设备（从桌面到移动端再到可穿戴设备）和新的设计潮流，因此天生具有“求变”的属性
    • Web API (HTML/CSS/JS)​​：它的“不稳定”在于其​​功能的快速扩张​​。Web 从一个简单的文档平台，被赋予了应用平台的使命（Web App），这就需要不断增加新的、复杂的能力（如复杂的图形、3D、本地文件操作、硬件访问等）。
    • CSS​​：从最初的简单样式，发展到 Flexbox、Grid、动画、滤镜，未来还会有嵌套、颜色函数等
    • Web 的“变”不是推倒重来，而是 ​​“在绝对保留旧东西的基础上，疯狂增加新东西”​​。这是另一种形式的“稳定”——​​极致的向后兼容​​。你可以用 2025 年最新的特性写一个页面，但 1995 年写的简单 HTML 页面在今天依然能完美渲染。这种兼容性承诺是 Web 的基石
  • react ​​Class Component 的问题​​：
    • this 绑定、生命周期方法难以理解（componentDidMount, componentDidUpdate）、代码复用困难（HOC, render props）。这确实让 React 变得臃肿
    • 函数式组件 + Hooks 的优势​​：更简单的心智模型（纯函数）、逻辑复用更轻松（自定义 Hooks）、代码更简洁。这代表了 React 向“稳健和简洁”的回归

vite

  • 官方对create react app的淘汰说明: 2025.0214
    • 迁移到框架: next.js, expo
    • 迁移到构建工具: vite
    • 弃用的原因: 不存在它的生态位了: react专注于语法维护, 这个工具的初衷只是便利初学者的工具而已
  • ​TanStack Query (原React Query)​
    • fetch​​：浏览器原生API，仅完成​​单次HTTP请求​​，不管理缓存、重试、依赖更新等
    • TanStack Query​​：专门管理​​服务端状态​​的库，处理数据缓存、后台更新、请求去重等复杂逻辑
  • React Router 团队将其称为“框架”，是为了强调其​​提供的是一套完整的路由解决方案​​（包含数据加载、错误边界等），而不仅仅是 URL 匹配。但在大众认知中，它依然是一个库
  • 配置 SSR 需要自己搭建 Node 服务器、处理路由、协调 hydration，极其复杂。
    • Flask 无法直接用于 React SSR​​：React SSR 需要在 Node.js 环境中运行。那个 65 star 的库只是一个蹩脚的 hack，绝不推荐
    • 正确路径​​：要实现 SSR，你应该直接选择 ​​Next.js​​ 或 ​​Remix​​。它们是从头到尾为 SSR 设计的框架
  • ​​npx create-react-router@latest​​：这是 ​​React Router 团队官方维护的、基于 Vite 的模板​​。它内部调用的就是 Vite，但预先为你配置好了 React Router 的最新实践、数据加载等
  • 包管理器选择（npm/yarn/pnpm/bun/deno）
    • yarn: 已停止维护
      • 类比： 想象你在做一个大型项目（比如建一座房子），你需要用到很多第三方的工具和材料（比如水泥、砖头、电线）。这些工具和材料就是“包”（Package）。
      • package.json 文件就是你的 “材料清单”，上面写着你需要“水泥 v2.1”、“砖头 v5.0”等。
        • 决定项目依赖的是 ​​package.json​​。所有包管理器都遵循这个标准文件
      • npm 和 yarn 就是 “总包工头”。它们负责根据你的清单，去仓库（NPM Registry）里，把所有你需要的、以及你的材料所依赖的其他材料（依赖的依赖），全都准确无误、高效地拉到你的工地（node_modules 文件夹）上。
      • Lock 文件就是将你首次安装时所有依赖（包括依赖的依赖）的 确切版本号、下载地址 和 完整性哈希 全部锁定下来。这样，任何人、任何时间、任何地点执行 npm install 或 yarn install，都会得到一个一模一样的 node_modules 文件夹。它保证了环境的 确定性 (Determinism) 和 可复现性 (Reproducibility)
        • ​​锁文件​​：每个包管理器会生成自己的锁文件（如 pnpm 生成 pnpm-lock.yaml）来精确锁定依赖版本，​​确保每次安装结果一致​​。这些锁文件不应提交到 Git（但通常建议提交），切换时删除旧的即可
      • Facebook 在其巨大的项目中被 npm 的痛点折磨得苦不堪言，于是联合 Google 等公司推出了 Yarn
      • ​​发布包​​：无论你使用哪种工具开发，​​发布包到 npm registry 的唯一标准工具是 npm publish​​（或通过 npm 账号的网页界面）。其他工具不提供发布功能
    • ​​Bun/Deno​​：它们不仅是包管理器，更是 ​​Node.js 的替代运行时​​。它们旨在提供一个更现代、更快速、更安全的 JavaScript/TypeScript 执行环境
  • 可通过pnpm why isbot查看依赖树
  • npx tailwindcss init: 你的项目使用了 @tailwindcss/vite 插件，它简化了 Tailwind 的集成，因此不需要手动创建 tailwind.config.js。但如果你想自定义 Tailwind 的配置（例如修改主题、添加自定义颜色等），仍然可以手动创建它. 这会生成一个默认的 tailwind.config.js，你可以按需修改