carrie999/blog

• 👩 about me： https://www.saintgirl.xyz/
• 💖 todolists: https://todo.saintgirl.xyz/
• 🌟 ios APP：https://apps.apple.com/us/developer/yajing-pang/id1745831534
• 😄 Interesting: https://colors.saintgirl.xyz/ & https://texture.saintgirl.xyz/
• 🌸 floralTile: https://floralweb.vercel.app/
• 🎮 soul wanderer: https://soulwanderer.vercel.app/

blog's Issues

Resume english

前端开源的新库，听我说谢谢你🙂

前端的历史我就不讲了，从jquery时代到react vue angular 等响应式框架。
虽然黑人不好，这次来讲一下前端的大坑有哪些，作为一个业务型开发前端，真的被他们整的太惨。
从JS 到 TS
最近微软还有个大公司，好多源码都在向ts靠拢，于是公司就开始推广ts，他们 美之名曰的优点
VSCode的提示了解到函数的参数和返回值信息：
export function foo(name: string): number {
return name.length
}
比如这个，你下次使用foo就给你提示，传入个number就给你提示不对
就是约束类型，自己开发的给别人使用能传递更多的信息。
缺点就是自己多写点代码。
可以方便阅读和维护。
请求定义很麻烦
那么问题来了，传入一个字符串还好自定，如果是一个对象呢，对象有 A，B，C，D 太多的属性，一碰到传入参数很多的对象就特别麻烦。
比如一个我发出去一个请求，突然间给我返回20个属性，每次用请求结果，经常各种提示没有 C属性D属性，于是就想了一个办法，写any这总该好了吧。
传入参数一般都是3-7个左右，每次都要另起一个文件专门定义参数传递类型，然后饮用，本来我自己想传递什么好好的，结果我要定义一大堆的类型。
每次对于请求回来的数据结果还要再次引入该类型，循环嵌套。
我真的谢谢你。
还有react我要特地引用react自己定义好的ts类型，我真的谢谢你。
interface AppProps {
value?: string;
}

const App: React.FC = ({ value = '', children }) => {
// ...
};
interface AppProps {
value?: string;
children?: React.ReactNode; // 自己定义children的类型
}
function App({ value = "", children }: AppProps) {
return <>{children}</>;
}
除了记住ts，还要记住react本身自己提供的类型，真的一带上或者 : AppProps 之类的语句我就感觉阅读速度一下子慢了很多，你拒绝ts还不行，还要被迫写ts。
npm/yarn/pnpm
是用npm还是用yarn，yarn觉得npm写的不够好，于是开发了yarn，而npm又不断的改进自己，把yarn 的优点又学习了，所以整体用起来我们开发起来真的不觉得哪个更好。唯一的不够好的地方就是每次npm启不来，就用yarn起，yarn起不来就换npm。
pnpm又觉得 npm和yarn 的包的管理方式不好，你们好重复，自己加了软链，于是下载速度快了好多。
那么我们就npm更换成pnpm，然后还要解决一大堆问题。
听我说谢谢你。
babel/esbuild(go)/swc(rust)/bun(zip)
因为有了vue，react这样的不被浏览器识别的语法，就需要编译，编译就是把react语法换成纯粹的js，
babel就出场了，各种分割比如， 通过正则把 let a =1 给你拆了，这就是所谓的AST，拆了就要再组合起来，比如你要拆vue就要引入 vue-loader，拆scss 就要scss -loader。
但是这个速度真是太慢了。node不如go，rust这种语法快，至于什么原因，有人说单线程，想要了解更多就要问哪个造语言的人。
每种语言语法都差不多，差的多的是这个语言本身的优缺点。
于是一个叫 Evan Wallace 的人在开发figma的过程中，通过go语言写出esbuild，做的就是编译，但是还不够稳定，于是就在本地开发用，真是快了10倍。
一位韩国精神小伙donny，大学期间一直在写swc，参考了很多babel代码，写了swc。
于是就要比较esbuild和swc有什么区别。esbuild想做打包，swc想做编译对标的是babel
zip又是一个小众的语言，bun 对标 Node 和 Deno，从 2021 年 4 月初始提交至今已有超过百万行的代码增删量，单人完成了 98% 以上的提交量，一个评价卷王。
rust 在 node 中的应用
因为 rust比node快，于是就有neon和napi-rs的出现
Next/Nuxt/Remix
服务端渲染，以前前后的混淆在一起，php直接和前端（特别原始写法）一起部署。前端分离之后，我们开始用起来react和vue angular，前端想做服务端渲染就要node去请求服务再和原本的react和vue再渲染， 听我说谢谢你。
webpack/rollup/vite
vite 使用原生的 esm本地开发配合esbuild速度更快

scss/sass/tailwind
$font-stack: Helvetica, sans-serif;
$primary-color: #333;body {font: 100% $font-stack;color: $primary-color;
}

提供一种新的写法可能

