redux 本来就不适合在组件里用。redux 适合用来保存全局状态，跨组件调用方法、获取变量。我的项目里用的是 redux-toolkit，感觉这个用起来比 redux-saga 舒服多了。

redux 就好比电线、组件就好比电器。电器电源线插到插座上就能用，但是不代表电器里面的所有线路都要接到电源线上。就像星际里的卡拉，虽然神圣的卡拉连接着每一个人，但是每个人的思想、状态还是有区别的。

你这种流程，完全可以用一个 hook 来代替，比如这样：
```javascript
const {
loading, // 加载状态
getData, // 获取数据的方法，可以用来重新获取数据
data, // 数据
... // 其他状态，比如数据总数、分页之类的
} = useRequest({ /* 配置 */ });

```

状态全放在 redux 里这种用法，我以前在项目里碰到过，我接手后给我留下一堆问题。比如有定义了一堆的 action type，导致一个流程的代码跳来跳去，action type 看不出来是做什么的；还有就是组件的所有状态被扔到 redux 里边，导致组件不能被复用的。

组件不要用 redux，你这么做，如果多个相同组件存在，却公用同一个状态，会出问题的。
内部可以考虑使用 useReducer 和 useContext 配合使用。

我之前是通过越狱了的手机安装 ssl-kill-switch2 抓的

分工，UI 没有要求只是没有人设计，但是交互体验还是要有的。我们开发的后台，同事有使用起来不舒服的地方，都是群里喊人私聊反馈然后修改的。
而且多个后台可能对应多个项目的接口，不分开的话，代码复用就会很麻烦。
后台之间也可能会需要封装成组件来复用代码。

其实 jsdom 、cheerio 、linkedom 是可以在浏览器中使用的，只不过没提供浏览器能使用版本而已。
我现在在浏览器中处理 html 就是用的 DOMparser 和 cheerio （因为 DOMparser 不能在 webworker 的环境中使用）。
不过看来 LZ 也不一定会用 webpack 和 rollup，还是用 DOMparser 吧。

原生的选择上面已经说了，用 DOMParser 。
用库解析的话就可以考虑 jsdom 、cheerio 、linkedom

我其实不太喜欢用 es5 、es6 这个说法来区分新 js 语法和旧 js 语法，js 就是 js，所谓的 es6 、es2018 、es2020 都已经进入标准了，那么它就是白纸黑字清清楚楚写着的 ECMAScript 标准。也就是说写 var a = 5; 也是 js ； for await (const item of list) {} 也是 js 。

前端不纠结语法是因为有 babel 、core-js 这两个利器，它极大大大大大的减少了开发的负担，不用关心语法的兼容问题。下能兼容 ie7，上能跑到 chrome91，跨越几十个版本。

云有内网服务的吧

应该下载的是 sass 而不是 dart-sass，dart-sass 不会用到 python，因为它已经被编译成 js 了。

@xiebruce 用户主动选择的是可以拿到真实路径的，或者自己调用自己的文件的话，虚拟路径也是可以运行的。但是因为软件没有签名啥的，是没法通过变量获取到当前文件的真实路径，至少 electron 是这样的。

http 请求和响应，正常来说的话，比如请求的路由是 /index.html 、/a.css ，会在目录下面寻找相应的文件；或者 /a/b/c，服务器解析后返回相应的信息。

单页应用切换路由，不会再去请求，所以本地切换是正常的。你请求"/"，返回 index.html 。但是刷新后，重新请求"/admin/user"，你的服务没有对这个路由进行处理，所以返回 404 。

所以你需要把请求的路由，都返回 index.html 的内容。这样无论你请求的是 /a 、/a/b/c/d，都会返回 index.html 的文档内容，然后 react 或 vue 根据当前的路由渲染内容。

单页应用，需要把所有的路由请求都返回 index

原因有很多，比如项目组解散了导致项目没人维护；没有专业的前端来开发，写代码的人还停留在几年前的认知水平；或者项目就展示了几个表格数据。但是对于新项目来说，基本上都已经放弃 jquery 了。

用 react 、vue，就绕不开 webpack 、express 或 koa 、babel 或 typescript 。对于大型的系统来说，用 react 、vue 这些比用 jquery 开发快得多。数据驱动、不需要操作 dom 、以前代码是业务 + dom，现在是只写业务代码，加上 babell 或 typescript 帮你解决代码兼容问题，组件的封装和复用，单页应用，你写的不再是网页，而是应用。

而且以前开发过程中需要解决的问题，比如热更新、热替换、mock 、跨域、代码复用、不同环境下输出不同代码等等，都能很好的解决。以前代码复用是复制粘贴，现在是发到 npm 、使用的人引入模块；以前跨域找后端、现在跨域 node 的 server 直接配置代理。

发布项目的时候直接一个命令，帮你压缩代码、图片；上传 cdn ；域名替换；脚本注入等等。

相比 jq 的时代，现在开发真的是方便、舒服、快速多了。

mac 上的软件如果没有签名的话，拿到的只是一个虚拟文件路径，拿不到软件真实的目录。

现在常用的 loader 和 plugin 已经支持 webpack5 了。给我自己项目用的搞的脚手架和我们项目用的 umi，升级到 webpack5 后都没有问题。有问题的有可能是 loader 和 plugin 本身 api 的变化。

声明 webpack4 的，有些是已经废弃的，可能是 webpack 已经内置的功能，有些是不需要升级的，没有用到 webpack 已经废弃的 api，所以兼容 webpack5 。在 ts 编译时忽略错误即可。

webpack5 的 top-level-await 、Module Federation 、filesystem cache 等都很有用，并且编译速度真的是大幅度提升，我们的项目编译时间从 4 分钟缩短到 2 分钟内，在 docker 内的打包时间从 10 分钟降低到 3 分钟。

emmmm......代码写的实在是太复古了

不仅用，而且配置相当严格。ts 直接要求全部声明类型。严格要求自己。
见过不用 lint 的代码，真的就是屎一样，没有约束，都要飞起来了。

这种都是拿软件做的，正常很少有手写 svg 的。我曾经实现一个 button 的 hover 渐变特效，纯手写，连查文档再调试，花了四五个小时。
你这个题，基本上是招不来人了。