webpack 4.0.0-beta.0 新特性介绍

近年来前端技术如雨后春笋般蓬勃发展,我们也在这个潮流下不断地学习、成长。前端技术的不断发展,给我们提供了许多的便利。例如:JSX的出现为我们提供了一个清晰、直观的方式来描述组件树,LESS/SASS的出现提高了我们书写css的能力,AMD/CommonJS/ES6 的出现为我们模块化开发提供了便利。然而,我们需要使用其它工具将这些工具转化成原生语言以运行在浏览器上。为了能够更好的将这些不同的资源整合到一起,我们就需要一个打包工具,webpack就是这个需求下的产物。 webpack 可以看做是模块打包机。它做的事情是:分析你的项目结构,找到JavaScript模块以及其它的一些浏览器不能直接运行的拓展语言(Scss,TypeScript等),并将其打包为合适的格式以供浏览器使用。目前,webpack 总共发布了三个稳定版本。从17年八月底开始,经历了长达五个月的开发周期,webpack 团队通过增加大量新特性、bug修复、问题改善并于近期发布了 webpack 4.0.0 的 beta 版本。如果你对 webpack 感兴趣,下面我们就来学习一下 webpack 4.0.0-beta.0 的新特性。 P.S. 以下所有代码演示代码都是基于 webpack 4.0.0-beta.0。 1、安装webpack v4.0.0-beta.0 如果你使用yarn:

如果你使用npm:

2、webpack 4.0.0.beta.0 新特性介绍 下面是一些你肯定会感兴趣的新特性。如果阅读完本章后还觉得不过瘾,你可以再这查看完整的changelog。 本章将从以下几部分来介绍 webpack 4.0.0-beta.0。 2.1 环境 webpack 运行环境升级。已经不支持 Node.js 4 版本。源码升级到更高的 ECMAScript 版本。 根据 webpack package.json 配置中显示 Node.js 最低支持版本:”node”: “>=6.11.5” 2.2 模块 webpack 模块类型及 .mjs 的支持: […]

【译】如何构建React组件?

原文:https://reallifeprogramming.com/how-to-structure-components-in-react-54fc43e71546 编程是一项非常复杂的工程,尤其要编写干净整洁的代码更为困难。我们需要考虑很多问题—变量命名、函数作用域、异常处理、安全保障、性能监控等等。在编程中,变量命名唯一还是一件比较困难的事情,我倾向于编写松散耦合且高度聚合的组件。如果从面向对象或者函数式编程的角度来说,也会遇到同样的问题。构建体系是我认为最难的事情,因为它将影响到整个项目。想要成为能熟练设计软件架构的人,需要经过多年磨砺和积累。(也许没有人能完全掌握它— 在如此快速发展的行业中,总有人走在前面,也总有一个方法可以提高软件设计)。 我非常喜欢使用React,因为我觉得它最大优点就是足够简单。在简单和容易之间还是存在区别的,我的意思是React也很简单。当然你需要些时间来了解它,当你掌握其核心内容后,其他的事都是水到渠成的了。下文将介绍比较难的部分。 耦合&内聚 这些指标(耦合&内聚)或多或少的给我们改变编程习惯带了挑战。它们经常被运用在类形式的面向对象编程中。我们也将参考并且运用同样的规则在编写React组件上。 耦合指元素之间的相互连接和依赖关系。如果你改变一个元素需要同步的更新另外一个元素,我们称此为紧密耦合。而松散耦合指的是改变一个元素时,并不需要改变另外一个元素。举个例子,显示银行转账金额功能。如果展示金额依赖于汇率计算,那么内部转换结构更改时,展示的代码也会被更新。如果我们设计基于一个元素接口的,松散耦合的系统,这样元素的改变并不会影响视图层展示。很明显,松散耦合的组件更易于管理和控制。 内聚则是组件是否只为一件事情负责。这个指标是依循单一原则和unix原则:专注一件事情并且做好这件事。如果账户余额格式化展示需要计算相关汇率和检查是否有查阅历史权限,那么这个包含很多功能职责,而这些功能并不相互依赖。也许,权限处理和汇率应该是不同的组件。另一方面,如果有多个组件,一个用于整数部分,一个用于小数部分,另外一个用于货币展示,程序员想展示余额,他们则需要找到所有组件进行组装。其中的挑战则是创造高度内聚的组件。 构建组件 创建组件有很多种方法。 我们希望在合理程度下组件是可以被重用的 。我们也希望构建的小组件可以被用在更大的组件中。理想情况下,我们想构建松散耦合和高度聚合的组件,这样我们的系统更有利于管理和扩展。在React组件中props 类似函数中的参数,它们也可以看做是无状态功能的组件。我们需要思考在组件中如何定义props和组件如何被重用。 接下来,我们以费用管理系统为背景,分析费用详细的格式,来介绍如果构建组件:

