暂时未有相关云产品技术能力~
暂无个人介绍
哈喽,我是树酱。本期分享一些私货~ 这些工具可以给让你随时随地,效率拉满。再也不用担心使用场景的限制 🖖
哈喽,我是树酱。之前搭建的微前端体系已经稳步运行将近两年了,最近遇到一些童鞋反馈。之前据说qiankun并不支持Vite打包的应用,那是不是我就无法使用了?
哈喽,我是树酱。之前搭建的微前端体系已经稳步运行将近两年了,最近遇到一些童鞋反馈。之前据说qiankun并不支持Vite打包的应用,那是不是我就无法使用了?
前言:日常开发中,好的工具往往能让我们事半功倍,有句老话说得好:工欲善其事,必先利其器。使用高效率的工具可以极大提升我们的开发效率。接下来分享下树酱平时开发中经常使用的一些效率工具
哈喽,我是树酱。最近业务功能需求开发中Web端需要接入人脸识别,于是做了技术预演。可能你会问:不是蛮多云服务商开放这方面的接口支持,直接用不香吗?还要自己造轮子多费劲呀。 是的,我也调研了不少解决方案,但是人家是要收费的呀(而且费用不低)或者甲方不买单~“卑微前端开发”
哈喽,我是🌲 树酱。今天聊一聊关于我跟Json schema的一些交集,顺便给大家重新梳理下今日这个主角的概念及当下主要的一些应用场景
哈喽,我是树酱。去年中旬的时候写过一篇关于如何更好管理 Api 接口。最近有朋友问我,我们都是根据Swagger文档,然后通过“阅读”swagger文档中每个微服务包含的CRUD(增刪查改)等API,再通过“手动”撸出各种service文件,以此达到封装的结果。但是这样会暴露一些问题,如下👇
前沿:哈喽,我是树酱。今天分享的水文是关于前端与后端之间battle的那些事,自从前后端分离之后,这场分家带来了不少沟通问题,甚至产生battle。我们先回顾下前后端battle的前世今生
前言:哈喽,我是树酱。文章的源头,是因为在一次交谈中,朋友提到一个需求。需要一批邮箱去做一些"事情",具体是干啥事,留点悬念。如果手动去注册邮箱,只需要解决接收邮件问题。不仅费力而且现在包括像@163等邮箱都还需要手机验证。手动不行,那我们就自己"造"邮箱。一开始觉得挺复杂,毕竟作为一名前端工程师,这个“需求”已经超纲了。问题不大莫慌,看完这篇你就可以打造自己的域名邮箱了
前言:哈喽,我是树酱。先聊聊本文的起源,某天在水群的时候看到某大佬的Github账户主页,颜值简直爆棚。反观看树酱的Github主页,简直就是“陋室”,难以入眼!或者很多开发的小伙伴跟我一样,平时在github上参与开源少了,可能操作最多的无非就是fork与star,就不会考虑花时间去打理。其实github主页也是我们另一种名片的呈现方式,更好的展示可以给她留下一个好的印象
前言:最近有种感觉,好像微前端成为当下前端工程师的标配,从single-spa到qiankun,各种微前端架构解决方案层出不穷。那一夜,我在翻阅github时,留意到一个新的微前端框架,来自京东零售开源的MicroApp,号称无需像上面提到那两个框架一样需要对子应用的渲染逻辑调整,甚至还不用修改webpack配置。还有一个成功引起我注意的是:它把web-components的概念给用上了!让我们一探究竟!
前言: 工作生活中,我们总会离不开的“动作” 就是:规划 + 记录, 规划可以帮助我们更好地将我们下一个周期想要完成的事情做一个时间维度的拆分,并提前计划好相关事项。而记录则是可以帮我们收录碎片化接收的信息或者临时的idea~,再通过文字或图片的形式存起来。在互联网时代。我们每个人接触的信息量很大而且大部分信息是琐碎的,甚至随着信息分类多,还需要给信息打个tag标签。而此时我们会有选择性的选择我们想记录的信息,那有没有工具能够更好的记录?
前言:我们运用微前端架构解决了应用体积庞大的问题,通过实践微前端的理念,将前端应用拆分为多个微应用(可独立部署、松散耦合的应用)。同时微应用的存在,使得我们无需在构建一个庞大的应用,而是按需构建,极大了加快了构建效率。但只是解决了应用层面的问题,在中后台应用场景中,不同微应用和基座之间可能存在通用的模块依赖,那么如果应用间可以实现模块共享,那么可以大大优化单应体积大小
前言:我们运用微前端架构解决了应用体积庞大的问题,通过实践微前端的理念,将前端应用拆分为多个微应用(可独立部署、松散耦合的应用)。同时微应用的存在,使得我们无需在构建一个庞大的应用,而是按需构建,极大了加快了构建效率。但只是解决了应用层面的问题,在中后台应用场景中,不同微应用和基座之间可能存在通用的模块依赖,那么如果应用间可以实现模块共享,那么可以大大优化单应体积大小
前言:前端时间分享了这些node开源工具你值得拥有(上) 主要围绕git、npm、命令行工具、加解密工具、数据校验、文档生成工具等方面。通过现成的轮子来提升我们的开发效率,来解决在不同场景应用中遇到的一些问题
前言:前段时间开始落地基于vue3开发的应用,于是在社区留意vue3周边的一些开源项目。无意间看到微众银行WeBankFinTech团队开源的 Fes.js解决方案。在这个方案的设计思路中,快速上手、简单易用、拓展性高这几个特征引起我对项目的进一步探索
前言:文章的灵感来源于,社群中某大佬分享一个自己耗时数月维护的github项目 awesome-nodejs 。或许你跟我一样会有一个疑惑,github上其实已经有个同类型的awesome-nodejs库且还高达41k⭐,重新维护一个新的意义何在? 当你深入对比后,本质上还是有差别的,一个是分类体系粒度更细,其次是对中文更友好的翻译维护,也包括了对国内一些优秀的开源库的收录。最后我个人认为通过自己梳理,也能更好地做复盘和总结
前言:eslint我们常应用在代码静态扫描中,通过设定的eslint的语法规则,来对代码进行检查,通过规则来约束代码的风格,以此来提高代码的健壮性,避免因为代码不规范导致应用出现bug的可能。而规则是自由的,你可以设定内部自己团队适用的规则,也可以直接使用开源社区比较热门的规则集合, 比如airbnb、eslint-plugin-vue等
前言:这是一篇迟到的下集,上次分享了如何从0到1搭建一个可视化数据大屏,介绍了数据搭配的前期调研、控件区域的开发、画布模块的开发等等。上篇的链接点我👉 从0到1开发可视化数据大屏(上) 而下集主要围绕.控件管理模块、数据管理模块、图层管理模块这几个模块来介绍。
前沿:哈喽大家好,我是树酱🌲,好久不见。本文主要为了做复盘,在去年基于qiankun微前端架构的门户建设中,遇到的一些问题,可能你会认为:“哇,这也算问题吗?太简单了吧”。主要是分享在我认知体系内是如何解决的,如果对其中一些解决方案有更好的建议,记得在评论区留言~
前沿:哈喽大家好,我是树酱🌲,好久不见。本文主要为了做复盘,在去年基于qiankun微前端架构的门户建设中,遇到的一些问题,可能你会认为:“哇,这也算问题吗?太简单了吧”。主要是分享在我认知体系内是如何解决的,如果对其中一些解决方案有更好的建议,记得在评论区留言~
前沿:一个流程图设计器需要什么?一个是图的绘制能力、基于svg或者canvas来绘制各种形状的节点(矩形、圆形、多边形)以及线,一个是图与图之间的交互包括拖拽,节点之间的连线等,最后是画布面板的便捷性,其中包括:比如ps中的网格功能、对其线、步骤回撤、画布的可伸缩、快捷按钮等等,那前端社区有啥开源解决方案,方便我们快速开发一个属于自己的流程图设计器?
前沿: 聊起css,印象最深刻的就是刚毕业那会刚开始从事前端开发岗位工作的时候,身为一名 cut picture boy (切图仔),在页面布局及还原设计图中广泛使用css来开发页面,我记得刚开始接触最多的就是Bootstrap(用于开发响应式布局、移动设备优先的 WEB)。然而随着前端突飞猛进的编进,诸如element,ant design等优秀的ui库出现,在对比中感到审美疲劳。言归正传,css近年来了也催生了蛮多新的解决方案,比如 CSS Modules、styled-components(css in js )、Functional CSS、CSS 原子类、CSS沙盒等等
前言:大数据时代,以大屏为载体的数据可视化需求日渐增多,数据大屏成为越来越多企业绩效展示,报表展示,业务监控等等的一种形式,大屏的上线带来的是便捷,无需编码,用户可以直接将所要呈现的组件拖拽到画布上,然后进行随意配置和布局,所见及所得。前段时间我们上线了内部的自己的可视化数据大屏beta版本
前沿:跨域是一个老生常谈的话题,树酱在github上无意间看到cors-anywhere这个开源库,加上最近身边有一些实习童鞋在本地开发环境中提出疑惑🤔,本地开发是如何解决跨域问题的?结合以上,也就有了今天的主题,前端跨域解决方案那些事。跨域解决方案比较多,🌲酱君把平时接触比较多的share一下
前沿:我所理解的门户Portal就是一个入口, 可快速整合应用入口,用来统一账号管理、统一认证登录,打破信息孤岛等,做统一的权限管理,也可以实现单点登录 SSO。早期的MVC时代,web应用其实就有通过权限去控制页面、菜单、按钮等的显示和隐藏,只不过呈现方式不同,大多以php和jsp等为主,随着前后端分离后,前端也成了权限控制的扛把子,主要是从以下这几个角度去实现,路由层面、视图层面以及接口层面
前沿:有玩过qiankun的童鞋都知道,若想保证qiankun父应用能够成功正常加载子应用。我们需要“包装好”子应用,在官方文档中可以看到对子应用的打包方式中,就是通过将webpack的输出模式定位为 UMD 。你可以能好奇,这个UMD是个什么玩意?
前沿:文章的起源在于开发环境中使用qiankun框架,父应用加载子应用遇到一则报错 Failed to load module script: The server responded with a non-JavaScript MIME type of "text/html". Strict MIME type checking is enforced for module scripts per HTML spec 直接的翻译意思就是加载模块脚本失败:服务器以非JavaScript MIME类型“text/html”去响应。而也是这个问题引发了我的思考,到底是什么问题导致?
前沿:最近有需求开始接触数据可视化的开发,前期调研和体验了国内几家比较大的数据可视化解决方案提供商,并对开发中会涉及到一些工具做了筛选,经常在社区看到有小伙伴反馈相关方面的需求,于是借此机会把我整理的一些工具分享出来,后期开发完成再针对整个过程中的心得体会进行分享
前沿:朋友们,你还在手动“丢包”吗?机械化搬运工当得不是滋味吧?想不想学习自动化流水线构建~如果想,这篇适合你,结合CICD来自动化构建前端项目,本文树酱🌲主要介绍如何基于jenkins和travis的基础上让 CI/CD 跑起来,解放你的双手👋,从此告别996
前沿:文章起源在于,朋友跟树酱说在解决项目兼容IE11浏览器过程中,遇到“眼花缭乱”的babel配置和插件等,傻傻分不清配置间的区别、以及不了解如何引用babel插件才能让性能更佳,如果你也有这方面的疑虑,这篇文章可能适合你
前沿:这周慢更了,但树酱还是来了,上周分享了他关于前端的知识体系构建上篇传送门,主要包括Vue、Node、前端工程化模块、性能优化等四大模块,这篇主要跟你聊聊关于安全、设计模式、微前端等方面的知识体系构建
前沿:先预祝掘金升级成功... 树酱君是个渣渣,梳理了下发现还是蛮多知识点不够扎实,童鞋有机会也定期给自己做个复盘和回顾,梳理自己的知识体系。再加上前端娱乐圈变化多端,以至于我们既要加强对底层基础知识的巩固,查漏补缺,也要保持对新事物探索的好奇心。那树酱我是如何构建自己的知识体系呢?(特别算法是硬伤啊)⏰ 该本章为上下两章,本次分享是上章
前沿:前半年微前端火得一踏糊涂,刚好业务需求上有这样的应用场景,针对目前的微前端解决方案做了技术选型,qiankun作为蚂蚁金服内部孵化出来的微前端解决方案,经过线上应用充分检验及打磨最后开源,最终选择qiankun作为我们云产品架构入口。不过官方文档上关于上线部署文档较少,很多童鞋也可能只是在本地玩玩,没有到真正走通整个闭环,于是结合自身,在将qiankun落地过程中遇到的“那些坑”做个梳理。希望对你有所帮助
前沿:这几年,前端的组件库的演变迅速,社区脱颖而出不少优秀的开源组件库,包括element-ui、Ant design、IView等等,这些开源组件库源码中其实有很多值得我们学习的地方,无论是设计思路,代码风格等等,可以通过参考源码中一些写法,引用到我们平时的项目中去
前沿:这几年,前端的组件库的演变迅速,社区脱颖而出不少优秀的开源组件库,包括element-ui、Ant design、IView等等,这些开源组件库源码中其实有很多值得我们学习的地方,无论是设计思路,代码风格等等,可以通过参考源码中一些写法,引用到我们平时的项目中去。
前沿:续上次面试官问你关于node的那些事基础篇发出,童鞋反馈说“怎么那么基础啊,这也太水了吧” 这里统一做回复,不基础咋叫“基础篇”呢,因为树酱也不是什么大神,渣渣来着,只是通过自己的角度,希望能帮助大家更好地去学习,于是就有了进阶篇的梳理计划,今天树酱继续跟你聊聊关于node后续的那些事,附上 面试官问你关于node的那些事(普通篇)
前沿:文章的起源,是树酱的朋友在最近面试中对部分岗位中对node掌握程度要求感到很“慌 ”,当然node已渐渐从很多公司招聘的“加分项”转变为“强指标”,“慌”的原因无非是因为平时项目无需用到或者说少用node,再加上我们的知识吸收,大多都是碎片化的知识拼接起来,缺少一个完整体系化的梳理,借此机会,重新梳理一下,当然更多的还需要你参与实战,本文是基础篇。
前沿:前段时间在公司内部分享了关于bff和serverless的知识体会,从概念、特征、和应用场景再到简单的实践,今天借此机会跟大家分享,什么是BFF? 什么是serverless?
前沿:在掘金写作不知不觉已经过了四个月了,从一开始寥寥无几的阅读量,到现在有破万阅读的文章,感谢曾支持我的掘金友,希望在未来能加深产出文章的深度,今天从借此机会跟大家分享下树酱日常工作中常用的一些工具,或许可以帮到你提升日常的协作效率
前沿:中后台应用中表单需求颇多,左手一个表单,右手又是一个表单,无穷无尽,如果用模版一个个来写,不单写起来费时费力,而且看起来也是天花乱坠,于是这个时候你会去设想,那有没有什么方式可以去替换琐碎的手写表单模版的方式呢?让表单是“配出来”的,而不是撸出来的,让你轻松解决 form 表单,也不再为表单而烦恼。答案就是:动态表单
前沿:按需加载是性能优化其中的一个环节,可以是图片的按需加载,也就是lazyload来实现按需加载的场景,也可以是组件库的引入,只需部分组件的使用而无需全局引入整个组件库的场景,又可以是路由的按需加载,当路由被访问的时候才加载对应组件的场景,以此来实现更高效率的使用等等,本文把“懒加载”也划分为按需加载
前沿:自从前端和后端分家之后,前后端接口对接就成为了家常,“谁”也离不开谁,而对接接口的过程就离不开接口文档,比较主流就是Swagger(强大的API文档工具),当然今天它不是主角,顶多也就是个辅助。这篇文章旨在梳理如何在前端项目中更好的去管理跟后端“对接”的接口
日常开发中,我们使用到的Js定义的每一个值都属于某一种数据类型,常见的js数据类型有String(字符串)、Number(数字)、Boolean(布尔)、Object、Undefined、Null、Symbol等等,其中Symbol是ES6引入的新的数据类型,表示独一无二的数值。因为 JS 本身是一门弱类型语言,以至于类型转换发生的频繁很高,本文旨在帮助大家梳理各种类型之间的相互转换,在每一小节讲解转换前,还会跟大家介绍这些“老朋友”
前言:这段时间一直在搞to B方向中后台的项目,表单接触的频率会比较多,就突发奇想聊聊表单数据相关的一些基础分享
上一篇树酱讲《前端工程化那些事》,聊到脚手架,不过时间比较仓促,导致内容较少,而在我实践开发中,随着新项目愈来愈多,脚手架工具就起到提高效能的作用,借此机会跟小伙伴们分享下我是如何从0到1开发一个简单脚手架
什么是前端工程化?本质上就是将前端开发流程,标准化、规范化、工具化、自动化、简单化。通过规范和工具来提高前端应用质量及开发效率
在日常开发中,特别是中后台管理页面,会经常使用到一些常用的函数比如:防抖节流、本地存储相关、时间格式化等,但是随着项目不断增加,复用性和通用性就成为一个很至关重要的问题,如何减少复制张贴的操作,那就是封装成为,适用与多项目统一的工具包,并用npm进行管理,“U盘式安装”的方式可以提高团队的效率,那今天就讲讲开发一个简易的工具库需要涉及哪些环节
谈到路由,一般分为前端路由和后端路由两种,后端路由指的当用户通过浏览器切换不同URL时,都会向服务器发起资源请求,服务器通过后端路由匹配之后根据不同URL返回不同页面,而前端路由则将浏览器与服务器交互(页面跳转的URL规则匹配)的任务交给前端来做
聊到运维,很长一段时间我觉得跟前端就是毫无关联的玩意,应该说半毛钱关系都木。但随着前端工程化的发展,前端基本运维部署相关知识甚至也逐步被重视,如果你公司的运维部门很强大,那么你也可以完全忽略运维相关的。只是树酱觉得,如果你想更多了解前端架构,还是需要具备一定的运维相关知识储备。当然,现在云厂商都想应推出自己的Serverless服务(下一篇会讲~),号称让前端更专注业务的开发,而不用担心底层应用的部署和维护,对开发者而言可以更多聚焦到业务领域的开发,有兴趣的童鞋可以去玩玩