五倍直播間

Blogs - Sidebar


`\[a-zA-z]{3,}|^\D$|^[0-9a-z]*$|^[0-9A-Z]*$\`

相信大家在寫程式的過程當中，一定都曾看到過像上面這種，有點像亂寫的程式碼，有些可能看起來沒那麼複雜，而有些則是長到讓人難以招架，光是看到就讓人頭痛，更不用說去讀懂它了。

事實上，這種程式碼叫做正規表達式(RegExp，Regular Expression），是處理文字非常重要的利器，當你希望規範文字的格式、或者是限制使用者的文字格式時，正規表達式是不可或缺的存在。

文首的表達式是我超級討厭的銀行密碼格式（還有 PlayStayion Network 的密碼格式），會找出這些格式：

* 超過連續三個英文字母（不分大小寫）
* 沒有任何數字
* 沒有任何大寫字母
* 沒有任何小寫字母

只要你設立的密碼符合以上任何一個格式，程式就會拒絕你使用這組密碼，以這樣的方式來讓使用者建立出一個安全性相對高的密碼——雖然很多時候都是徒勞無功的。

在這篇文章當中，希望可以透過簡單明瞭的方式來講解正規表達式，並且讓大家在未來撰寫或閱讀正規表達式的時候，能夠得心應手，無所畏懼。

在 Ruby 裡面，有幾種方式可以定義正規表達式，比較普遍的方式是用 slash(/) 將正規表達式包起來，像是 `/[a-zA-Z]*/`，而另一種方式則是用 Ruby 的 class生成，變成、 `Regexp.new('[a-zA-Z]*')` ，值得注意的是，使用第二種方式不需要加入 slash，只要將內容以字串方式傳入即可。大部分情況下我們會看到第一種方式，少部分的情況下，特別是需要動態產生正規表達式的時候，第二個方式會比較好用。最後則是將利用 `%r{[a-zA-Z]*}` 這樣的方式也可以定義正規表達式。

> 使用 %r 的情況下，不需要將 {} 裡面的表達式包成字串

在正規表達式當中，我們有幾個比較常用的 Match Character 來表示我們的規則：

| Match Character | 規則                 |
|-----------------|----------------------|
| .               | 所有字元             |
| \w              | 所有字母，包含大小寫跟數字 |
| \d              | 所有數字（0-9)       |
| \D              | 除了數字以外的字元   |
| [ ]              | 指定的範圍，例如[a-f]|

當然，只有 Match Character 還不夠，我們還必須指定字元是否重複，或者重複的次數，否則預設都是一個字元。

| 重複表示 | 規則                         |
|----------|------------------------------|
| ?        | 未出現或出現一次             |
| *        | 未出現或出現多次             |
| +        | 出現一次或多次               |
| {a}      | 出現 a 次                    |
| {a,}     | 至少出現 a 次以上            |
| {,b}     | 最多出現 b 次                |
| {a,b}    | 最少出現 a 次，最多出現 b 次 |

舉個例子來說，台灣的市話號碼有可能是七碼或者八碼，我們就可以利用 {a, b} 這個重複規則來做出正確的格式：`/^\d{7, 8}$/`。這個正規表達式的意思，我們希望找出一個有七到八個數字的字串，而前面的 `^` 以及後面的 `$` 分別代表字串的開頭開始和字串的結尾，這在很多場合是非常重要的。假設沒有規定必須從字串的最前面開始或在最後結束，他便會抓取最前面或是最後面符合的字串，如此一來便不符合我們希望的規則。

舉例來說，如果我們的規則是這樣 `/^\d{7, 8}/`，沒有最後結束的符號，那麼即使當我輸入手機號碼 0955555555，他還是會回傳最前面的八位數字給你。

```ruby
# incorrect
pry(main)> '09555555555'.match /^\d{7,8}/
=> #<MatchData "09555555">

# correct
pry(main)> '09555555555'.match /^\d{7,8}$/
=> nil
```

如此一來我們可以回頭看一開始的表達式
> `\[a-zA-z]{3,}|^\D$|^[0-9a-z]*$|^[0-9A-Z]*$\`

這邊可以注意到，中間我們用 pipe `|` 來做分隔，其實 pipe 就是 or 的意思，我們可以利用這個方式來加入多個條件，因此我們也可以將表達是分開來解讀。

- `[a-zA-Z]{3,}` 這個部分則表示我們要找出無論大寫或是小寫的字母，三個連續字母連在一起的組合。
- `^\D$` 這裡則表示找出整個字串都完全沒有數字的組合。
- `^[0-9a-z]*$` 這段則是找出整個字串中只有小寫和字母，意思就是字串中完全沒有大寫的組合。
- `^[0-9A-Z]*$` 和上面那段相似，只是找出沒有小寫的組合。

利用這個表達式，我們就可以順利做出一個討人厭的密碼規則囉，是不是很簡單呢？

在文章的最後，提供一個方便的線上工具，你可以在這個網頁上任意嘗試各種 RegExp 的組合，並且確認規則是否正確，非常地方便：[http://rubular.com/](http://rubular.com/)

希望透過這篇文章，讓大家可以輕鬆地解讀正規表達式，並且也能夠順利地用正規表達式寫出簡潔的程式碼。

photo by [Christiaan Colen](https://www.flickr.com/photos/christiaancolen/)


post-動動手來學 Regular Expression 正規表達式 / cover 

動動手來學 Regular Expression 正規表達式


即便是到了 2019 年，每次長途通勤我仍然是飽受行動網路速度不穩定的折磨，特別是每次搭乘臺鐵經過臺北到板橋區間，時有時無的訊號簡直快要把我逼瘋。這時只能夠透過提前下載好的 Netflix 影集、Audible 的有聲書或是 Kindle 來消磨時間，但若手癢拿起手機點開電子報中的文章，緩慢的載入速度還是立刻把人打回現實。

為了帶來更好的體驗，現在大家開始提倡諸如 Accelerated Mobile Pages (AMP)、Progressive Web App (PWA，漸進式網絡應用程式) 的標準，想要盡可能改善在網路不穩定的情況之下，行動存取的體驗。

早期我們都會被要求透過 Google 的 [PageSpeed](https://developers.google.com/speed/pagespeed/insights/?hl=zh-TW) 服務，來稽核手邊的網頁服務是否有做到基本的優化。去年 (2018) 年末，Google 更是一舉發布 [web.dev](https://web.dev) 這個服務，試圖逼死所有的開發者，透過 [Lighthouse](https://developers.google.com/web/tools/lighthouse/?hl=zh-tw) 的檢測，直接數值化網站中可能影響瀏覽體驗的瓶頸。

![post-透過 AWS ServerlessImageHandler 實現動態圖片處理](//images.ctfassets.net/8er52l3j5u76/10JCwFSh4NyqZSwpbMPOMM/f92a496ba2bd75f56743295606f31375/XHozjUs.png)

在這個前提之下，大家開始汲汲營營的著手試圖消滅網站中可能的效能瓶頸，於是前端開始向我們提出許多調整伺服器設定、優化回應速度等的要求。

今天以圖片作為討論的重心，你最常會在檢測報告中看到跟圖片相關的效能建議包含：

- Properly size images
  - Guide: [Serve responsive images](https://web.dev/fast/serve-responsive-images)
- Efficiently encode images
  - Guide: [Use Imagemin to compress images](https://web.dev/fast/use-imagemin-to-compress-images)
- Serve images in next-gen formats
  - Guide: [Use WebP images](https://web.dev/fast/serve-images-webp)
- Defer offscreen images
  - Guide: [Use lazysizes to lazyload images](https://web.dev/fast/use-lazysizes-to-lazyload-images)

![post-透過 AWS ServerlessImageHandler 實現動態圖片處理](//images.ctfassets.net/8er52l3j5u76/78WRffQbCVdST24WsfZMYf/1ee270d71ec774b06251c49fe16d3bf6/6HaXOX1.jpg)

令人感動的是 [web.dev](http://web.dev) 的檢測不單單只是提出問題與抱怨，他還直接在檢測報告的後面附上了詳細的指南，幾乎是 Step by Step 的告訴你應該又如何改善，完全就是網站優化的明燈。

Defer offscreen images 算是被抱怨的項目中最容易改善的項目，只要針對不是在 First View 中需要的圖片，進行 Lazyloading 的處理就能搞定，Google 甚至還連處理這件事情的套件都幫你選好了。

其他項目分別是 Properly size images、Efficiently encode images、Serve images in next-gen formats：

- Property size images 基本上是針對螢幕大小，回傳足夠尺寸的圖片
- Efficiently encode images 是要求針對圖片品質進行必要程度的無損 / 有損壓縮
- Serve images in next-gen formats 則是考量到圖片轉換為 Webp 之後可以大約減少 [25% 到 34% 的大小](https://developers.google.com/speed/webp/)，要求在支援 Webp 的瀏覽器中，以 Webp 格式回應圖片請求。

如果處理的圖片項目屬於靜態資源，那麼以上三個項目都可以很輕易的透過現代化的打包工具 (Eg: Webpack) 來達成，但如果今天網站的多數資源來自於 User-Generated Content (UGC，用戶生成內容)，就必須得要在使用者上傳圖片之後進行壓縮。一般來說我們會期望這樣相對耗時的處理過程，不要影響到使用者發布內容的體驗，所以通常會在背景程式中進行處理。

但是假設使用者每次會上傳 5 - 20 張不等的圖片，根據需求必須要壓成至少 3 種不同的大小、2 種不同的格式，我們得要設定一定等級的伺服器等待處理使用者的圖片。而這些提前準備好的圖片，有時根本沒有見天日的時刻。尤其當設計改變、圖片顯示的大小改變時，可能得要重新壓過所有的過往圖片。於是我們開始想

> 如果這些圖片能在需要時即時長出來，那該有多好。

這樣的處理模式可以透過 [Cloudinary](https://cloudinary.com/pricing) 之類昂貴的第三方服務做到 Image Processing on the fly 的功能，或是是透過 [Thumbor](http://thumbor.org) 之類的 Open Source 專案來打造出自己的 On-Demand Imaging service。

要自行打造這樣的服務，你需要

- 原圖儲存的空間 (諸如 AWS S3 Bucket 或是 Google Cloud Storage)
- 一個運作 Thumbor API 服務的伺服器
- 一般來說我們還會希望有個 CDN 服務來快取處理過的圖片

要讓這樣的服務達到最小可用的等級，會需要夠快的處理速度、夠快的平行處理能力。網路上有許多教你如何打造這類服務的教學，其中有不少是透過  AWS Lambda、Google Cloud Functions 等 Serverless 架構來達成優異的效能、與穩定的平行處理表現。

就在我閱讀相關的教學與分享的過程中，我無意間看到了 [AWS Serverless Image Handler 的白皮書](https://s3.amazonaws.com/solutions-reference/serverless-image-handler/latest/serverless-image-handler.pdf)，這個服務的架構可以說是幾乎與我夢想中的藍圖相當符合：

## Serverless Image Handler 架構

- 原圖存於 AWS S3 Bucket
- 透過 API Gateway 接收對於圖片的請求
- 請求由 AWS Lambda 這個 Serverless 服務來執行
    - 自 S3 Bucket 中取出圖片
    - 由 Thumbor 為基礎的 Function 來進行圖片的壓縮、裁圖、格式轉換、加上浮水印等動作
    - 在 API Gateway 的前面以 CloudFront 完成 CDN 服務，快取處理過後的圖片

![post-透過 AWS ServerlessImageHandler 實現動態圖片處理](//images.ctfassets.net/8er52l3j5u76/2s0CKRhnQSRWbRVsjnZXkX/e05955e236dfdda08d84ae7930a62527/lNrA1vm.png)

(Serverless Image Handler 架構示意圖，摘自：AWS Serverless Image Handler Implementation Guide)

## 部署

這份白皮書當然不僅僅止步於概念化的階段，在線上的 [AWS Serverless Image Handler Implementation Guide 關於 Deployment 的章節中](https://docs.aws.amazon.com/en_us/solutions/latest/serverless-image-handler/deployment.html)，可以找到關於如何透過 AWS 提供的 CloudFormation Stack 部署這個服務的詳細教學，首先你應該有 1 個儲存 S3 圖片用的 Bucket，這邊因為篇幅關係，就不對於 AWS 帳戶設定、S3 Bucket 設定做 Step by Step 的解說。

按下文中 「[Lauch Solution](https://console.aws.amazon.com/cloudformation/home?region=us-east-1#/stacks/new?stackName=ServerlessImageHandler&templateURL=https:%2F%2Fs3.amazonaws.com%2Fsolutions-reference%2Fserverless-image-handler%2Flatest%2Fserverless-image-handler.template) 的按鈕」，你就會被導引到 AWS CloudFormation 的服務中，並自動帶入這個 AWS 預先幫你寫好的 Templates

![post-透過 AWS ServerlessImageHandler 實現動態圖片處理](//images.ctfassets.net/8er52l3j5u76/62ocy9iNST7PdkZRRpX3wE/0a69d5229b8b9028a52099cf073b01d8/WIzX4iR.png)

接著你需要至少填入

- Origin S3 Bucket：需要處理的圖片儲存的 S3 Bucket 名稱
- Origin S3 Bucket Region：該 S3 Bucket 位於的區域

若需要 CORS 設定來避免別人在他們的網站中嵌入你的圖片

- Enable CORS 選項改為 「Yes」
- CORS Origin 設定為可嵌入圖片的網站位址，這邊必須注意包含域名、協定等資訊都必須要完全符合，以我們官網為例，必須要為 https://5xruby.tw
- 需要特別注意的是，目前並不支援 Multiple CORS Origin 的設定

關於 Deploy UI 的設定

- 若勾選 Deploy UI 為 「Yes」、且設定 UI Prefix 為 「demo/」，則部署完成後可在 `https://[CLOUDFRONT_ENDPOINT]/demo` 中看到一個示範用的 UI 介面
- 請特別注意，在撰文時的最新 Serverless Image Handler 版本 `v 3.1.0` 中，當 Deploy UI 的選項被開啟，那麼 Serverless Image Handler 可能會沒有辦法處理設定好的 Origin Bucket 的圖片，若沒有特別想要玩玩看示範用的 UI 介面，建議不要開啟 Deploy UI 的選項

