react webpck
发布在web组件探索2015年11月30日view:2023
在文章任何区域双击击即可给文章添加【评注】!浮到评注点上可以查看详情。

前言

当初我们在技术选型的时候,选择react最重要的原因是它能帮我们实现组件化。然而只是逻辑的组件化已经不能满足我们的胃口了,我们希望将组件化做到极致,我们还想要:

  1. 一个组件的资源都放在一个目录下
  2. 组件的使用如丝般顺滑
  3. 性能性能性能!生产环境的资源分配最优

这些需求,react全家桶里的webpack都能满足!

webpack简介

webpack是一个模块打包器,它的工作原理大致是,从一个入口模块开始,解析依赖,有时候也顺便编译代码,然后生成适用于生产环境的代码文件。

一切都是模块

它解析依赖的过程很有意思,当遇到图片,css,template等非js资源时,也会把资源读出来,放在事先配置好的位置。这就能很好的满足我们上面提到的第一个需求:一个组件的资源都放在一个目录下。试想,如果没有这个能力,我们用grunt/gulp要怎么做,是的,在构建的时候,遍历每一个目录,把资源读出来,如果我们的目录里有不需要打包到生产环境的资源呢,那就得配置哪些文件不需要了吧?越大的项目,配置就越庞大。这样的组件化,着实心累。

但是如果一切都能在依赖解析的时候做,我们不会打包出任何多余的资源,并且,也不会缺失任何的依赖。这也就使组件的使用如丝般顺滑,我们只需要require一个组件的入口文件,就把组件的依赖不多也不少地全部读进来了。

分包

到这里我们可能会有疑问,在解析过程,从入口文件到最终代码,所有的依赖,那该是多大的文件,浏览器缓存不用了吗,按需加载不要了吗。要的要的。

为了充分利用浏览器缓存,我们当然要把几乎不会修改的第三方资源,如react,zepto分出来,webpack的做法是,当遇到此类资源时,也为它分配资源ID,把它单独写到目标目录,以便我们在页面中单独引用。由于有ID,页面在浏览器打开运行的时候,webpack还是能准确地找到被分出来的资源。

更进一层,不同的页面之间可能有公用的代码,为了利用浏览器缓存,我们也希望能把公用部分抽出来。webpack的做法是,对比出公用的部分,也单独写出来,分配ID。当然,这个对比是文件级别的,这就要求我们平时写代码注意模块化,不要硬是把两个实现不同功能的function放在一个文件里。

至于webpack怎样实现按需加载,大家都能猜到了吧

webpack 在部落PC中的使用

我们来看看在部落PC中我们怎样配置webpack。

入口出口配置

entry: {
  "index": path.resolve(config.srcPath, "pages/index/index.jsx"),
  "detail": path.resolve(config.srcPath, "pages/detail/detail.jsx"),
  ................
}

entry下面,是每个页面入口的路径,webpack通过这些路径开始进行解析。 有入口就有出口,出口配在output下面,对应每个文件的目标路径。

解析过程配置

配好了开始和结束,接着配解析过程中需要做的事情,这些事情,都配在loader或者plugin中。

  // loader
  {
    test: /\.jsx$/,
    loader: 'jsx-loader',
    include: path.resolve(config.srcPath)
  }
  // plugin
  new CommonsChunkPlugin("common", "common.min.js", ["index", "detail", "barindex", "search"]),  

这里解释一下loader和plugin的区别。如果我们有去实现一个自定义loader,我们会发现,loader只能拿到文件字符串,这也就意味着,loader适合用来做对字符串的解析,如编译jsx,编译less, 代码压缩,混淆,而plugin,能拿到这个解析过程的各种事件,所以很适合用来在不同的时间点协作完成不同的事情,例如在读到不同文件的时候进行比对。在示例中,我们配置了一个jsx-loader,一个CommonsChunkPlugin,这些loader和plugin都能轻易的在github上搜到,不需要我们再自定义。

局限性 ##

有了loader和plugin,我们是否可以用webpack包办构建中的所有工作了呢?答案是不,webpack作为模块打包器的属性,决定了它善于处理模块间的关系,却不擅长处理代码级别的关系。所以像一些必要的代码注入,替换就做不了了。或者说,没有提供这样的接口。或许在未来,webpack会开放这样的能力(这要看作者是不是处女座)。

不过这都不是事儿,在部落中,我们选择用grunt来做注入和替换,如果我们想保持纯粹的webpack,还以在源码中暴露相关接口。

all in one?

webpack默认情况下是把css和js打包在一起的,我们需要根据具体的业务决定要不要把css分出来。如果我们经常按需加载一个组件,那么css、js打包在一起是个不错的方案,但是如果我们的页面都是一次性加载的,为了更好的利用浏览器缓存,还是把css分出来比较好,在部落中,我们选择把css分出来。

以上就是部落PC的webpack配置,是不是炒鸡短小精悍。当然webpack还有一些贴心的设计,如alilas,可以减少你写文件路径时的繁琐,再如externals,给一些不得不用全局变量的代码带来便利,等等。

评论
发表评论
暂无评论
WRITTEN BY
kimo
a coder,create things.
TA的新浪微博
PUBLISHED IN
web组件探索

在项目中关于组件化的一些问题,解决方案,和总结

我的收藏