根据模型,会有以下几种对费用格式的程序建模方式: 无props 传递一个expense对象 传递必要的属性 传递所有属性的map 传递一个格式化的子对象 下面分别讨论使用上述传递方式的优缺点。不过需要时刻关注使用以上任何方式是要看使用场景和依赖系统的。这也是我们所做的,建立适当的抽象场景。 无props 这是最简单的解决办法,往往就是构建一个写静态数据的组件。

不传递props,就不会给我们带来任何灵活性,而且组件也只能用于单一的场景。在费用明细的例子中,我们可以看到,最初组件是需要接受一些props。不过在某些场景下,没有任何props也是一个好的解决方式。首先,我们可以使用一些组件,其props的内容是一些不会轻易更改的内容,比如:商标,logo或者公司信息等。

编写尽可能小的组件使得系统更加容易维护。保持信息只保存在一处而且只需要在一处进行修改。不要在多处写重复的代码。 传递expense对象 在费用明细确定情况下,我们需要给组件传递数据。首先,我们需要传递一个expense对象。

传递费用对象给费用明细的组件是非常有意义的。费用明细的格式是高度一致的,它显示费用的数据。无论什么时候需要改变格式,这是唯一可以修改的地方。改变费用明细的格式也不会对费用对象自身带来什么副作用。 这个组件是和费用对象紧密耦合,这是一个坏的事情吗?当然不是,但是我们必须意识到这是如何影响我们系统的。 传递一个对象作为props,费用明细的组件将会依赖费用内部结构。当我们改变费用的内部结构时候,我们将需要更改费用明细组件。当然,我们只需要在一处进行修改。 这样的设计如何适应未来的改变呢? 如果我们增加、改变或者删除一个字段,我们将只需改变一个组件。如果我们需要增加一个其他的日历格式化展示?我们可以为日历格式化增加一个新的prop。

我们开始增加属性来使组件更加灵活。如果只有几个选项,那么一切都是很ok的。系统业务开始扩展后问题就来了,在不同的场景下我们需要维护大量的props。

增加props可以使得组件重用性更好,但你可能设计了多重功能职责的组件。这种规则也同样在函数写法中运用。可以用多个参数来创建一个函数,当参数的数目超过3个或者4个时候,意味着这个函数在做很多事情了,也许这时候应该将函数拆成更小的函数来的更加简单。 随着组件props的增加,我们将其拆分成定义明确的组件,比如:OverdueExpenseDetails, PaidExpenseDetails等。 只传递必要的属性 为了减少对象自身的内容,我们可以只传递必要的属性值。

我们分别传递属性,这样我们将一部分工作责任转移给了组件使用者。如果费用的内部结构发生变化,他将不会影响费用明细的格式化。但可能影响每个使用组件的地方,因为我们可能需要修改props。当我们以独立的属性传递props时候,一个组件将更加抽象了。 只传递需要的字段对未来设计改动是如何影响的?增加、更新或者删除字段将不会很容易。无论何时我们要增加一个字段,我们不仅仅要改变费用细节的实现,也需要改变每个使用组件的地方。另外一个方面,支持多种日历格式化几乎是现成的,我们可以传递日历作为prop,也可以传递格式化后的日历。

决定如何展示特定的字段应该在掌握在具体使用组件的人手中,这将不是费用明细组件关心的内容。 传递map或者array的属性 为了达到组件抽象化,我们可以传递一个map的属性值。

使用组件的人控制费用明细的格式化,传递给组件的对象格式则必须正确。

这个方案有很多缺陷,我们很难控制组件展示的样式,并且展示顺序也没有指定。因此,如果我们需要某种顺序的话,可以采用array代替map来解决这个问题。但是仍然还有缺陷。 […]

《拍拍二手》微信小程序开发经验谈

