你在使剑,是的,可是你的目的是杀人,直追你的目标,忘记手中长剑,才能使出最高的剑法... 而这世上又有多少剑客, 拘泥于手中快剑而落入俗套,终究没法到达登峰造极的境界... ----阿莱克西斯前端
剑,是剑客的武器,而现代前端工程师的剑能够理解为前端框架(固然不止是前端框架,但今天咱们只谈前端框架)。git
所谓御剑之道,指的是如何驾驭全部前端框架。对,你没有看错,是全部,而不是某一个。程序员
若是是介绍如何驾驭某一个框架,那么本文的标题可能就要改为“御剑之术”,但本文介绍的是“御剑之道”。github
现代前端程序员刚一入行就要选择一款前端框架来做为本身的技术栈,好比Vue,React,Angular等。包括各类公司的招聘信息上也会写上本身但愿应聘者掌握至少一种前端框架。因此不少人就会有一种困惑:我应该选择哪款框架做为个人技术栈?前端框架
若是你存在下面这些困惑,那么本篇文章会帮助到你:服务器
我本人对Vue是最熟的,熟悉到什么程度呢?几个月前我就已经写完了一本介绍Vue原理的书(《深刻浅出Vue.js》)还没上市,但我并不以为本身是Vue阵营的人。我以为本身是无阵营的,或者换一种角度来说,“框架并非个人剑”。前端工程师
这本书是与人民邮电出版社签约的,预计过不了多久就会和你们见面了。架构
对于这本书的内容质量你们尽管放心。人民邮电出版社出版的书,质量都不会差。就算你们不相信我,也要相信出版社。框架
对于初学者来讲,开局可以掌握一把绝世好剑,当然会在前期获得很大的帮助,一招练成,出手就能伤人。但也正是这把剑,若是不能在合适的阶段把它丢掉,那么它会限制本身没法到达登峰造极的境界。函数
独孤求败被称为『剑魔』,而他最终的境界是无剑。
《天龙八部》中描述段誉无形有质的六脉神剑时,曾写道:“使剑全仗手腕灵活,但出剑收剑,不论如何迅速,老是有数尺的距离,他以食指运那无形剑气,却不过是手指在数寸范围内转动,一点一戳,何等方便?(没错,前端工程师的剑也是一样的道理)
不少人在学习前端框架时,会进入到一个误区,这个误区是太过在乎框架提供的语法(API)。而且喜欢对各类框架孰优孰劣要争论个高低。
在实际工做中我历来不和人争论这些,但有一次和朋友们聊天恰好聊到这个话题,我说全部框架都同样用,只不过语法有点区别。其中一个朋友可能并无理解我这句话的意思,而后发了一篇文章说Vue和React在设计理念上是有一些区别的,不仅是语法。
设计理念不一样致使提供的语法不一样,但再怎么不一样,差别再怎么大,它们要解决的问题是相同的。如今这些框架其实没有什么React能作到的事换成Vue就作不了。反而是React能作的事,使用Vue都能作,反之亦然。那么对于我来讲,这两把剑就是同样的,只是使用起来手感不太同样。仍是那句话,要直追咱们的目标,不要拘泥于手中的剑。
站在“术”的角度看,它们确实不同,并且能够说几乎没有同样地方。可是站在道的角度看,它们是同样的。
因此你会发现,我关注的根本就不是框架提供的语法,我关注的是框架的特性。我说的框架特性,指的不是React提供了JSX,或者Vue提供了模板语法。这些不是我所说的特性,这些其实仍是语法。
那么框架的特性到底指的是什么呢?咱们举两个例子来感觉一下。
更深一步思考,React提供的JSX和Vue提供的模板,它们的目的是什么?目的是为了实现声明式渲染的功能。不管是JSX,或者是Vue中的模板,本质上都是描述了『状态』与『视图』之间的映射关系。
因此声明式渲染是框架的特性。
声明了映射关系以后,能够获得一个公式:
UI = render(state)
状态与视图之间的映射关系,等同于render
函数。熟悉React的同窗对这个公式应该并不陌生。JSX与Vue的模板在这一点上是相同的。在框架的内部,不管是JSX仍是Vue的模板,最终会编译成render
函数。
上面这个公式,输入的是state,输出的是DOM。因此输入变了输出就变了。
这个特性就是咱们常说的数据驱动视图。
这里会引出一个问题,框架必需要知道Web应用在运行时”状态“是否发生了变化,而后才能使用前面提到的公式从新输出一个新的UI。因此如何知道Web应用的状态在运行时是否发生了变化这个问题是全部框架必须去解决的。
解决方案有不少种。不一样框架,或者同一个框架的不一样版本对这个问题的解决方案都不一样,但相同的是均可以解决问题。关于这个问题如何解决,我在曾在个人文章、分享的PPT以及目前还未上市的书中都有详细的介绍。这个问题不是本文所讨论的重点,感兴趣的同窗能够点击这里了解更多信息。
不一样的解决方案,致使的直接结果就是它所提供给用户的上层语法或API彻底不同。
不一样的永远是语法,相同的永远是特性。----Berwin
现代主流框架都具有的一个特性是“组件”,它们都会以“组件”做为一个基本的抽象单元。
可能不一样的框架,它所提供的操控组件的方式不同,但概念上是类似的。
以前听过一次尤雨溪的知乎Live,他将实际应用中的组件分为四种类型并依次介绍了四种组件之间的区别:
展现型组件
展现型组件是最直接也是最经常使用的组件,就是用数据渲染视图,“数据进,DOM出”。
接入型组件
接入型组件一般会跟接入数据的service
层打交道。包含一些和服务器或数据源打交道的逻辑,而后接入型组件会将数据往下传,传给比较简单的展现型组件。在React中这种类型的组件被称为“容器组件(container component
)”。
交互型组件
交互型组件典型的例子是对表单组件的封装和加强。大部分组件库,像ElementUI都是以交互型组件为主。这一类组件会有比较复杂的交互逻辑,可是它是一个很是通用的逻辑,因此它强调复用。
功能型组件
功能型组件是比较抽象的组件。用Vue举例,路由的<router-view>
和Vue自带的<transition>
都属于功能型组件。它自己不渲染任何内容,它是一个逻辑型的组件。它一般做为一个扩展或一种抽象机制存在。
不一样框架操控组件的方式可能不同,但使用组件的“心法”永远是同样的。这就是关注特性带来的好处,你能够切换到任意一个框架,使用组件或封装组件时,老是上面列出的几种类型。
掌握了“心法”的程序员在切换框架时,他的状态一般是这样的:我如今想写一个交互型组件,这个框架都提供了哪些API?去翻翻文档看一下。而后就能够写出一个很优雅的组件出来,哪怕刚使用这个框架才不到一天。
若是没有掌握“心法”,用了一个框架写出的代码很糟糕,那么换了一个框架也不会写出更好的代码,甚至更糟糕。
绝顶剑法,不在于使用的是什么剑,而是使剑的人。
前面详细介绍了两个特性给你们感觉下为何要重视特性。框架的特性太多不能每个都详细介绍,下面列出一些你们比较熟悉的通用特性:
对于初学者不知道应该学哪一种框架的问题,其实大可没必要这么纠结,随便选一个去学(固然是学特性),之后切换到其余框架也是很轻松的事情。
有经验的程序员也无需担忧投资了一个框架,刚学会就过期了。框架虽然过期了,但内功心法却深深地扎在你的脑壳里。
为团队选择技术栈所考虑的因素与人不同。就目前来看,各大主流框架所提供的能力与社区的繁荣程度并无明显的差距,因此框架是否靠谱等问题基本上不须要考虑,更多要考虑的因素反而是:
当团队肯定好了技术栈以后,最重要的是统一。一个团队内部只存在一种技术栈并打磨出成熟的架构与工做流以后,会大幅提高团队内的生产效率。
在学会了框架的特性以后,若想达到“无剑”的境界,那就须要具有实现这些特性的能力。只有具有了这样的能力,你才能彻底理解一种“特性”,从而达到人剑合一的境界。不然这些特性对你来讲是一个黑盒,你永远不知道它内部发生了什么,你就只是这把剑的使用者,没法真正的驾驭它们。你会被框架的设计者牵着鼻子走,而后无奈地说一句:求别更新,老子学不动了。
注意,前面提到的是实现这些“特性”的能力,固然若是能实现一个完整的框架更好。但一个框架一般会有不少很繁琐的东西会消耗掉不少精力,而那些东西其实并非很关键,就像咱们平时写代码同样,老是有不少没什么技术含量的体力活。
举例来讲,真正能让咱们彻底理解“声明式 & 数据驱动渲染”这个特性的方式就是亲自动手去实现它。固然,不一样框架或者同一个框架的不一样版本对这个特性的实现方式都不太同样。但这都不要紧,当咱们亲自动手用某一种方式实现它以后,咱们就能真正理解不一样的实现方式之间各自有什么取舍,只有亲自动手实现了某个特性以后咱们才能知道不一样的实现方式有哪些优点,为了获得它而付出的代价(舍弃的)是什么。
对“声明式 & 数据驱动渲染”这个特性的实现方式感兴趣的同窗能够看个人另外一篇文章《聊聊我对现代前端框架的认知》,在这篇文章中,有一个小节“现代前端框架对渲染的处理”对这个问题进行了相关的介绍。
本文说了这么多,但其实只讲了一个道理,就是要重视『特性』,而不是语法与API。
还有就是本文开头的那句话,若是想达到登峰造极的境界,就不要过于专一手里的剑。框架既是神兵利器,也是枷锁。既赋予咱们力量,也束缚着咱们。
若想挣脱这个枷锁,就要达到“手中无剑,心中有剑”的境界。
初学者最开始学武每每急于求成,学了一招出手就想伤人。但却不知真正的高手不多杀人。
中前期学发,中后期学收,收发自如,神功乃成。