![post-透過 AWS ServerlessImageHandler 實現動態圖片處理](//images.ctfassets.net/8er52l3j5u76/2uthWAAAZLVrmtGAmWHa1C/086768cf7dd2178051eae737cbda69bf/zRobQ1Z.png)

- 依據需求在下一頁的選項中，為這個 CloudFormation Stack 中的資源建立 Tag、指定 IAM 角色或是進階選項，這邊除了建議以有意義的 Tagging 標註這個 CloudFormation Stack 生成的資源外，其他選項沒有需求的話可以暫時保留預設就好。

- 最後在 Review 步驟中勾選：「I acknowledge that AWS CloudFormation might create IAM resources with custom names.」，同意 AWS Cloudformation 可能幫你建立有自訂名稱的 IAM 角色中並按下「完成」，就會被導引到 CloudFormation 的頁面中了

- 此時你應該會在頁面中看到剛剛設置的 CloudFormation Stack 在「Create In Progress 的狀態」，並且可以在下面的 Event 中看到詳細的各 Resorce 設定的情形，按官方的文件中表示，整個過程大約需要 25 分鐘。

![post-透過 AWS ServerlessImageHandler 實現動態圖片處理](//images.ctfassets.net/8er52l3j5u76/5PeqotOEEyjU1RgSCj6izH/dffa86e7cb0f11240e98826a66334441/Dc3ZJqm.png)

## 價格

在白皮書的 Overview 章節關於 Cost 的段落，指明了可能會產生的費用包含來自於 S3 Bucket、CloudFront、Lambda 與 API Gateway 的費用，以服務設定於美東區域 (N. Virginia) 為例，每月一百萬次的圖片處理請由、15 GB 的圖片儲存、以及 50 GB 的資料傳輸費用，會產生的費用大致如下：

| AWS Service        | Estimated Price |
|--------------------|----------------:|
| Amazon API Gateway |          $ 3.50 |
| AWS Lambda         |          $ 3.10 |
| Amazon CloudFront  |          $ 6.00 |
| Amazon S3          |          $ 0.23 |
| Total              |         $ 12.83 |

需要注意的是 AWS 的 PUT 跟 GET Requests 所產生的費用會因為每個網站性質、圖片數量有很不一樣的情況，所以並沒有被計算於其中，另外若有使用到「智慧裁圖」的功能，必須支付 AWS Rekognition 的圖片辨識費用。

## 真的可以達成需求嗎？

部署完成後，你應該可以在 CloudFront 中看到對應的 Endpoint 設定，或是在剛剛 CloudFormation Stack Detail 的 Output 中找到部署後的 Endpoint。

透過請求 `https://[CLOUDFRONT_ENDPOINT]/[THUMBOR_FILTER]/[STORAGE_PATH]` 的方式，就能夠動態的達成圖片的動態縮圖。

為了示範，我特意的打開了 Demo UI 的選項：

![post-透過 AWS ServerlessImageHandler 實現動態圖片處理](//images.ctfassets.net/8er52l3j5u76/3Y7sBqVJ0v4ZWVTbgGD6v1/0b0497fcce01555a93a825606a324f2a/LfBgFRf.jpg)

可以在畫面中看到，除了基本的長寬的切圖、格式轉換、 Quality 壓縮等設定外，甚至包含動態浮水印、智慧裁切的方式。

以上面那張大圖（[點我看原圖](https://github.com/awslabs/serverless-image-handler/blob/master/source/ui/img/face2.jpg)）進行以下的裁切設定：

```
200x200/smart/filters:format(png):watermark(https://d3soe0wkhi4rba.cloudfront.net/demo/img/aws-logo-watermark.png,120,130,0)
```

- 大小：200x200
- 智慧裁切
- 轉換為 PNG
- 以 AWS Logo 在右下角進行浮水印繪製

可以得到如下的結果：

![post-透過 AWS ServerlessImageHandler 實現動態圖片處理](//images.ctfassets.net/8er52l3j5u76/5Ze25N9HocnGmzArW9eE7m/819bd1ed51dfe42311805707d476fd87/mM4Cq0N.png)

關於支援的 Filter 及詳細用法，可以參閱

- AWS 白皮書中的 [Appendix A: List of Supported Filters](https://docs.aws.amazon.com/en_us/solutions/latest/serverless-image-handler/appendix-a.html)
- [Thumbor 官方文件中的 Filters 章節](https://thumbor.readthedocs.io/en/latest/filters.html)

## 安全性考量

除了可以透過 CORS 設定來避免別的網站盜用你的圖片以外，也可以透過 Thumbor 的 SafeURL 避免其他任意修改網址中的 Thumbor 參數，以獲得其他樣貌的圖片，要啟用 Safe URL 的功能，可以在對應的 AWS Lambda Function 中設定以下的 Environment Variables:

![post-透過 AWS ServerlessImageHandler 實現動態圖片處理](//images.ctfassets.net/8er52l3j5u76/4OPqAcscaU53WDbkJUQ8pB/63661fc8985549d5673b6a4d08711d06/iADN3x0.png)

- ALLOW_UNSAFE_URL: True
- SECURITY_KEY: 設定為任何你喜歡的密鑰

更新完 Lambda Function 後，以後的請求必須要加上 `HMAC-SHA1` 加密過的參數才可以被 Serverless Image Handler 接受，步驟上為：

- 將請求的 Path 以 HMAC-SHA1 算法與你設定的密鑰加密為 Signature
- 將 Signature 以 URL Safe Base64 算法編碼
- 將請求網址改為：https://[CLOUDFRONT_ENDPOINT]/[ENCODED_SIGNATURE]/[原先的請求 PATH]

更多相關資訊，詳見

- [AWS Serverless Image Handler Implementation Guide 關於 Security 的章節](https://docs.aws.amazon.com/en_us/solutions/latest/serverless-image-handler/deployment.html)。
- [AWS Serverless Image Handler Implementation Guide Appendix D: Safe URL](https://docs.aws.amazon.com/en_us/solutions/latest/serverless-image-handler/appendix-d.html)。
- [Thumbor 文件關於 SafeURL 的章節](https://thumbor.readthedocs.io/en/latest/security.html?highlight=safe%20url)

## 黑魔法?

截至目前為止，我們好像都沒有實際看到 AWS 幫我們部署到 Lambda 上面的 Code、也沒有看到 CloudFormation Template 裡面的內容，感覺好像裡面有很多黑魔法發生，其實 Serverless Image Handler 的原始碼開源在 AWS Labs 的 GitHub 帳號中，可以前往 [Serverless Image Handler 的 Repo](https://github.com/awslabs/serverless-image-handler) 中檢視完整的原始碼，甚至加上自己需要的功能之後部署自己的版本，在 Repo 的 README 中有關於如何打包新的 Lambda Function 的教學。

## Auto WebP
當瀏覽器支援 WebP 這個較好的壓縮格式時，瀏覽器會在請求的 Header 中加上類似的 `Accept: image/webp,image/*` 設定，Thumbor 便能接收這樣的設定並自動以 `image/webp` 回傳。

由於 AWS Serverless Image Handler 的 Lambda Function 其實只是幫你運行了 Thumbor，你可以輕易的在 Lambda Environments 中加上新的設定來開啟這樣的功能。

- 新增新的 Environment Variables `AUTO_WEBP` 為 `True`
- 在對應的 CloudFront 中允許 Accept Header 作為 Caching 條件

讓我們透過 CURL 來檢查一下結果，如果是沒有對應 Accept Header 的請求，預設以原始格式回傳：

```shell
curl -I "https://CLOUDFRONT_ENDPOINT/500x200/prop/5/8856b82425b926b2d93ef314e893e0a7.jpg"

HTTP/2 200
content-type: image/jpeg
content-length: 25121
date: Tue, 22 Jan 2019 14:00:13 GMT
x-amzn-requestid: 09c9e79d-1e4e-11e9-9aaf-6748fac7bc66
x-amzn-remapped-content-length: 25121
x-amz-apigw-id: T6I9EFhAtjMFnHg=
cache-control: max-age=31536000,public
expires: Wed, 22 Jan 2020 14:00:13 GMT
etag: "3e260286d1529193c185ffa93650ee4d37166ed4"
x-amzn-trace-id: Root=1-5c4721ed-c9282248e551fab4a0798714;Sampled=0
x-amzn-remapped-date: Tue, 22 Jan 2019 14:00:13 GMT
vary: Accept
x-cache: Miss from cloudfront
via: 1.1 fbf94e317a2eadeb551cc7c3ef6e546d.cloudfront.net (CloudFront)
x-amz-cf-id: _Mc6-ERgc6my1EpWsEIIjM-7aUr9ELAqYXCULfrCEz7pYfEFmG1uJQ==
```

如果是有 Accept Webp 格式的請求：

```shell
curl -I --header "accept: image/webp,image/*,*/*;q=0.8" "https://CLOUD_FRONT_ENDPOINT/500x200/prop/5/8856b82425b926b2d93ef314e893e0a7.jpg"
HTTP/2 200
content-type: image/webp
content-length: 17458
date: Tue, 22 Jan 2019 13:55:18 GMT
x-amzn-requestid: 58bfca53-1e4d-11e9-8e00-63a2ea8deee6
x-amzn-remapped-content-length: 17458
x-amz-apigw-id: T6IOpEdrtjMFc5Q=
cache-control: max-age=31536000,public
expires: Wed, 22 Jan 2020 13:55:18 GMT
etag: "a4fdc702a62407d8d08fdefdeaccb2279bf282fd"
x-amzn-trace-id: Root=1-5c4720c4-6329e9b86ed8d27cf33ed564;Sampled=0
x-amzn-remapped-date: Tue, 22 Jan 2019 13:55:17 GMT
vary: Accept
age: 421
x-cache: Hit from cloudfront
via: 1.1 3c61ae3f6890de150027c363309d9c7f.cloudfront.net (CloudFront)
x-amz-cf-id: z0i0Yn3WBtjzMlVDId0Do1GjNUQMIRs3p8hMA9b2i0sqvdarhGUIfg==
```

可以看到相同大小的圖片請求，硬是小了 30% 的大小，而且透過 Accept Header 判斷回傳格式，還可以確保 HTML DOM 節點的乾淨，是個非常優雅的解決方法。

## Known Issues

這個方案也並非盡善盡美，除了上述提到的不支援 Multiple CORS Origin 設定、Demo UI 無法跟現存的 Bucket 並用外，這篇文撰寫時最新的 Serverless Image Handler 版本 `3.1.0` 所搭配的 Thumbor 版本為 `6.5.1`，在處理透明 PNG 的智慧裁切時會遇到預期外的錯誤，暫時也不支援 SVG 的圖片格式。

另外由於 Lambda 服務本身對於 Response Body 的限制，若裁切後的圖大於 6MB 可能會造成回傳失敗。

## 結語

AWS Serverless Image Handler 結合了 S3 Bucket 的儲存服務、API Gateway 跟 AWS Lambda 搭建出動態縮圖 API，並以 CloudFront 作為 CDN 快取服務，可算是一個相當完整且具有潛力的解決方案，雖然目前仍有些功能上的欠缺或是問題，但是使用者可以透過開源的原始碼自行針對自己的需求客製。

Lambda 的平行處理及優異的效能，讓自行搭建 On Demand Image Processing Service 這件事情變為不再遙不可及，也讓工程師能夠專心於提供使用者更好的服務體驗。


post-透過 AWS ServerlessImageHandler 實現動態圖片處理

透過 AWS ServerlessImageHandler 實現動態圖片處理


跑在瀏覽器上的組合語言？在 ban 了 flash 之後，大家在尋找是否有其他可以在瀏覽器上執行原生程式的方案，又或者只是不想寫 Javascript...Webassembly 這個標準被提出了（以下簡稱 wasm），可以是 C/C++ 這種靜態語言的編譯目標，也就是我們可以把現有的 C/C++ 專案編譯成 wasm，[有人就嘗試把 ffmpeg 編譯到瀏覽器上執行](https://www.youtube.com/watch?v=GsGPWSUmP8s)，後來 [golang](https://github.com/golang/go/wiki/WebAssembly) 以及 [rust](https://rustwasm.github.io/book/) 也可以編譯成 wasm ，今天來用 [rust](https://www.rust-lang.org/) 試試看 wasm 吧

> 基本上這篇我是看著 https://rustwasm.github.io/book/ 做的

## Rust

我選擇 rust 純粹只是因為我沒用過，聽說對於 concurrent 有一套很獨特的概念，想嘗試看看而已，首先來把 rust (`rustup`) 安裝起來：https://www.rust-lang.org/tools/install

我對 `rustup` 的理解： rust 官方的 rust 版本管理器

安裝完成之後，安裝現在的 rust 穩定版

```shell
rustup toolchain install stable
rustup default stable
```

## 準備 rust wasm 開發環境以及工具

基本上現在使用 wasm 的方法是比較像是寫底層原生程式給 js 呼叫，[必須先用 js 載入 wasm，接著用 js 呼叫 wasm 的 exports](https://developer.mozilla.org/en-US/docs/WebAssembly/Using_the_JavaScript_API#Streaming_the_WebAssembly_module)

但是要怎麼讓編譯器知道哪些東西要給 js 呼叫？js 跟 rust 互傳變數/資料的時候如何各自表述？甚至載入 wasm 可能各家瀏覽器的 API 都不盡相同...幸好 rust wasm 已經有許多現成的工具包幫我們解決這些問題，所以接下來要先來把開發環境準備好

### `wasm-pack`

首先 [wasm-pack](https://github.com/rustwasm/wasm-pack) 是 rust 跟 js 橋樑的核心，它的 macro 讓指定的 rust 函式以及資料結構提供給 js 端使用，當然也就處理了兩邊的資料轉換，最後它還幫忙生成 js 讓 webapp 端可以直接 import 使用

```shell
cargo install wasm-pack
```

> `cargo` 是 rust 的 `npm` / `gem` / `bundle`，我的理解是這樣

### `cargo-generate` & `wasm-pack-template`

同時也有人弄了新手模板 [wasm-pack-template](https://github.com/rustwasm/wasm-pack-template)，但是為了使用他我們要裝 `cargo-generate`，於是乎：

```shell
cargo install cargo-generate
```

### `create-wasm-app`

rust 的部份準備好了，但是我們要怎麼弄個能夠載入 wasm 的 webapp？還有個 wasm webapp 的新手模板 [create-wasm-app](https://github.com/rustwasm/create-wasm-app)，這個幫你把 [webpack](https://webpack.js.org/) 設定值都準備好，而且就是拿來跟 `wasm-pack-template` 搭配使用的，但是也意味著我們需要 [nodejs](https://nodejs.org/en/)，而且我用 nodejs `11.6.0` 才能用 npm 從模板建立專案

```shell
node -v # => v11.6.0
npm install -g create-wasm-app
```

## 終於可以來建立專案囉

這邊建立一個叫做 `wasm-glife` 的 [wasm-pack-template](https://github.com/rustwasm/wasm-pack-template) 專案：

```shell
cargo generate --git https://github.com/rustwasm/wasm-pack-template -n wasm-glife
cd wasm-glife
```

還沒完，還要把 webapp 建立起來，弄個 `www` 資料夾來放 webapp：

```shell
mkdir www
cd www
npm init wasm-app
npm install
```

## 看來產生不少東西，看一下哪些檔案值得我們關心

```
tree .
.
├── Cargo.toml <= 給 rust 的 package.json
├── LICENSE_APACHE
├── LICENSE_MIT
├── README.md
├── src
│   ├── lib.rs <= 將會是接下來的重頭戲，我們會在這邊定義給 js 呼叫的東西
│   └── utils.rs
├── tests
│   └── web.rs
└── www <= 大家熟悉的 webpack 專案
    ├── bootstrap.js
    ├── index.html
    ├── index.js <= 將會在這邊呼叫 rust wasm
    ├── LICENSE-APACHE
    ├── LICENSE-MIT
    ├── package.json
    ├── package-lock.json
    ├── README.md
    └── webpack.config.js
```

#### `Cargo.toml`

```toml
[dependencies]
cfg-if = "0.1.2"
wasm-bindgen = "0.2"
```

這邊最重要的就是 `wasm-bindgen` 這個套件，待會會看到相關的 macro

#### `src/lib.rs`

[wasm-pack-template](https://github.com/rustwasm/wasm-pack-template) 產生的 `src/lib.rs` 一開始引入一些東西，configure 一些東西，先不管他，下面這兩個已經完整示範了要怎麼在 rust 使用 js function 以及把 rust function 提供給 js 使用

```rust
#[wasm_bindgen]
extern {
    fn alert(s: &str);
}

#[wasm_bindgen]
pub fn greet() {
    alert("Hello, wasm-glife!");
}
```

* `#[wasm_bindgen]` macro 加上 `extern` 表示從 js 拿哪些 function 使用，這邊把我們常用的 `alert` 拿進來
  * [有想法的人應該已經想到問題了，可以看一下 wasm_bindgen 更詳細的說明](https://rustwasm.github.io/wasm-bindgen/examples/import-js.html)
* `#[wasm_bindgen]` macro 加上 `pub fn ...` 讓 js 可以呼叫哪些 rust function，這邊把 `greet` 拿出去給 js 呼叫

#### `www/index.js`

```javascript
import * as wasm from "hello-wasm-pack";

wasm.greet();
```

js 這邊就把 wasm 當成一般的 ES module 引入，接著呼叫 `greet()`

但是我們現在還沒編譯 rust 到 wasm，這時直接去跑 webpack 是編譯不過的，畢竟 `hello-wasm-pack` 還沒編譯出來

## 編譯 rust 到 wasm

```shell
rustup run stable wasm-pack build -d www/wasm
```

* `rustup run stable ...` 的部份，我想是類似 `bundle exec ...`，去執行對應 rust 版本的執行檔
* `wasm-pack build` 就能編譯這個 rust 專案成一個 node module
  * `-d www/wasm` 則是讓編譯出來的 node module 放在 `www/wasm`

按下 enter 之後就會開始下載 dependency，編譯，第一次編譯約莫幾分鐘

> [線上書的做法是產生一個真的 local npm module...](https://rustwasm.github.io/book/game-of-life/hello-world.html#using-our-local-wasm-game-of-life-package-in-www)但是我覺得沒必要這麼麻煩，直接把東西丟在 webpack 專案裡頭就能用了

## 串到 webapp

`wasm-pack` 成功之後會產生蠻多東西的，不過我們 focus 在產生的 node module

```
tree .
...
└── www
    ├── bootstrap.js
    ├── index.html
    ├── index.js
    ├── LICENSE-APACHE
    ├── LICENSE-MIT
    ├── package.json
    ├── package-lock.json
    ├── README.md
    ├── wasm <= wasm-pack 編譯出來的 node module
    │   ├── package.json <= "module": "wasm_glife.js"
    │   ├── README.md
    │   ├── wasm_glife_bg.d.ts
    │   ├── wasm_glife_bg.wasm <= 就是我，wasm
    │   ├── wasm_glife.d.ts
    │   └── wasm_glife.js <= wasm-pack 會把必要的橋接產生在這
    └── webpack.config.js
```

因為產生的是 node module，透過 webpack 可以直接 import 使用，我們只要把 `www/index.js` import 改成

```javascript
import * as wasm from "./wasm";
```

接著把 webpack 跑起來

```shell
npm run start
```

用[支援 wasm 的瀏覽器](https://caniuse.com/#feat=wasm)打開 http://localhost:8080/ 應該可以看到：

![post-Webassembly - run native code on browser using Rust](//images.ctfassets.net/8er52l3j5u76/sHoje69SaGqq0pT3UvuAd/43480e7629a1afe4398aba3047b1c7b4/9PxdcQ7.png)

在打開瀏覽器開發工具切到 Network tab，確實可以看到 wasm 被載入了：

![post-Webassembly - run native code on browser using Rust](//images.ctfassets.net/8er52l3j5u76/6tSTZNDdZcXsVl7wMz3FsA/0bcd4ee963a364154461f8678fca8eb0/1oYjh7R.png)

wasm 是 binary 格式的，需要用工具才能轉回可讀的文字：

![post-Webassembly - run native code on browser using Rust](//images.ctfassets.net/8er52l3j5u76/43B939WRD5hgp9copcxhpV/06ce75b7f82ea9c3c77f97d9b79d62db/Jm7ZdIT.png)

最後偷瞄一下 webpack 怎麼幫我們載入 wasm 的 (`bootstrap.js`)：

![post-Webassembly - run native code on browser using Rust](//images.ctfassets.net/8er52l3j5u76/5lbWXLYGCII6HePMUdmu8e/503a45ecaf91bbbbb23bd21d49bf96fe/eRd7MXb.png)

## 實做一些東西來玩玩：Conway's game of life

因為我看的這本線上書就是要來做 [Conway's Game of Life](https://zh.wikipedia.org/wiki/%E5%BA%B7%E5%A8%81%E7%94%9F%E5%91%BD%E6%B8%B8%E6%88%8F)，基本上就是在一個棋盤上，每個格子可以是死亡或是存活兩種狀態，並且會根據周圍 8 格鄰居格子的狀態決定下回合的狀態

但是我對 rust 還沒這麼熟，所以就邊看邊抄，邊抄邊學，嘗試寫成自己的版本：https://github.com/pastleo/rs-wasm-glife/

* [src/universe.rs](https://github.com/pastleo/rs-wasm-glife/blob/master/src/universe.rs) 實做[核心資料結構](https://github.com/pastleo/rs-wasm-glife/blob/master/src/universe.rs#L10)以及[演算法](https://github.com/pastleo/rs-wasm-glife/blob/master/src/universe.rs#L67)
* [src/main.rs](https://github.com/pastleo/rs-wasm-glife/blob/master/src/main.rs) 讓我可以編譯成傳統 binary 執行檔在 console 上執行並印出棋盤
* [src/lib.rs](https://github.com/pastleo/rs-wasm-glife/blob/master/src/lib.rs#L47) 包裝成 `Game` class 給 js 使用
* [www/index.html](https://github.com/pastleo/rs-wasm-glife/blob/master/www/index.html) 以及 [www/index.js](https://github.com/pastleo/rs-wasm-glife/blob/master/www/index.js) 實做使用者界面
  * [`game.isChanged(i)`](https://github.com/pastleo/rs-wasm-glife/blob/master/src/lib.rs#L63) 決定[是否要 toggle css class](https://github.com/pastleo/rs-wasm-glife/blob/master/www/index.js#L48) 避免不必要的 DOM 改動
  * 使用者可以[按格子](https://github.com/pastleo/rs-wasm-glife/blob/master/www/index.js#L97)來[更改狀態](https://github.com/pastleo/rs-wasm-glife/blob/master/src/lib.rs#L67)

我也把東西放到網站上大家可以上去玩玩：https://static.pastleo.me/rs-wasm-glife/

[結果影片](https://www.youtube.com/watch?v=6PRM-iyNo80&feature=emb_title&ab_channel=%E9%82%B1%E5%86%A0%E5%96%BB "結果影片")

> 蠻好玩的，我可以玩很久

## 心得

其實 conway's game of life 用 rust -> wasm 很可能沒有比純 js 實做來的快，說不定光是在 rust 跟 js 之間的資料轉換的效能犧牲就已經不值得了，現在 wasm 是以 MVP 的概念先在各家瀏覽器支援，我個人比較期待的是還沒定案的這兩個功能：

* [threading](https://github.com/WebAssembly/threads) 讓支援 threading 加速的 C/C++ 程式發揮優勢
* [GC](https://github.com/WebAssembly/gc) 讓瀏覽器執行 ruby, erlang, elixir 等 runtime

這幾天就花點時間試試看 wasm，體驗一下在自己機器開發/執行的感覺（話說在 android chrome 跟 ios safari 都跑得起來）順便學一下 rust


post-Webassembly - run native code on browser using Rust

Webassembly - run native code on browser using Rust

post-Git 面試題 / cover

Git 面試題


# 第一次用 Flex 切版就上手

## 前言

`flex` 是在 CSS3 發佈的屬性，目的是為了讓大家使用 `flex` 後能更有效率的達成想要的切版效果，像是大家在排版的時候，是不是常常會遇到垂直置中的問題呢？因此有很多人會特別整理出 「垂直置中的 X 個方法」這類型的文章，而今天要介紹的 `flex` 排版法，則是其中一種可以方便大家在切版時隨時設定垂直對齊的排版方法。那麼，我們就直接來介紹 `flex` 的使用方式吧！

## Flex 的屬性使用教學

### 設定父層的 `display` 為 `flex` 或 inline-flex

`display: flex | inline-flex`

要使用 `flex` 排版的物件，首先父層的 `display` 一定要設定為 `flex` 或 `inline-flex`，這樣父層裡的子元件才能吃到 `flex` 的屬性設定，而屬性值 `inline-flex` 則能讓父層保有 `inline-block` 的特性。

### 利用 `flex` 設定父層內的子元件大小（`flex-grow`、`flex-shrink` 和 `flex-basis`）

#### flex-grow
`flex-grow` 是指當父層的總空間分配給所有子元件後，如果空間還有剩下來的話，設定了 `flex-grow` 的子元件可以從剩下的空間裡額外得到多少比例的空間，在沒有設定之前 `flex-grow` 的預設值為 0，表示在沒有設定的狀態下子元件都只會照自己原本的元件空間顯示，不會去佔多餘的父層空間，但是當有子元件被設定了 `flex-grow` 的時候，父層剩下的空間則會依照子元件們 `flex-grow` 的總和去分配每個元件額外可以分到多少空間，例如父層的寬度是 `300px`，而父層的下面有三個子元素，分別是 .a .b 和 .c 這三個子元素的寬度各是 `50px`，當 `flex-grow` 沒有設定屬性值或屬性值為 0 的時候，那 .a .b 和 .c 佔據的寬度就會是他們原始的寬，也就是 `50px`，但當 .a 設定 `flex-grow: 1` 時，父層剩下的空間將會分成一等分分給 .a，所以實際呈現的樣子就會是：

- 父層剩下的空間 = 300px - 50px(.a 的寬) - 50px(.b 的寬) - 50px(.c 的寬) = 150px
- .a 的寬 = 50px(.a 原始寬) + 150px(父層剩下的空間) = 200px
- .b 和 .c 則維持原本的 50px 不變

而當我們設定了 .a 的 flex-grow 為 2，.b 的 flex-grow 為 1 時，則會像下面這樣：

- 父層剩下的空間 = 300px - 50px(.a 的寬) - 50px(.b 的寬) - 50px(.c 的寬) = 150px
- 每一份 flex-grow 所佔據的寬 = 150 / 3(.a 的 `flex-grow: 2;` + .b 的 `flex-grow: 1;`) = 50px
- .a 的寬 = 50px(.a 原始寬) + 50px * 2(有兩份 flex-grow) = 150px
- .b 的寬 = 50px(.b 原始寬) + 50px * 1(有一份 flex-grow) = 100px
- .c 的寬維持原本的 50px 不變

#### flex-shrink
若說 `flex-grow` 代表的是子元件的伸展性，那 `flex-shrink` 則是指子元件的收縮性，當父元素的空間不夠放入所有子元件時，`flex-shrink` 的數值就控制了子元件是否能夠被收縮（預設值為 0，也就是不能收縮），以及整體收縮的比例是多少（屬性值越大則收縮的幅度越大）。

#### flex-basis
`flex-basis` 指的則是子物件的最小寬度或高度（這裡的指的是寬或高是由 `flex-direction` 的設定值來決定，`flex-direction` 將在本文後面詳述），依照上述的例子 .a .b 和 .c 的原始寬度 50px 就是利用此屬性進行設定。

而上述的三種屬性可以簡寫在一個 `flex` 屬性內，寫法是： `flex: flex-grow` 的值 `flex-shrink` 的值 `flex-basis` 的值 ;。

### 在父層設定 `flex-flow` 決定子元素的排序方向還有是否換行（`flex-direction` 和 `flex-wrap`）

#### flex-direction 可以決定子元件的排序方向

`flex-direction: row | row-reverse | column | column-reverse`

我們可以從父層設定子層物件的排列方式，在沒有設定的狀態下預設的屬性值是 `row` （使物件由左至右排序），而 `row-reverse` 則能使物件以相反方向排序（由右至左），如果希望物件是以垂直的方式編排，我們則會使用屬性值 `column`（使物件由上至下排序）或是 `column-reverse`（使物件由下至上排序）進行排序。

#### flex-wrap 則決定了子物件是否可以換行

`flex-wrap: nowrap | wrap | wrap-reverse`

`flex-wrap` 預設的屬性為 `nowrap` 不換行，`wrap` 為換行，`wrap-reverse` 為換行且排序方式與 `wrap` 相反。

`flex-direction` 和 `flex-wrap` 可以簡寫為 `flex-flow`，寫法為：`flex-flow: flex-direction的值 || flex-wrap的值`。

### 子物件的對齊設定

#### justify-content

`justify-content: flex-start | flex-end | center | space-between | space-around;`

`justify-content` 會依照我們設定的 `flex-direction` 方向，移動子物件的對齊位置，以 `flex-direction: row;`為例，當我們設定 `justify-content: flex-start;` 時子物件會向左靠齊、`flex-end` 會向右靠齊、`center` 會使子物件置中對齊、`space-between` 會讓第一個子物件靠左，第二個子物件靠右，並使剩下的物件等距對齊，而 `space-around` 則會在左右都不靠齊父層的狀況下等距對齊所有子元素。

#### align-items

`align-items: flex-start | flex-end | center | baseline | stretch;`

`align-items` 對齊的方向與 `justify-content` 相反，像當 `flex-direction: row;` 的時候 `justify-content` 控制的是子元素的左右對齊，那 `align-items` 就是控制子元素跟子元素之間的上下對齊，反之，當 `flex-direction: column;` 的時候 `justify-content` 控制的是子元素的上下對齊，那 align-items 就是控制子元素跟子元素之間的左右對齊，我們這裡一樣以 `flex-direction: row;` 為例，當我們設定 `align-items: flex-star;` 時子元素就會向上對齊、`flex-end` 時會向下對齊、`center` 時會置中對齊、baseline 時會以物件的基準線為主進行對齊，而 `stretch` 則可以自動將子元素的高度延展成一樣的高度。

#### align-content

`align-content: flex-start | flex-end | center | space-between | space-around | stretch;`

`align-content` 是多行的屬性，當子元素的數量多到換行時 `align-content` 會對整個子元素區塊設定對齊方式，而屬性值代表的意思與上述的屬性值大多相同，故此不再復述。

## 結語

透過 `flex` 的對齊特性，我們可以用更方便的方式佈局我們要切的畫面，希望這篇文章能幫助大家在未來實作時能有更多切版屬性的選擇，如果對文章有任何問題也歡迎提出來一起討論。

---

>  👩‍🏫  __課務小幫手：__
>  
> ✨ 想掌握 HTML 觀念和原理嗎？
>
> 我們有開設 🪁 [HTML 網頁設計新手村](https://5xruby.tw/courses/html) 課程唷 ❤️️
>


post-第一次用 Flex 切版就上手 - cover

第一次用 Flex 切版就上手


React 16.3.0 發佈了關於 lifecycles methods 的更新，新增了 method：`getDerivedStateFromProps` 和 `getDerivedStateFromError`，因為原有的 lifecycle method: `componentWillMount`, ` componentWillReceiveProps` 和 `componentWillUpdate` 經常讓人誤解誤用，造成許多實作上的程式漏洞。所以在這次 React 16 更新之後，為了幫助理解這些 lifecycle methods 使用的時機，下面將會分成四個部分來介紹：mounting, updating, unmounting 和 errors。

說明文章使用範例：一個類似 Pinterest 的瀑布流式簡單應用。預設每兩秒會在最下面載入一些需要加入排列的 blocks。

[範例結果](https://blissful-ptolemy-8b66a6.netlify.com/)

[範例程式碼](https://github.com/fokayx/react-lifecycle-example)

這邊會使用 `bricks.js` 這個 library 來處理頁面的佈局，`bricks.js` 是一個不錯工具，但其實他和 react 並沒有很麻吉，他和 `vanilla JavaScript` 或者 `jQuery` 還更合拍。那為什麼要故意用 `bricks.js` 呢？因為在 lifecycle methods 裡面常常需要整合各種 non-React 套件，在實作上許多好的套件並不只是為 React 而生，而 lifecycle methods 就在這其中扮演一個橋樑的角色。

One more thing：總之呢～lifecycle methods 他們 hen 容易你的程式越來越複雜，不到最後關頭絕不輕言呼叫。

## Mounting
### constructor
當 React 元件是一個 `class component` ，那麼當他誕生時呼叫的第一個方法就是 `constructor`，也就是說一個 `functional component` 是不會有這個方法的唷，可能長得有點像這樣：

```
class MyComponent extends Component {
  constructor(props) {
    super(props);
    this.state = {
      counter: 0,
    };
  }
}
```

`constructor` 的使用伴隨著 component 相關的 props，所以你必須一併呼叫 `super` 並且傳入 `props`。
在這邊可以設定整個元件 `state` 的初始值，也可以使用 props 的傳入來設定，例如：

```
class MyComponent extends Component {
  constructor(props) {
    super(props);
    this.state = {
      counter: props.initialCounterValue,
    };
  }
}
```

`constructor` 不是一個必須翻牌的方法，不找他也沒有關係，如果只是為了要設定 state 的初始值，只要 `Babel` 設定有支援 [`class fields`](https://github.com/tc39/proposal-class-fields)，下方這樣的寫法也是可以預設 state 的初始值：

```
class MyComponent extends Component {
  state = {
    counter: 0,
  };
}
```

這種寫法少了幾行相對好像比較受喜愛，要從 props 取得設定值也沒有問題：

```
class MyComponent extends Component {
  state = {
    counter: this.props.initialCounterValue,
  };
}
```

那麼 `constructor` 不就沒有存在的必要了嗎？其實他還有另外一個作用就是設定 `ref`，例如範例中：

```
class Grid extends Component {
  constructor(props) {
    super(props);
    this.state = {
      blocks: [],
    };
    this.grid = React.createRef();
  }
```

React 元件需要 `constructor` 來呼叫 `createRef`，才能給例子中的 grid 建立 reference，之後再傳給 `bricks.js` 使用。

`constructor` 還可以用來 binding function，來這裡 [React Binding Patterns: 5 Approaches for Handling `this`](https://medium.freecodecamp.org/react-binding-patterns-5-approaches-for-handling-this-92c651b5af56) 看更多。

最佳使用時機：設定 state、建立 refs 和 function binding。

### getDerivedStateFromProps (new)

在元件 mouting 階段 render 之前，最後被呼叫的方法就是 `getDerivedStateFromProps`，可以在這個方法裡面用初始的 props 設定 state，如範例的 `Grid` 元件：

```
static getDerivedStateFromProps(props, state) {
  return { blocks: createBlocks(props.numberOfBlocks) };
}
```

這裡使用 `numberOfBlocks` 這個 prop 來生出大小隨機的區塊，然後回傳一個 state object。回傳後用 `console.log(this.state)` 印出來會長得像這樣：

```
console.log(this.state);
// -> {blocks: Array(20)}
```

從 props 設定 state 這段程式碼完全可以放在 `constructor`，拿來放在 `getDerivedStateFromProps` 好處是更加的直覺，他就純粹是用來設定 state，但在 `constructor` 裡面是還有可能做一些其他的事。

最佳使用時機 ( mount 階段 )：回傳設定值來自初始 props 的 state object。

### render
回傳 JSX 長出 React 元件的地方，在 React 這個框架會花蠻多時要在這裡作業。

最佳使用時機：回傳生出元件的 JSX。

### componentDidMount
當元件第一次長出來的時候這個方法就會被呼叫，如果你需要載入資料用 AJAX、fetch 之類的動作就是在此時進行，千萬不要在 `constructor`、`render` 或其他地方去發出這些的請求，有一個叫 [Tyler McGinnis](https://twitter.com/tylermcginnis33) 是這麼說的：

> 因為無法確保 AJAX / fetch 的結果會在什麼時候完成，如果在元件長好之前就載完了，那就表示你對一個還沒長出來的元件進行 `setState`，這樣是沒有作用的，而且 React 也不希望這麼做，會生出一堆討厭的警告。

在 `componentDidMount` 裡面還能做許多有趣的事，

- 在剛生成的 `<canvas>` 上畫點東西
- 把一堆資料塞入一個瀑布流的佈局畫面
- 設定 `event listeners`

基本上就是在這邊處理那些有 DOM 之後才能做的事，或進行取得元件所需要的資料。
例如：

```
componentDidMount() {
  this.bricks = initializeGrid(this.grid.current);
  layoutInitialGrid(this.bricks)

  this.interval = setInterval(() => {
    this.addBlocks();
  }, 2000);
}
```

例子中使用 `brick.js` 裡面的方法 `initalizeGrid` 來產生 grid。然後每二秒新增更多的 blocks，模擬實際上在用 `loadRecommendations` 時更多的載入資料。

最佳使用時機：送出 AJAX、fetch 等等來載入元件所需的資料。

## Updating
### getDerivedStateFromProps
唉〜這剛剛不是出現過！是的沒錯，但這個時候的用處比剛剛多了些。
如果需要用 `props`  更新 `state` 的話，可以在這裡處理然後回傳新的 state object。不過呢最好不要在這裡用 `props` 來更新 `state`，最好認真地確認需不需要用這個方式把 state 存下來？

在下面的一些情況下可以在這個方法裡面處理，但通常是不建議這麼做：

- 當 source 更新的時候重新設置 video 或 audio 元件。
- 在 server 更新的時候，更新 UI 元件
- 在內容改變的時候，關閉 accordinon 元件。

在我們的範例中 `Grid` 這個元件有一個 `numberOfBlocks` 的 props ，但因為這個也屬於 Update 的一種，所以這裡的意思就是：如果元件 state 的blocks 大於零的話就回傳一個空的 object，不然就用 `numberOfBlocks` 這個 props 進行 state 的更新：

```
static getDerivedStateFromProps(props, state) {
  if (state.blocks.length > 0) {
    return {};
  }
  return { blocks: createBlocks(props.numberOfBlocks) };
}
```

也就是說如果原本 state 的 block 數超過新的 props，就不更新 state，直接回傳一個空的 object。

註：關於 `static` 方法，例如 `getDerivedStateFromProps` 是無法透過 `this` 來控制元件的，所以無法處理 grid ref。

最佳使用時機：透過 props 更新 state，

### shouldComponentUpdate (new)
在 React 的信念裡面當元件收到新的 props 或是 新的 state 就要更新一下。只是元件本人有點小小的焦慮，覺得更新之前要先請示。因此誕生了 `shouldComponentUpdate` 這個方法，傳入 `nextProps` 和 `nextState` 當參數。

`shouldComponentUpdate` 只會回傳 boolean 值，預設是回傳 true，就好像這個元件問主人說：我應該 re-render 嗎？主人：喔，小可愛，是的，你應該這麼做。透過這個方法，可以確認元件不會沒事就隨便 render，能夠提昇一些效能。

關於 `shouldComponentUpdate` 的參考用法之一 [How to Benchmark React Components: The Quick and Dirty Guide](https://engineering.musefind.com/how-to-benchmark-react-components-the-quick-and-dirty-guide-f595baf1014c)

在上面的文章裡提到的例子：一個 table 有許多的欄位，問題出於如果 table re-render，所有的欄位就算沒有需要更新也必須跟著一起 re-render，這樣的確是會拖慢效能。`shouldComponentUpdate` 就能做到只有在特定 props 改變的時候再進行更新。

貼心小提示：如果元件在這個方法裡面做了一些設定，那麼元件就不會跟一般的元件一樣進行更新，有時候 bug 就出現在我們忘了這些特別的手動設定，請小心服用。

範例裡面在前一個 `getDerivedStateFromProps` 方法寫了：在某些時候忽略新的 `this.props.numberOfBlocks`。但因為 React 預設是只要收到新的 props 就要 re-render，所以元件還是會再重新 render 一次，這樣確實是浪費效能沒必要。使用 `shouldComponentUpdate` 處理一下，讓元件只有在新的 blocks 多於 state 的 blocks 的時候再進行更新唷。

```
shouldComponentUpdate(nextProps, nextState) {
  // Only update if bricks change
  return nextState.blocks.length > this.state.blocks.length;
}
```

最佳使用時機：需要精準地掌控元件應該在什麼時候 re-render 的各位。

### render (和 `Mounting` 的時候一樣)

### getSnapshotBeforeUpdate (new)
`getSnapshotBeforeUpdate` 是出現在 render 前的最後一個方法，在這裡可以看元件在此時此刻的 state 和 props 最後一眼。呃～呼叫這個方法的話不是會在 render  前增加一點小延遲嗎？總是有些情況是會需要知道現況，然後和即將進行的 render 作個整合，例如：

```
getSnapshotBeforeUpdate(prevProps, prevState) {
  if (prevState.blocks.length < this.state.blocks.length) {
    const grid = this.grid.current;
    const isAtBottomOfGrid =
      window.innerHeight + window.pageYOffset === grid.scrollHeight;
    return { isAtBottomOfGrid };
  }
  return null;
}
```

在範例中是用在當使用者滾到網頁的最下方，如果有新的 blocks 載入的話要保持畫面停留在底部，然後回傳一個 object　如：`isAtBottomOfGrid`，不然的話就來個 `null`。不管如何在 `getSnapshotBeforeUpdate` 這個方法就是要回傳個什麼值，不然就要設為回傳 `null`。 Oh my god why！ 讓我們繼續看下去。

最佳使用時機：處理將要 render 的元件針會其中的某些屬性，接著會把值傳給 `componentDidUpdate`。

### componentDidUpdate
來到這裡終於把元件更新完畢，在 `componentDidMount` 這個方法可以獲得三個 props：`previous state`、`previous props` 和 一些來自剛剛 `getSnapshotBeforeUpdate` 的東西，例如：

```
componentDidUpdate(prevProps, prevState, snapshot) {
  this.bricks.pack();
  if (snapshot.isAtBottomOfGrid) {
    window.scrollTo({
      top: this.grid.current.scrollHeight,
      behavior: 'smooth',
    });
  }
}
```

以上的意思是：用 Bricks.js 的方法 `pack` 重新佈局 grid，然後從剛剛的 `getSnapshotBeforeUpdate` 這邊得知使用者處於 grid 最下方的狀態，所以在有新的 blocks 誕生的時候一樣能停在 grid 的最下方。

最佳使用時機：在 DOM 更新之後做一些對應。

## Unmouting
### componentWillUnmount
嗨~ 大家今天到這裡過得好嗎？小元件們走到現在也是個要說再見的時候了，在告別之前可以在 `componentWillUnmount` 這個方法裡面做最後的掙扎。那麼可以用來幹啥呢？可以把和這個元件有關的一些用不著的 request、event listeners 統統移除，要走就要走得乾乾淨淨的。範例中在 `componentDidMount` 裡面設了一個 `setInterval` 在這邊要把他清掉：

```
componentWillUnmount() {
  clearInterval(this.interval);
}
```

最佳使用時機：在元件最後燒毀前清掉不需要遺留下的廢物。

## Errors
### getDerivedStateFromError
老天鵝，有子元件東西壞了啦，這時候應該要出現 error 畫面，一個最簡單的方法就是放一個類似 `this.state.hasError` 的設定，在發生 error 的時候可以用 `getDerivedStateFromError` 設成 `true`：

```
static getDerivedStateFromError(error) {
  return { hasError: true };
}
```

注意一點：`getDerivedStateFromError` 的回傳值只能是一包更新的 state object，其他啥也別做，要有什麼要處理的話留在下一個 `componentDidCatch` 方法再說。

最佳使用時機：更新 state 來呼叫 error 畫面。

### componentDidCatch
跟剛剛的 `getDerivedStateFromError` 有點像，`componentDidCatch` 也是在子元件有 error 的時候被觸發，區別在於在這個方法裡面可以做更多其他的處理，例如把 error log 下來：

```
componentDidCatch(error, info) {
  sendErrorLog(error, info);
}
```

上面的給的 `error` 參數是 error 訊息，例如：(Undefined Variable blah blah blah… )，`info` 就是 stack trace 那些 (In Component, in div, etc)。

`componentDidCatch` 只有 error 發生在 lifecycle methods 裡面的時候才有效，如果是從 click handler 來的 error 是不會被 catch 的唷。

通常這個方法會用在 error boundary 元件裡面，例如：

```
class ErrorBoundary extends Component {
  state = { errorMessage: null };
  static getDerivedStateFromError(error) {
    return { errorMessage: error.message };
  }
  componentDidCatch(error, info) {
    console.log(error, info);
  }
  render() {
    if (this.state.errorMessage) {
      return <h1>Oops! {this.state.errorMessage}</h1>;
    }
    return this.props.children;
  }
}
```

最佳使用時機：Catch 和 log errors。

結論：

React 16 lifecycle methods 將要廢除 `componentWilllMount`、`componentWillReceiveProps` 和 `componentWillUpdate` 這三個方法，然後新增 `getDerivedStateFromProps` 和 `getDerivedStateFromError` 這兩個方法。如果有用到被廢除的那三個方法，在 React 16  是還可以用使用沒問題，到了 React 17 也能用，只是會發出 `UNSAFE_` 的警告，不能預期的是也有可能造成一些 bug，希望大家能夠更無痛地使用這些 lifecycle methods。

REF:

- [React 16 Lifecycle Methods: How and When to Use Them](https://blog.bitsrc.io/react-16-lifecycle-methods-how-and-when-to-use-them-f4ad31fb2282)
- [React v16.3.0: New lifecycles and context API](https://reactjs.org/blog/2018/03/29/react-v-16-3.html)
- [Update on Async Rendering](https://reactjs.org/blog/2018/03/27/update-on-async-rendering.html)
- [Cover image](https://cdn-images-1.medium.com/max/2000/1*bqLzlcQEU8e7yWQ3tKSaxQ.png)

---

>  👩‍🏫  __課務小幫手：__
>  
> ✨ 想掌握 React 觀念和原理嗎？
>
> 我們有開設 💠 [React 全攻略入門班](https://5xruby.tw/courses/react) 課程唷 ❤️️
>


post-React 16：Lifecycle Methods 新手包

React 16：Lifecycle Methods 新手包


本文嘗試觀察 Rails 透過什麼方式來解析輸入的網址，找到對應的 controller action 以及 params，然後自幹一個。

### 參考資料
- [Rack 應用程式](https://railsbook.tw/extra/rack.html)
- [尝试理解 ActionDispatch::Routing::RouteSet](https://ruby-china.org/topics/30916)

由於篇幅的關係，請先花個 1～2 分鐘大概讀一下參考資料再繼續往下閱讀。

想要自幹一個 Rails Router 就要從了解 Rails Router 開始。

# 了解 Rails Router

在參考資料中，我們得到了一個寶貴的資訊：

> ActionDispatch::Routing::RouteSet 是一個 Rack App。

也就是說 RouteSet 有一個 call 方法，並且他會傳回符合 Rack 規範的內容。
[https://github.com/rails/rails/blob/master/actionpack/lib/action_dispatch/routing/route_set.rb#L832](https://github.com/rails/rails/blob/master/actionpack/lib/action_dispatch/routing/route_set.rb#L832)：

```ruby
def call(env)
  req = make_request(env)
  req.path_info = Journey::Router::Utils.normalize_path(req.path_info)
  @router.serve(req)
end
```

這就是 Rack App 的進入點。他在這裡是製作 request，然後丟給 `@router.serve` 方法去處理。

這個 @router 的 class 是 `ActionDispatch::Journey::Router`。

https://github.com/rails/rails/blob/master/actionpack/lib/action_dispatch/journey/router.rb#L31

```ruby
def serve(req)
  find_routes(req).each do |match, parameters, route|
    # 略
    status, headers, body = route.app.serve(req)
    # 略
    return [status, headers, body]
  end

  [404, { "X-Cascade" => "pass" }, ["Not Found"]]
end
```

大意：用 `find_routes` 找出對應的 route 之後，執行 `route.app.serve`。

這個 route 的 class 是 `ActionDispatch::Journey::Route`。

這個 route.app 的 class 是 `ActionDispatch::Routing::RouteSet::Dispatcher`。

我們繼續看他到底 serve 了什麼。
[https://github.com/rails/rails/blob/master/actionpack/lib/action_dispatch/routing/route_set.rb#L29](https://github.com/rails/rails/blob/master/actionpack/lib/action_dispatch/routing/route_set.rb#L29)：

```ruby
def serve(req)
  params     = req.path_parameters
  controller = controller req
  res        = controller.make_response! req
  dispatch(controller, params[:action], req, res)
rescue ActionController::RoutingError
  if @raise_on_name_error
    raise
  else
    [404, { "X-Cascade" => "pass" }, []]
  end
end

def controller(req)
  req.controller_class
rescue NameError => e
  raise ActionController::RoutingError, e.message, e.backtrace
end

def dispatch(controller, action, req, res)
  controller.dispatch(action, req, res)
end
```

在這裡可以看出，他直接從 `req.controller_class` 找到對應的 controller 並且做處理，然後就回傳結果了。

可以看出 controller class 需要支援兩個方法：
- make_response!(request)
- dispatch(action, request, response)

且 dispatch 的輸入值 response 正好就是 make_response! 的輸出。

# 自幹一個 Rack App

所以我們可以仿照參考資料的做法，自己做一個 Rack App 來試用看看：

首先弄一個空資料夾，然後在裡面建立一個 `config.ru` 檔案，內容如下：

```ruby
require 'action_dispatch'

class EtrexController
  def self.make_response!(request)
  end
  def self.dispatch(action, req, res)
    [200, {"Content-Type" => "text/html"}, ['QQ']]
  end
end

app = ActionDispatch::Routing::RouteSet.new

app.draw do
  get 'etrex', to: 'etrex#index'
end

run app
```

因為 make_response! 的輸出也只有我們自己用，所以就乾脆不在 make_response! 做事了。

你可以在 bash 下用 `rackup` 指令來執行這個 Rack App 。

接著在瀏覽器輸入對應的網址 [http://localhost:9292/etrex](http://localhost:9292/etrex) 就可以看到結果「QQ」。

# 繼續了解 Rails Router

我們已經知道整個 RouterSet 大概做了些什麼事，接下來我們就專注在本文重點：Router 是如何將 request 轉換為 controller action 和 params。

```ruby
def find_routes(req)
  routes = filter_routes(req.path_info).concat custom_routes.find_all { |r|
    r.path.match(req.path_info)
  }

  routes =
    if req.head?
      match_head_routes(routes, req)
    else
      match_routes(routes, req)
    end

  routes.sort_by!(&:precedence)

  routes.map! { |r|
    match_data = r.path.match(req.path_info)
    path_parameters = {}
    match_data.names.zip(match_data.captures) { |name, val|
      path_parameters[name.to_sym] = Utils.unescape_uri(val) if val
    }
    [match_data, path_parameters, r]
  }
end
```

這個程式碼很長，我們一段一段來解讀。

```ruby
  routes = filter_routes(req.path_info).concat custom_routes.find_all { |r|
    r.path.match(req.path_info)
  }
```

因為我先偷看了 filter_routes 的實作，所以我知道這段是用一個不單純的演算法，根據網址來排除 routes，而後面的 `.concat custom_routes ...` 可以先忽略，感覺不是重點。

```ruby
routes =
  if req.head?
    match_head_routes(routes, req)
  else
    match_routes(routes, req)
  end
```

這段則是根據 http method 來排除 routes。

```ruby
  routes.sort_by!(&:precedence)

  routes.map! { |r|
    match_data = r.path.match(req.path_info)
    path_parameters = {}
    match_data.names.zip(match_data.captures) { |name, val|
      path_parameters[name.to_sym] = Utils.unescape_uri(val) if val
    }
    [match_data, path_parameters, r]
  }
```

因為有可能多重 match，這裡就依照優先序排序，然後把所有結果都整理好傳回。同時，他也在這裡做了網址參數的解析。

其中的 r.path 的 class 是 ActionDispatch::Journey::Path::Pattern。

r.path.match 方法如下：

```ruby
def match(other)
  return unless match = to_regexp.match(other)
  MatchData.new(names, offsets, match)
end
```

我們從上而下的解讀，未必要完全理解，透過實際觀察其輸入輸出，就能知道他大概的意圖。

他這裡想要解析的參數是在 router 規則中的 `etrex/:id` 之類的變數。

舉例來說，我們會期待用一個 `get 'etrex/:id'` 來捕捉所有 `etrex/1`、`etrex/2`、`etrex/3`... 的網址。

而我們希望 router 能從中解析出參數 {id: 1}，而這段 match 就是在做這件事。

# 觀察小結

Rails 的 router 中有許多的 route，每一個 route 負責保存一組規則，明確指向特定的 controller 以及 action。在建立 route 時，就已經進行了一些預處理來做加速。

Rails 在 router 上定義 find_routes 方法，比對 uri 以及 http method 來找出需要的 route，並且即時生成正規表示式來做參數解析。

# 開始自幹 Router

我們的目標是要讓 `get 'etrex/:id', to: 'etrex#show'` 能運作，儘量用最少最好讀的 code 來完成，效能什麼的在這裡不是重點。

```ruby
require 'action_dispatch'
require 'cgi'

class Router
  def initialize
    @routes = []
  end

  # 設定規則
  def draw(&block)
    self.instance_exec(&block)
  end

  def get(pattern, options)
    @routes << Route.new('get', pattern, options)
  end

  # 程式進入點
  def call(env)
    route = find_route(env)
    return route.serve(env) if route.present?
    [404, {"Content-Type" => "text/html"}, ['404 not found']]
  end

  private

  def find_route(env)
    method = env['REQUEST_METHOD'].downcase
    path = env['PATH_INFO'].downcase

    @routes.find do |route|
      route.match?(method, path)
    end
  end
end

class Route
  def initialize(method, pattern, options)
    @method = method.downcase
    @pattern = pattern.downcase
    controller_name, @action = options[:to].split('#')
    @controller = controller_class(controller_name)
  end

  def match?(method, path)
    match_method(method) && match_path(path)
  end

  def serve(env)
    query_string_params = Rack::Utils.parse_nested_query env['QUERY_STRING']
    params = in_path_params.merge(query_string_params)
    @controller.dispatch(@action, params, env)
  end

  private

  def in_path_params
    @in_path_params
  end

  def controller_class(controller_name)
    Object.const_get("#{ controller_name.capitalize }Controller")
  end

  def match_method(method)
    @method == method
  end

  def match_path(path)
    path = path[1..-1] if path[0] == '/'
    path_words = path.split('/')
    pattern_words = @pattern.split('/')

    return false unless path_words.count == pattern_words.count

    # 在 match 的同時紀錄在網址中的 params
    @in_path_params = {}
    pattern_words.zip(path_words).each do | pattern_word, path_word |
      if pattern_word[0] == ':'
        @in_path_params[pattern_word[1..-1]] = path_word
      else
        return false unless pattern_word == path_word
      end
    end
    true
  end
end

class BaseController
  attr_accessor :params
  def initialize(params)
    @params = params
  end

  def self.dispatch(action, params, env)
    body = self.new(params).send(action)
    [200, {"Content-Type" => "text/html"}, [body]]
  end
end

# 以上都是框架的部分
# 以下看起來像是正常的 rails code

class EtrexController < BaseController
  def index
    "etrex/index, params: #{params}"
  end

  def show
    "etrex/show, params: #{params}"
  end
end

app = Router.new

app.draw do
  get 'etrex', to: 'etrex#index'
  get 'etrex/:id', to: 'etrex#show'
end

run app
```

我做了最基礎的 Router 架構，可以把規則變成 Route 物件保存在 @routes 中，由 Route 提供 match 方法，並在 match 網址的同時擷取出網址中的參數。

同時也做了基礎的 controller 結構，確認能夠正常取得來自網址以及 query string 的參數。到這裡總算是入門囉！！

> 「What I cannot create, I do not understand.」 Richard Philip Feynman

---

>  👩‍🏫  __課務小幫手：__
>  
> ✨ 想掌握 Ruby on Rails 觀念和原理嗎？
>
> 我們有開設 🏓 [Ruby on Rails 實戰課程](https://5xruby.tw/courses/ruby-on-rails) 課程唷 ❤️️
>


post-如何自幹一個 Rails Router / cover

如何自幹一個 Rails Router

> 圖片作者：Duncan WJ Palmer    ，
> [來源連結](https://www.flickr.com/photos/blatez/16802876298/)

# Ruby 探索：Blocks 深入淺出

在學習 Ruby 的過程中，Block 是其中很重要的一環，如果對 Block 有多一點的認識就能更了解一些深奧的 code 到底是什麼意思啦！這篇文章主要是在看完 Metaprogramming Ruby 2 中的 Block 章節後的讀書心得，以及一個我自己找的一個小題目來練習學到的觀念。

--- 
### 目錄

* Scope 介紹
  * 什麼是 Scope ?
  * Scope Gate
* Block 介紹
  * Block 從頭開始
  * Proc 基本介紹
  * procs 和 lambdas 怎麼分？！
  * & 符號解析
* Block 實作
  * 自己做一個 before action
  * 第一步：試試看在 before 中執行 block 
  * 第二步：在執行 before 的時候只有紀錄…
  * 第三步：重新定義要執行 before 的 method
  * 第四部：只有第一次執行 execute_before
* 結論

---

### Scope 介紹

#### 什麼是 Scope ?
在介紹 Block 之前，我們需要先認識 ruby 中的 scope。
誒！什麼是 scope 呢？大概就是哪個變數可以在哪邊被看到的規則，舉例來說

```ruby
x = 10
def method
  puts x
end

method
```
執行上面這段程式後會發生...

```text
test.rb:3:in 'method': undefined local variable or method 'x' for main:Object (NameError)
	from test.rb:6:in '<main>'
```

在 method 方法內和外是不同的兩個 scope，所以 method 方法不能看到它外面的變數 x。如果想知道在自己的 scope 中可以使用哪些變數可以用 `local_variables` 來看！以下面這段 code 為例：

```ruby
v1 = 1
class MyClass
  v2 = 2
  local_variables #[:v2]
  def my_method
    v3 = 3
    local_variables #[:v3]
  end
  local_variables # [:v2]
end
local_variables # [:v1, :obj]
obj = MyClass.new
obj.my_method
```
> local_variables 會回傳現在的 scope 中可以看到的區域變數

在上面的例子我們可以發現，定義 `class MyClass` 到 `end` 中間這段區域看不到變數 v1 ，同時 `def my_method` 到它的 `end` 這段也看不到變數 v2，這是因為他們在不同的 scope。

#### Scope Gates

在 Ruby 中有三個 Scope Gates：`Class definitions`, `Module definitions` 還有 `Methods` 他們就像一道牆，牆外牆內彼此看不見那裡有哪些變數。

當然也是有一些方法可以突破這樣子的限制，可以換個方式定義 Class 還有 Methods 讓他們不再是 Scope Gates，這方法叫做 Flattening the Scope (其實方法的名字好像也不是很重要)，反正就是突破那個 scope 的限制啦！

```ruby=
my_var = "Success"
MyClass = Class.new do
  puts "#{my_var} in the class definition"
  define_method :my_method do
    puts "#{my_var} in the method"
  end
end

MyClass.new.my_method
```
可以成功印出

```
Success in the class definition
Success in the method
```

### Block 介紹

#### Block 從頭開始

除了上述方法可以突破 scope 的限制外，其實 block 也是可以做到類似的效果的，它讓我們可以先寫一段程式，然後再方法裡面呼叫，就像這樣

```ruby=
def my_method
  x = "Goodbye"
  yield("cruel")
end

x = "Hello"

my_method do |y| 
  puts "#{x}, #{y} world" 
end 
```
會印出

```
Hello, cruel world
```

上面的例子，在呼叫 `my_method` 的時候我們傳了一個 block (do 到 end 的那段)，大概可以想像他是 `my_method` 這方法的一個參數，接著 `my_method` 可以用 yield 這方法來執行這個 block。這個 block 厲害的地方在於它可以帶著當下的 bindings`(註解1)` 到 method 裡面去執行，所以在 `my_method` 可以看到 `x` 變數內的值是 Hello。

> 註解1

> bindings 指的是當下 scope 可以使用的 variable, methos 還有 self

在 Ruby 的世界裡 block 是個特殊的成員，他不是物件也不能單獨存在，但其實還是有方法可以把 block 轉成物件讓我們處理的，那就是 Proc。

#### Proc 基本介紹

```ruby=
inc = Proc.new {|x| x + 1 }
inc.call(2) # 回傳 3
```

在 Proc.new 後面接一個 block 就可以產生一個 Proc 的物件，接著可以使用 call 方法來呼叫。有很多種方式可以產生 Proc 的物件，而且用不同方式產生的 Proc 也會不太一樣，首先來介紹 proc 還有 lambda ～

#### procs 和 lambdas 怎麼分？！

```ruby=
l1 = lambda {|x| x + 1 }
l2 = ->(x){ x + 1 }
p1 = Proc.new {|x| x + 1 }
p2 = proc {|x| x + 1 }

puts "l1: #{l1.lambda?}, #{l1.class}" # l1: true, Proc
puts "l2: #{l2.lambda?}, #{l2.class}" # l2: true, Proc
puts "p1: #{p1.lambda?}, #{p1.class}" # p1: false, Proc
puts "p2: #{p2.lambda?}, #{p2.class}" # p2: false, Proc
```
上面的 `l1`, `l2`, `p1`, `p2` 都可以使用 call 方法來執行，其中我們可以用 `lambda?` 來知道它是不是 lambda 如果不是那它就是 proc 啦！除了用 `lambda` 跟 `->()` 產生的 Proc 物件是 lambda 其他都是 proc 唷！

說了那麼久怎麼產生跟判斷 proc 和 lambda，當然就要來說他們有什麼不同啦！主要有兩個不同的地方，第一個是 return 的值，第二個是參數的判斷方式

##### procs 和 lambdas 有不同的 return 

```ruby=
def double(callable_object)
  callable_object.call * 2
end

# return from lambdas
la = lambda { return 10 }

# return from the scope which defined the procs(main)
pr = proc { return 10 }

puts double(la) # 20
puts double(pr) # LocalJumpError...
```
執行程式後會

```
 20
 test.rb:12:in `block in <main>': unexpected return (LocalJumpError)
 	from p92.rb:22:in `double'
 	from p92.rb:29:in `<main>'
```

lambda 的 return 是從 lambda return，而 proc 則是從定義 proc 的 scope return 意思就是如果把 proc 用一個方法包起來的話...

```ruby= 
def lambda_double
  la = lambda { return 10 }
  result = la.call
  return result * 2
end

def proc_double
  pr = Proc.new { return 10 }
  result = pr.call
  return result * 2  # unreachable code!
end

puts lambda_double # => 20
puts proc_double   # => 10
```

`lambda_double` 可以執行完方法中的每行程式，而 `proc_double` 則會在 `pr.call` 那行就 return 了，因為 proc 的 return 是從定義 proc 的地方也就是 `proc_double` 出發的。

##### procs 和 lambdas 處理參數的方式

procs 處理參數的方式比較有彈性，而 lambdas 則是比較嚴格，說起來不清楚!? 看 code 最快

```ruby
puts "以下是 proc"
pr = proc {|a,b| [a,b]}
p pr.call('a', 'b')
p pr.call('a')
p pr.call('a', 'b', 'c')

puts "以下是 lambda"
la = lambda {|a,b| [a,b]}
p la.call('a', 'b')
p la.call('a')
p la.call('a', 'b', 'c')
```

執行程式後會

```
以下是 proc
["a", "b"]
["a", nil]
["a", "b"]
以下是 lambda
["a", "b"]
test.rb:8:in `block in <main>': wrong number of arguments (given 1, expected 2) (ArgumentError)
	from test.rb:10:in `<main>'
```

procs 遇到多的參數會自動丟掉，而不夠就補 nil，lambdas 則要求參數的數量正確才能執行。

#### & 符號解析

> 促使我想要多瞭解 ruby 中的 block 就是這個 & 符號了，第一次在 rails 專案裡面看到了這種符號真是既挫折又期待，覺得有很多東西可以學啦！在 C 語言中 & 是來拿記憶體位址的符號，在 ruby 裡面 & 符號到底是拿來做什麼的呢？

& 符號可以把 block 轉成 Proc 或是轉回來，多說無益看 code 就知道

```ruby=
def second_method
  puts 'In second_method'
  yield
end

def first_method(&operator) # 這裡的 & 是把 block 轉成 Proc 
  puts 'In first_method'
  operator.call
  second_method(&operator) # 這裡的 & 是把 Proc 轉成 block
end

first_method do 
  puts "this is block"
end
```
執行後會印出

```
In first_method
this is block
In second_method
this is block
```

在呼叫 `first_method` 得時候我們傳了一個 block 給他，我們可以把 block 想像成是最後一個參數，只是要在定義 `first_method` 的時候跟他說我們會有一個參數而且他是一個 block，因此就寫 `&operator`，之後就能在 `first_method` 中使用 operator 這個 Proc 啦～

如果想要不是馬上要用這個 Proc 還能把他先轉成 block 再傳給下一個 method，這時候就是在 `operator` 前加個 `&` 它就又從 Proc 轉成 block 囉！所以 second_method 使用 yield 才能成功呀！

以上就是關於 Block 的基本介紹啦，接下來做個小小的練習來應用一下學到的知識啦！

### Block 實作:
#### 自己做一個 before action 

目標是讓下面的程式碼

```ruby=
class Example 
  extend BeforeAction
  before :method_a, :method_b do
    puts 'the code before method'
  end

  def method_a
    puts 'this is method a'
  end

  def method_b
    puts 'this is method b'
  end
end

instance_1 = Example.new
instance_1.method_a
instance_2 = Example.new
instance_2.method_b
```

可以有這樣的執行結果

```ruby
the code before method
this is method a
the code before method
this is method b
```

> 要做一個 `BeforeAction` 的 Module ，在裡面有個 before 方法可以讓指定的 method 在執行之前，先執行 before 後面的 block

#### 第一步：試試看在 before 中執行 block 
```ruby=
module BeforeAction
  def before(*methods, &block)
    methods.each do |method| 
      block.call
    end
  end
end
```
> 現在我們可以依據定義了幾個 method 給 before 來執行幾次 block

#### 第二步：在執行 before 的時候只有紀錄...

要做到 before action 就必須覆寫裡面的 `method_a`, `method_b` 之類的，但是在執行 before 的時候根本還沒有定義 `method_a` 是什麼，所以在這邊只能先把要執行的 block 還有要覆寫的 method 名字存起來！

```ruby=
module BeforeAction
  def new
    execute_before
    super
  end

  def before(*methods, &block)
    # 先存起來之後用
    @methods = methods
    @block = block
  end

  def execute_before
    # to do ...
  end
end
```
> 存起來之後我們可以在 Example 用了 new 方法時，再來處理我們的 block，讓那些需要執行 before action 的 method 可以被覆寫

#### 第三步：重新定義要執行 before 的 method

```ruby=
module BeforeAction
  ...
  def execute_before
    @methods.each do |method| 
      # 幫原本的 method 取一個新名字
      newname = "new_#{method}"
      alias_method newname, method
      block = @block
      # 重新定義每個 method 要做什麼
      define_method method do 
        # 執行 block
        block.call
        # 原本的 method
        send(newname)
      end
    end
  end
end
```
> 這個步驟比較麻煩一點，重新定義方法後就會把原本的方法全部蓋過去。所以我們幫原本的方法取了個新名字(newname)，在重新定義方法後就可以在呼叫(send)來執行原本方法的程式了！

到目前為止，我們的程式已經可以讓 Example 這個 class 做這樣的事囉！如果只有 new 一次都能正常執行～

```ruby=
instance_1 = Example.new
instance_1.method_a
instance_1.method_b
```

執行結果為

```ruby
the code before method
this is method a
the code before method
this is method b
```

#### 第四部：只有第一次執行 execute_before

因為只有在第一次 new 的時候需要執行 execute_before，所以我們可以做一點小小的修改...

```ruby=
module BeforeAction
  def new
    execute_before if first_time?
    super
  end

  def first_time?
    return false if @not_first_time
    @not_first_time = true
  end

  ...
end

```

#### 最後：大功告成

完整程式碼如下

```ruby=
module BeforeAction
  def new
    # 只有第一次執行 new 時要 execute_before
    execute_before if first_time?
    super
  end

  def first_time?
    return false if @not_first_time
    @not_first_time = true
  end

  def before(*methods, &block)
    # 先存起來之後用
    @methods = methods
    @block = block
  end

  def execute_before
    @methods.each do |method| 
      # 幫原本的 method 取一個新名字
      newname = "new_#{method}"
      alias_method newname, method
      block = @block
      # 重新定義每個 method 要做什麼
      define_method method do 
        # 執行 block
        block.call
        # 原本的 method
        send(newname)
      end
    end
  end
end

class Example 
  extend BeforeAction
  before :method_a, :method_b do
    puts 'the code before method'
  end

  def method_a
    puts 'this is method a'
  end

  def method_b
    puts 'this is method b'
  end
end

instance_1 = Example.new
instance_1.method_a
instance_2 = Example.new
instance_2.method_b
```

執行後結果

```
the code before method
this is method a
the code before method
this is method b
```

在這範例練習到把 block 轉成 Proc ，然後存起來之後使用，在每次呼叫方法的時候都先執行這個 Proc

### 結論

透過寫這篇文章好好的整理了 block 相關的觀念，不然以前總是略懂略懂，但要回想的時候又要翻書查看半天...雖然這些東西可能不是馬上需要用到，但以後如果有需要用到這些技巧的時候，再回來看這篇自己寫的文章應該可以很快回憶起來吧！

---

>  👩‍🏫  __課務小幫手：__
>  
> ✨ 想掌握 Ruby on Rails 觀念和原理嗎？
>
> 我們有開設 🏓 [Ruby on Rails 實戰課程](https://5xruby.tw/courses/ruby-on-rails) 課程唷 ❤️️
>


五倍紅寶石・專業程式教育機構

ASTRO Camp

線上課程

實體課程

技術文章

五倍消息

技術文章

動動手來學 Regular Expression 正規表達式

透過 AWS ServerlessImageHandler 實現動態圖片處理

Webassembly - run native code on browser using Rust

Git 面試題

第一次用 Flex 切版就上手

React 16：Lifecycle Methods 新手包

如何自幹一個 Rails Router

Ruby 探索：Blocks 深入淺出

訂閱文章

電話 | (02) 2331-5247

信箱 | [email protected]

地址 | 10046 台北市中正區衡陽路 7 號 5 樓

專業課程

ASTRO Camp

線上課程

實體課程

關於我們

關於五倍紅寶石

聯絡我們

媒體報導

加入我們

部落格

技術文章

五倍消息

幫助與政策

常見問題

隱私權政策

服務條款