「南方古猿」之 png sprite
看到上面這張圖，相信好多資深前端會感到很親切。
早期為了減少資源的請求，人們想到了將小的 png 圖片合併到一張圖上，然後根據 background-position 來顯示不同的圖片。
早期還有靠人肉來測量坐標，隨著構建工具的發展，我們可以用一些插件，如 grunt-spritesmith ( https://github.com/Ensighten/grunt-spritesmith )、gulp.spritesmith ( https://github.com/twolfson/gulp.spritesmith ) 等。它可以幫助我們自動合成，並生成好 css， 位置都計算好的。
那麼使用 png 圖片這種方式它的優點就是兼容性好。但是一旦開發多了，它的不便變體現出來了，換顏色、改大小、透明度、多倍屏等等。
所以對於這種方式我們只能緬懷。
「能人」之 Iconfont
於是人們又想出了用字體文件取代圖片文件：Iconfont。
雖然早期製作或尋找合適字體比較麻煩，但隨著各種字體庫的網站出現，如： http://www.iconfont.cn ，那都不是事了。再加上 css 的自定義字體的兼容性非常好，Iconfont 迅速開始流行起來。以這個站為例，大概看下使用方法：
在 Iconfont 中創建自己的項目，將需要使用的圖標添加到自己的項目中。
複製出 Unicode 或 Font class
全部代碼如下
這裡有demo：https://codepen.io/maming/pen/YNpMwd
在實際開發中，我們會把常用的一些圖標封裝成組件 ( http://uxcore.coding.me/css/iconfont/ )，直接使用。像這樣
Iconfont 用起來挺方便的，而且兼容性也十分的好，大小、顏色可隨意改變。
但它仍有缺陷：
字體需要加載資源
有時候可能會出現鋸齒
只能被渲染成單色或者css3的漸變色
所以我們要繼續進化。
「直立人」之 svg symbol
使用 svg ，這裡所謂的進化並不是 svg 本身的進化，因為 svg 並不晚於 Iconfont。只是環境（兼容性）的原因導致它無用武之地。就像最近火的一塌糊塗的 AI, 其實最早在 1956 年就提出了。隨著外界因素的進化，IE6/7/8 的淘汰， android 4.x 的開始，svg 的機會變到來了。先看下兼容性：
The <symbol> element is used to define graphical template objects which can be instantiated by a <use> element.
通過定義的 svg 模板，我們可以使用來加載它。
那麼是怎麼來的呢？
同樣，在這個構建工具十分發達的時刻。
最開始我們使用了 gulp-svg-symbols ( https://github.com/Hiswe/gulp-svg-symbols )，它可以將指定目錄中的 svg 自動合併到一個 svg 文件中，文件裡包括了所有 icon 的 symbol 模板，然後再將這個模板將其隱藏放到 index.html 中。
但是這個庫有個坑點是它依賴了一個 Unicode 的包，這個包在國內安裝炒雞慢，於是我們棄用了它，使用了gulp-svgstore ( https://github.com/w0rm/gulp-svgstore )
按照這種方式我們成功的開發一 salt-icon ( https://github.com/saltjs/salt-ui/blob/master/demo/src/pages/icon/PageIcon.js ) 這個組件，裡面包括了一些常用的 icon。使用方式：
這樣我們在 mobile 端用 svg 替代了 Iconfont，解決了上述 Iconfont 提到的問題。
但是很快我們就發現，在 index.html 中引入那一坨 symbol 模板是極其噁心的。
隨著 webpack ( https://webpack.github.io/ ) 打包的成熟，各種 loader，我們將那一坨 symbol 模板直接打包成一個 salt-icon-source.js 文件，在這個文件中將其 append 到 body 上。
同時發現了上述提到的 iconfont 網站 ( http://www.iconfont.cn/ ) 也支持直接導出 symbol 文件。
這樣雖然解決了引入模板的那個問題，但是後面又發現的 symbol 在安卓 4.3.x 下無法顯示，也就是說 symbol 的兼容性並沒有直接使用 svg 好。
然後我們通過使用一個叫 svg4everybody ( https://github.com/jonathantneal/svg4everybody ) 的庫，解決了上述兼容性問題。（它的原理是如果發現不支持 symbol 的，它會通過 xlink:href 拿到 svg 的資源，然後動態創建一個 svg,插入到當前位置）
雖然解決了兼容性的問題，但是我們深深的感覺到了這種方式的不優雅。
講的這裡，可能會有人會有疑問，既然已經有 svg-react-loader ( https://github.com/jhamlet/svg-react-loader ) 了，為什麼不直接 import svg 文件？
業務中使用的圖片當然可以直接 import 加載，但一些通過的圖標我們希望是能統一起來，做出組件，更方便的使用。
而且我們組件中還會對 svg 處理了它事件不能冒泡的問題，也就是在某些低版本的安卓機上，svg 圖標是無法點擊的。解決方案有兩種：
不過，這個問題可以給我帶來啟示，『既然已經有 svg-react-loader ( https://github.com/jhamlet/svg-react-loader ) 了』，那麼 svg-loader 裡做了什麼呢？symbol 的方式或許真的可以淘汰了。
「智人」之 svg
看下 svg-react-loader ( https://github.com/jhamlet/svg-react-loader ) 的實現
首先有一個模板
然後有一個 sanitize.js ，會對 svg 做一些處理，加上標準的 xml namespace, 把 React 特有的屬性 class / for 轉化為 className / htmlFor, 把屬性名轉化為駝峰。
最後根據模板生成這樣一段代碼
這樣的代碼我們就可以直接在 react 中直接使用了。
所以我們的組件藉助這樣的思想，完全棄用了 symbol 模式。
我們先掃描對應的 svg 文件，將其按上面的思路生成一個個單獨的 js 文件。
在組件層面可以再封裝一層，統一引入，提供一個通用的調用方式，和上面一樣。
更好的是你也可以單獨引用每一個文件，減小使用體積。
最後我們憧憬一下，隨著 react 15.x 的發布，react 對 svg 的支持越來越好了，隨著 IE 8 也即將被遺棄，我們的 PC 端也有望從 Iconfont 轉換到 svg 了。