muwoo
## 前言 当业务代码发布到线上的时候，突然报了某一个机型白屏或者某个功能无法使用的时候，这种场景我们最需要的就是能知道究竟是代码哪里出错了。常见的手段是通过 `vconsole` 注入到我们的代码中，然后再找一下对应机型，进行功能调试。但是往往影响功能的兼容性不仅仅跟机型有关，有可能和系统版本，客户端版本等等综合因素。也就是说别人报错，你的相同机型不一定会报错，这种情况可能就又得找到当事人的手机来再注入`vconsole`来复现问题。 但 `vconsole` 终究是需要注入到代码里面的，如果想不注入代码里，可以通过 Charles 做请求劫持，给页面再插入 `vconsole` 的地址，让页面来加载，从而达到在用户手机远程查看的目的。但 `vconsole` 在有限的屏幕上去做展示，整体体验不是很好。其次 `vconsole` 也并没有达到远程调试的目的。接下来我们将尝试借助于 `rubick` 的能力来实现一个桌面端真正意义上的远程调试工具。 先直接上代码： [rubick 工具箱](https://github.com/clouDr-f2e/rubick) [远程调试 rubick 插件](https://github.com/clouDr-f2e/rubick-network/blob/master/README.md) ## 动手实现 ### 基于 Chrome devtools...
可视化编辑区实现
# 可视化编辑区实现 前面几个小节的介绍可能大家没有直观的感觉到跟可视化搭建的具体联系，因为还没有涉及到编辑这一块的内容。本小节开始，我们就可以开始设计编辑器的相关工作啦！ ## 初始化项目 编辑器我们采用的是基于 `vue3` 来的，为啥不是 `react` 或者 `vue 2.x`，纯属个人喜好，别无他意。当然用什么框架不是重点，重点是只要我们掌握了思想就可以“为所欲为”。好了，先初始化 `vue3` 项目，对于 `Vue 3`，你应该使用 `npm` 上可用的 `Vue CLI v4.5` 作为 `@vue/cli@next`。 ``` npm install -g @vue/cli@next vue create...
## 后端路由简介 路由这个概念最先是后端出现的。在以前用模板引擎开发页面时，经常会看到这样 ``` sh http://www.xxx.com/login ``` 大致流程可以看成这样： 1. 浏览器发出请求 2. 服务器监听到80端口（或443）有请求过来，并解析url路径 3. 根据服务器的路由配置，返回相应信息（可以是 html 字串，也可以是 json 数据，图片等） 4. 浏览器根据数据包的 Content-Type 来决定如何解析数据 简单来说路由就是用来跟后端服务器进行交互的一种方式，通过不同的路径，来请求不同的资源，请求不同的页面是路由的其中一种功能。 ## 前端路由 #### 1. hash 模式 随着...
## 前言 为了进一步提高开发工作效率，最近我们基于 `electron` 开发了一款媲美 `uTools` 的开源工具箱 [rubick](https://github.com/clouDr-f2e/rubick)。该工具箱不仅仅开源，最重要的是可以使用 `uTools` 生态内所有开源插件！这将是巨大的能力，意味着 `uTools` 生态内所有插件可以无差异化使用到 [rubick](https://github.com/clouDr-f2e/rubick) 中。 设计交互上为了更能提高用户的使用效率，我们又尝试去实现了 `uTools` 中非常优秀的一些设计，比如：**超级面板**。该功能可以通过鼠标快速唤起`uTools` 插件能力，而不用再打开应用。比如上传图片，只要我们安装了图床插件，那么当鼠标选择桌面上某张图片时，即可快速呼出上传图片的菜单选项，方便省事。接下来一起看看实现方式吧！ ### 代码仓库 [Rubick github](https://github.com/clouDr-f2e/rubick) ### 功能截图： #### 文件夹下长按右建 #### 选择文件后长按右键 #### 选择文字后长按右键...
## 故事背景 之前在网上有看到很多小伙伴基于 `electron` 实现了非常多好用的桌面端工具，比如图床管理工具 [PicGo](https://picgo.github.io/PicGo-Doc/zh/guide/#%E4%B8%8B%E8%BD%BD%E5%AE%89%E8%A3%85)，就专门做图床工具。也有一些其他的类似的小工具，比如 [saladict-desktop](https://github.com/zenghongtu/saladict-desktop) 专门做沙拉翻译查词的桌面端应用，[colorpicker](https://github.com/Toinane/colorpicker) 专做桌面端取色工具... 我们也参考了这些小工具的设计理念，尝试在公司内部做一款桌面端工具，解决网络抓包、代理、图床、性能测评等常见场景的使用问题。最后在推广的时候，遇到了一个比较严重的问题，就是很多小工具对特定用户来说并不需要。比如测试只需要使用网络抓包、代理的功能，其他功能并不关心。此时就需要设计一款桌面端应用，类似于 `App Store` 那样，用到什么下载安装什么即可。这就需要实现桌面端应用的插件化。 于是乎，我们看到了 [uTools](https://u.tools/docs/guide/about-uTools.html) 是支持插件化的桌面端应用，但是前提是我们的插件必须发布到 `uTools` 插件市场，才能实现多端同步下载的功能，但是公司内部的工具库有些涉及到安全信息又无法发布到 `uTools` 插件中，所以我们特别渴望有一款类似于 `uTools` 的内部工具箱。 为了进一步提高开发工作效率，最近我们基于 electron 开发了一款媲美 uTools 的开源工具箱 rubick。该工具箱不仅仅开源，最重要的是可以使用 uTools 生态内所有开源插件！这将是巨大的能力，意味着...
## 背景 经常我们要去看一些页面所发出的请求时，经常会用到 Charles 做为抓包工具来进行接口抓取，但一方面市面是很多抓包工具都是收费或者无法二次开发的。当前我们团队大多数用的也都是 Charles，但是对于一般新手来说，单纯想抓个包或者修改和接口返回数据，直接上手 Charles 不管配置成本和学习成本都相对较高。所以我们有必要自己按照自己最爽的状态来撸一个适合自己的抓包工具。 ## 结果 基于以上诉求，我们自己重新设计并修改了交互，搞了一个符合我们诉求，使用简单的桌面端抓包工具。本身这个插件是可以集成到 `utools` 里面的，但是由于很多涉及到内部的功能，我们没法通过 utools 进行发布，所以我们自己做了一个可以使用 utools 所有生态的工具箱 `Rubick`。此次抓包工具也是基于 `Rubick` 的插件工具。 试玩地址： Rubick: https://github.com/clouDr-f2e/rubick 抓包插件：https://github.com/clouDr-f2e/rubick-network 这次我们先不看代码，直接来看我们实现的抓包工具的效果： ### 支持HTTP/HTTPS请求抓取。  ### 支持接口mock...
前言
# 前言：可视化搭建诞生背景 ## 关于我 笔者曾经在 51信用卡从0到1设计实现过一套基于 h5 活动的可视化搭建体系，半年上线了近 1000 + 活动页。后面去了 蚂蚁集团 接触到了内部使用的 凤蝶 可视化搭建体系，让我对可视化搭建有了一起额外的认知。现在也是在当前公司负责可视化搭建这块的内容，可以说在 H5 可视化搭建领域，自己也是有一点摸爬滚打的经验，可以给大家分享，如果这个专题可以给你们带来一些灵感或者规避掉一些问题，那这个专题的目的就达到了。 ## 什么是可视化搭建 可视化搭建字面意思就是通过 `GUI` 可视化交互搭建出之前通过代码开发出来的界面，可视化搭建并不是一个新词，如果之前接触过安卓开发的同学应该有用过 `Android Studio`，其便是一款支持可视化拖拉生成代码的开发工具：  当然，前端在很早之前也有很多可以搭建页面的 `GUI` 工具，比如...
# Vue 3.x Form render  [github: vue form render](https://github.com/muwoo/vue-form-render) [在线演示](https://muwoo.github.io/vue-form-render) ## 为什么要造这个轮子？ 之前用过 React 的 Form Render 的小伙伴应该比较清楚 Form Render 可以基于 JSON Schema 快速构建出表单区块。不得不说 For Render 在以下场景中的使用会给开发带来巨大的便利： 1. 规范化表单视图的快速生成：写好对应的参数配置，快速生成一个标准表单，省去了使用类...
## 前言 前不久，我刚刚入职了蚂蚁金服，由于自己一直对蚂蚁技术的向往，所以这次也算是如愿以偿啦。如果看到本文的你也想着来大厂历练一下，欢迎简历砸到：[email protected] ## 简单的随笔一下吧 其实我也不知道说些什么，我就简单的谈谈自己对前端的认识和自己的成长的过程吧。15年的时候，我刚毕业，自己本身毕业的时候也不是专门做前端的，当时做的是Android、Java之类的，因为当时对偏向于界面交互的东西感兴趣，所以选择了前端这个行业，因为自己对编程语言有点底子，所以相对来说，入门前端并不是很难。但是入门和掌握是两码事。 当时我在一个普通的公司做前端开发，也负责做一些架构和前端技术选型的事情，当时深刻感觉到自己的瓶颈带来的问题，在知乎上我还特地回答了一下这样一个问题：[大公司和小公司的程序员差别在哪？](https://www.zhihu.com/question/20397229/answer/301045417)当时自己的理解大致是这样的： >个人亲身体会，有三个方面吧：眼界，眼界，眼界。就跟当年高考选择学校差不多，更多人愿意去大城市的院校，而不愿意待在3-5线城市一样。我之前就在一个类似于作坊型的公司待过，前端4-5个人，当时算是顶配了。但是会发现在做业务的过程中，总是会遇到各种奇怪难以解决的坑，而这些坑需要花费团队很大的精力去处理。而且，还不一定能解决掉，就算解决了，也有可能是最笨的方法。但是这些问题，可能在大公司内存在着一整套完整的体系结构，一整套已经成熟的解决方案。其次，小公司内可能只存在一个诸葛亮，什么事情都是由这个人和大家商讨决定，当然，这个诸葛亮的天花板，决定着整个团队的天花板。但是大公司内，存在着各式各样的诸葛亮，所谓术业有专攻！大家在不同领域，不同层级，发挥着自己独特的优势和价值，从中只要你愿意去学，能学到很多有用的知识！当然，小公司也有自身的优势，百废待兴。所以，如果你有信心让这个公司兴起来，那么你就是王者。 所以当时的自己深深被这种眼界的问题困扰，就是自己做的东西，遇到了自己解决不了的问题。可能是自己的一开始设计就错了，可能是哪一个环节错了。这种排查问题的过程给我带来了很大的困扰。所以后面我选择去了大搜车。在大搜车我也主要是带着很多疑问去的，在里面我学习到了很多知识，很多很多。自己之前想了很久的问题在这里慢慢被解开。 然后对自己帮助很大的就是社区了，因为有时候自己喜欢这种解决难题带来的成就感，而这种成就感想分享到社区，一方面可以帮助到和我遇到同样问题的人，另一方面也可以得到别人的认可，或者说别人有更好的方案，可以一起探讨出更优秀的解决方法。所以后面我每次学习成长，我都会通过知乎、掘金、Github等渠道进行分享。期间我结识了很多优秀的小伙伴，我们一起有一些沟通和交流，感觉这个也是我能力提升的很大一个因素。 最后还是不断地思考吧，我相信我们作为程序员，肯定是热爱这个行业，而不仅仅是为了工作。有的时候遇到问题或者好的解决方案，我们应该多想为什么这么做，他是怎么实现的，这么实现的好处，有没有更简洁的办法实现。之前看了很多优秀的大神的源码设计，然后我发现我在写代码的过程中开始模仿他们了，很多设计模式或者说是代码的整洁组织规范，都可以得到很大的提升。 ## 最后 最后吧，我还是挺喜欢这样一句话的：首先我需要是一个程序员，其次我才是前端工程师。欢迎共勉！！最后再说一下：蚂蚁金服招前端，base杭州。有兴趣的可以投投简历，就算没兴趣，交个朋友也好。
## 前言 如果你经常接触一些公司的活动页，可能会经常头疼以下问题：这些项目周期短，需求频繁，迭代快，技术要求不高，成长空间也小。但是我们还是马不停蹄的赶着产品提来的一个个需求，随着公司规模的增加，我们不可能无限制的增加人手不断地重复着这些活动。这里我就不具体介绍一些有的没的的一些概念了，因为要介绍的概念实在太多了，作为一个前端的我们，直接上代码撸就好了！！！！ 想要了解更多，也欢迎访问： [源地址](https://github.com/muwoo/blogs/issues/36) [blogs](https://github.com/muwoo/blogs) ## 目标 我们的目标是实现一个页面制作后台，在后台中我们可以对页面进行 `组件选择 --> 布局样式调整 --> 发布上线 --> 编辑修改`这样的流程操作。 ## 架构设计 首先是要能提供组件给用户进行选择，那么我们需要一个`组件库`，然后需要对选择的组件进行布局样式调整，所以我们需要一个`页面编辑后台`接着我们需要将编辑产出的数据渲染成真实的页面，所以我们需要一个`node服务`和用于填充的`template 模板`。发布上线，这个直接对接各个公司内部的发布系统就好了，这里我们不做过多阐述。最后的编辑修改功能也就是针对配置的修改，所以我们需要一个数据库，这里我选择的是用了`mysql`。当然你也可以顺便做做权限管理，页面管理....等等之类的活。 啰嗦了这么长，我们来画个图，了解下大概的流程： ## 开撸 #### 组件的实现 首先我们来实现组件这一部分，因为组件关联着后台编辑的预览和最后发布的使用。组件设计我们应该尽量保持组件的对外一致性，这样在进行渲染的时候，我们可以提供一个统一的对外数据接口。这里我们的技术选型是基于 Vue 的，所以下面的代码部分也主要是基于 Vue 的，但是万变不离其宗，其他语言也类似。...