结语
听我说谢谢你，因为有你温暖了四季我依然是写业务的前端工程师，真的不知道技术是不是为了业务服务。为了解决一个问题，提出一个方案，又不断的去优化这个方案的缺点，比如不能解决原本很容易解决的问题，感谢这百家争鸣的开源时代。

参考
https://mp.weixin.qq.com/s/Q3o0ryTs3g24s0Te1MFqRw

我做前端的那些事儿

工作流程
产品经理PM-UI设计-前端FrontEnd-后端Server-测试QA

1. 产品提出需求
   一起开大会讨论，看看需求有什么不合理的地方，是否符合逻辑不符合代码逻辑，内容太多是否可以分批开发，可以向pm提出体验功能不好的地方。核心目标就是自己好开发，用户体验好。
2. UI设计
   设计出稿子，向UI设计确认是否定稿了，免得重复写代码，你也可以和设计师问一问，这个样式能不能换成通用的组件，方便你更好开发，比如设计师搞了两个弹窗，但是样式不统一，你可以向设计提出能否统一样式等等。要好切图gif动态图资源等，自己无法切图的还可以多交流。
   验收一般都是提测后，主动和设计说走查UI样式，免得影响上线。修改样式问题，不要撕逼，有的设计要求比较严格1像素都不行，这种就和设计好好商量。这个还会涉及到各个机型，安卓IOS，网页等不同的机型，基本看几个主流的就可以。
3. 后端Server
   这个是最好打交道的职位，基本就是给一个文档定义接口，想要什么格式可以让后端返回数据。
   注意有问题一定做好区分，是前端问题还是接口问题。有的数据样式比较少无法覆盖很多case让他们多返回，不稳定的接口多反馈。
4. 测试QA
   会有个测试会，和你对清楚什么功能，你哪个功能完成了就打勾，自测 100% 再提交，不要给测试找太多麻烦。 有的公司会有什么bug 率，一个项目 bug 太多，小心被他们穿小鞋。
   基本跟他们打交道是最麻烦的，此时经常测试产品UI来回讨论，更改是最多的，有可能这个时候会更改需求，也可能UI设计也会改，有提前思考不周到的地方，经常来回修改。甚至在你开发的过程中发现问题都可能来回讨论修改需求。
   前端开发
   一致性原则
   参考同事开发的代码，尽量保持一致性，就算你觉得那样不好，你也要这样写。大家都用一个库，你最好也用这个库。
   和设计对清楚细节
   先开发样式-自己多测几个机型，各个浏览器。注意问清设计哪个是可以适配的，哪个是固定长度等。
   用什么字体，动效如何。
   注意后端返回错误
   对接接口，多注意错误兜底，多catch不要then了之后从来都不捕捉错误，对于后端返回的数据我们不能全信，A对象上可能没有B属性就会导致错误。
   体验性能
   很多人更在乎首屏的加载速度，请求延迟后loading，不会在乎你的代码本身性能，比如重复react渲染了3次。
   代码的优雅可读性
   看公司preview有的有，有的没有，就算有，好多都是一个形式。
   这个不属于产品的验收结果，甚至领导都不太关心这个，他们更在乎线上有什么问题。
   作为一个合格的程序员，希望你尽量保持代码的可读性，不要摆烂，维护项目的人会谢谢你。
   上线后找问题
   某用户反馈出现问题，最好要做好错误的打点上传，真的方便太多。
   关于工资
   有的人觉得公司给我工资给低了怎么办，找领导说能不能涨，不要不好意思，你觉得你比周围人低就说，你觉得你应该比别人高你也可以提出来，不要憋着，员工要求涨工资不丢人。
   晋升
   说说怎样晋升，不要维护旧项目，一定要找新的，没有也要给卷出新的来，这就是潜规则。
   新的永远都比维护旧的的项目更有加分空间。
   你项目管理好，进度不延期，测试提出bug少，UI设计还原的好，和产品提出问题提的好，和同事技术交流好，最好找几个新的看着比较困难的项目，更是加分项，每天不要第一个下班，多写文档多分享，再和领导多说话，不要怕领导，不晋升你晋升谁。你技术本身增长一定是最不值得投入了，但是恰恰这个是最重要的，然而他们无法分辨，毕竟谁来也能干活，但是你干的又好又快又多，要从表面做功夫。
   多和公司理念契合，就算不认同也要契合。
   如果这些你这些都卷了，工作了两年都不晋升你，那你赶紧跳槽。
   工作内容
   这好几年，都是在这样的重复循环中，大公司可能要忙一点，多个项目来回穿插，也有休息的时候，整体感觉就是一个搬砖的，不会有技术提高，其实技术提高是个伪命题，技术就那么些，主要还是最新的技术，只要多开拓视野多引入新库基本就被他们认为技术提高。
   吐糟
   前端和前端其实差别很大，有人前端天天维护业务项目，有人在大公司里维护前端基础项目，比如写antd 这样的库，有人开发叫 vue 的框架，他们都是做前端的。
   看你自己的追求，做一个维护业务的前端工程师也挺好的，大家加油工作，天天向上，升职加薪不是梦。