前两周想必大家都看到了京东发布拍拍二手交易平台的新闻,「拍拍二手」APP也正式上线。与此同时我们也紧锣密鼓的进行着「拍拍二手」微信小程序的开发。整个过程痛并快乐着,体会着采坑的痛苦,和跳出坑之后的喜悦。 项目介绍 「拍拍二手」主要有三大业务:回收、优品和个人闲置交易。京东“将以平台化的运营思路,整合回收、检测、再加工、销售等逆向供应链资源,做品质二手。”,而基于微信有庞大的社交关系链,利于产品的推广,直接面对用户,助力自身业务等优点。公司于是决定推出微信小程序版的「拍拍二手」。 微信小程序的的主要页面有: 拍拍首页 拍拍群首页 一键转卖列表页 商品发布页 商品详情页 订单详情页 我的(发布、卖出、收藏) 我们打开小程序,看一段操作的视频: 可谓是麻雀虽小五脏俱全。 项目预研 在此项目之前,我们有过几个小程序的经验,所以项目启动时,我们便采用“前端驱动业务”的方式,推动业务童鞋提前申请小程序依赖的资质,如:小程序账号、名称备案、支付资质、腾讯地图日访问量等等。 同时,区别于以往我们做过的小程序,本次项目将拍拍二手C2C的整体流程移植到小程序平台,并实现以微信群为载体的交易体验。在需求评审过程中,我们大致遇到以下几个问题,并进行了技术预研。预研结果我们将在技术难点部分展开解说。 技术架构 在现有小程序的框架基础上,我们丰富了自定义组件,新增了基础类库,引入了SASS、Eslint在小程序里的应用。这里简单抛出几点: 因受限于小程序包大小的限制(开发时包大小限制为2M);我们对静态图片资源也做了优化,并将大部分图标放在了CDN,小程序直接访问网络资源。  SASS的使用,既是沿用我们现有的PC、M端的重构方式(大家都已熟稔于心),也大大提升了小程序开发的效率。  ESLint 的应用,采用我们设置的代码规范,为我们的代码输出做了把关。 此外,鉴于小程序路由跳转层级的限制(最初是5级),我们细化了每个流程的路由跳转方案。 技术难点 以下,我们将重点解析在项目中遇到的疑难问题和解决方案。我们从小程序包大小、兼容性问题、现有组件缺陷、这些天我们遇到的坑、我们开发的小程序组件、为业务提供备选方案等角度一一举例解析。 小程序包大小限制 为了达到代码不超过2M,为了小而全,我们在开发过程中就必须去思考如何减少代码量,同时提高用户体验。如何提高小程序的代码复用率,同时还要降低它们的耦合。 首先,我们采用前后端分离的方式,前后端约定接口文档;也放弃了传统前端出静态页再套页面、模板开发的方式,前端直接依据接口规范模拟数据后重构+开发; 第二,在开发前我们做了很多的探讨,从几十张设计稿中归纳可以通用的模块,编写了很多通用组件;在数据处理方面编写了很多公共方法,提炼到 util 类中; 第三,我们将静态资源雪碧图化、tiny后,发布到CDN上,小程序里依赖图标的元素直接引用网络资源。 小程序兼容问题 小程序在兼容性方面有一些已知问题,在文档中已明确指出,但最近新出的iPhone X,文档尚不全面,我们这次也对该机型做了测试,并整理出我们遇到的一些兼容性问题,希望可以对大家有所帮助。 首先给大家看一张图片,它存在两个问题,下面我一一介绍它们的处理方式: 1、border-radius 设定后在 iphoneX 中元素的边框显示不全 遇到这个问题的时候只需要把 rpx 改成 px 即可。其实不只是小程序有这类问题,在 M端开发过程中如果使用 rem 这种单位都难以避免会造成这样。 2、iphoneX 中 view 设定 padding-left 在手机中有偏差

[…]

与JDReact的第一次亲密接触 ——加油卡项目总结

JDReact 平台是在 Facebook ReactNative 开源框架基础上,进行了深度二次开发和功能扩展。不仅打通了 Android/iOS/Web 三端平台,而且对京东移动端基础业务能力进行了 SDK 级别的封装,提供了统一、易于开发的 API 。基于以上种种优势,加油卡壳牌业务决定使用 JDReact 技术进行开发。 由于这是我们团队首次使用 JDReact ,在开发过程中遇到了很多问题:不熟悉 JDReact 提供的 API 、如何调用后台数据接口?怎样切换测试、预发环境?开发完后怎样打包?如何上线?等等每个流程都不熟悉。因此,在完成项目之后,很想做一个总结,从前期准备到最终项目上线的整个流程做一个分享,希望能为初次使用 JDReact 的同事有所帮助!如有错误,还请多多指教! 1 前期准备 1.1 项目背景 加油卡壳牌业务是京东APP中的一个项目,可以从首页的「充值缴费」入口进去,如下视频演示: 1.2 项目环境配置 1.2.1 开发分支以及文件结构 初始项目中只包含一个 dev 分支,最后打包 APP 时会从该分支中抽取代码,所以我们新建了一个 trunk 分支,平时在该分支上进行开发,最后打包 APP 的时候再切换到 dev 分支,合并代码。 对于文件结构,如上图所示,其中 Navigation.js 设置页面路由信息,以及打开项目时进入的默认页面;pages 文件夹下存放项目的每个页面代码;images 存放项目开发中使用到的图片;components 文件夹下存放页面中用到的各个组件。 1.2.2 安装依赖环境 按照 JDReact 团队给出的安装依赖环境的步骤,当执行 npm start […]

【译】如何使用ES6箭头函数使JavaScript代码更易读

原文:https://medium.freecodecamp.org/arrow-functions-in-javascript-2f8bf7df5077 箭头函数是搭建现代 Web 应用程序中一种新的基础构件。在本文中,你将会学习箭头函数如何使代码更简洁、使“this”关键字更易于管理;还将学习隐式返回、使用箭头函数记录日志以及隐式返回结合对象一起使用的方法。 如果你喜欢通过视频而不是文本学习,这是视频链接:https://youtu.be/dB1KA-yz65s 。 与常规函数相比,使用箭头函数有两个优点。首先,箭头函数使代码更简洁。其次,使用箭头函数使得管理“this”关键字更容易。 我见过那些初次学习箭头函数的开发者,对于他们来说箭头函数本身的概念并不是很难理解。你可能已经熟悉函数、函数特性、函数用例等内容,但是当你第一次接触箭头函数语法时还是比较容易困惑的。因此,我们要慢慢来,首先介绍一下与常用函数相比,箭头函数的语法是怎样的。 下面是一个基本函数声明和函数表达式的范例:

现在,如果我们想要将函数表达式改为一个箭头函数,我们可以这样做:

使用箭头函数最难的是习惯它的语法形式,一旦你适应了并坚持下去,相信你将会深入的理解并掌握它。 现在,你可能想知道使用箭头函数带来的所有好处。其实,上面的例子并没有充分显示出箭头函数的优势,我发现当使用匿名函数时,箭头函数的优势发挥的最为明显。通过查看另一个使用 .map  的基本例子,可以让我们对箭头函数的语法更为熟悉。

好了,熟悉的差不多了,接下来让我们进行深入的学习。 假设我们有一个函数:getTweets ,该函数接收用户 id 作为入参,通过访问一个简单的 API 接口后,返回所有星数和转发次数超过 50 的 Twitter 用户。 使用 promise 构造函数定义,这个函数看起来是这样的:

是的,功能虽然实现了,但是这个函数还不是最完美的。尽管具体的实现步骤是紧凑的,但是想法有点过于平常了。根据上述对箭头函数的理解,我们来看一下可以怎样改进 getTweets 函数。

好的,酷极了。但是除了不需要写 function 之外,和上面的写法几乎是一致的。虽然这种写法是有益的,却没有什么值得炫耀的。还是让我们来看一下使用箭头函数带来的下一个优点:“隐式返回”。 使用箭头函数时,如果你的函数是一个“简单的函数体”(对于单行函数的称呼),那么你可以省略“return”关键字,该值会自动(隐式)返回。 所以,前面的 add 示例修改后如下:

更重要的是,修改后的 getTweets 函数示例如下:

该代码不仅容易编写,更重要的是,它更容易阅读。 如果箭头函数只有一个入参,那么我们可以做的进一步的修改是省略该参数周围的 ()。考虑到这一点, getTweets 函数可以这样写:

总的来说,我认为上面做的每一种改变都是巨大的进步。 箭头函数的另一个优点就是如何管理“this”关键字。如果你对“this […]

© 2018 JDC. All Rights Reserved.