為什麼你應該了解不同的選項類型

良好的沟通还能提高销售额。

你不知道的「 import type 」

例如在下面的这个例子中，我们确保 JavaScript 的值 doThing 以及 TypeScript 类型 Options 一同被导入:

当 TypeScript 输出一个 JavaScript 文件时，TypeScript 会识别出 Options 仅仅是当作了一个类型来使用，它将会删除 Options。

比如在下面的例子中， MyThing 究竟是一个值还是一个类型？

如果 Mything 仅仅是一个类型，Babel 和 TypeScript 使用的 transpileModule API 编译出的代码将无法正确工作，并且 TypeScript 的 isolatedModules 编译选项将会提示我们，这种写法将会抛出错误。

一个我们看到的具体例子是出现在 Angularjs（1.x）中， services 需要在全局在注册（它是一个副作用），但是导入的 services 仅仅用于类型声明中。

结果 ./service.js 中的代码不会被执行，导致在运行时会被中断。

在 TypeScript 3.8 版本中，我们添加了一个仅仅导入/导出声明语法来作为解决方式。

import type 仅仅导入被用于类型注解或声明的声明语句，它总是会被完全删除，因此在运行时将不会留下任何代码。

与此相似，export type 仅仅提供一个用于类型的导出，在 TypeScript 输出文件中，它也将会被删除。

当使用 import type 导入一个类时，你不能做类似于从它继承的操作。

如果在之前你使用过 Flow ，它们的语法是相似的。

与 import type 相关联，我们提供来一个新的编译选项： importsNotUsedAsValues ，通过它可以来控制没被使用的导入语句将会被如何处理，它的名字是暂定的，但是它提供来三个不同的选项。

remove ，这是现在的行为 —— 丢弃这些导入语句。这仍然是默认行为，没有破坏性的更改
preserve ，它将会保留所有的语句，即使是从来没有被使用。它可以保留副作用。
error ，它将会保留所有的导入（与 preserve 选项相同）语句，但是当一个值的导入仅仅用于类型时将会抛出错误。如果你想确保没有意外导入任何值，这会是有用的，但是对于副作用，你仍然需要添加额外的导入语法。

Babel 和 TypeScript 是如何一起工作的

TypeScript 做了两件事

将静态类型检查添加到 JavaScript 代码中。
将 TS + JS 代码转换为各种JS版本。

这样，就即可以使用 Babel 的所有优点，同时仍然能够提供 ts 文件。

在这里，babel 不能告诉 example.ts 那个 Color 实际上是一个类型。

大概是因为 babel 团队并不想像 TypeScript 那样，在相同的类型解析过程中进行构建，只是为了删除这些类型吧。

isolatedModules

isolatedModules 是什么

tsc 做类型检查时，当监测到 isolatedModules 是开启的，就会报类型错误。

From TypeScript docs:

Perform additional checks to 為什麼你應該了解不同的選項類型 ensure that separate compilation (such as with transpileModule or @babel/plugin-transform-typescript) would be safe.

From Babel docs:

--isolatedModules This is the default Babel 為什麼你應該了解不同的選項類型 behavior, and it can't be turned off because Babel doesn't support cross-file analysis.

OAuth 2.0 常見用詞

「Sign in with Google」按鈕背後的連結長得類似像下面的連結，當使用者點下去，就會被導向這個 Authorization Server 的位址，上面需要帶入相關設定資訊。
（補充：前四個步驟最終是希望取得「Authorization Grant」，Authorization Grant 有不同類型。在這邊因為是以 Authorization Code Flow 這種取得 Access Token 的方式做為舉例，所以 response_type 為什麼你應該了解不同的選項類型 為什麼你應該了解不同的選項類型 的值為 code）

🔐 使用者身份驗證與授權

以 Google 為例，點擊「Sign in with Google」後就會被導向以下都入畫面，下方也同時顯示了應用程式希望你授權同意它代為取得的相關資源訊息。

🚛 同意或拒絕授權的 Callback

同意或拒絕授權後，會將使用者導向應用程式指定的 Callback URI，並依據結果在 query string 帶上相對應的資訊：

🔑 交換 Access Token

通常會透過 HTTP Post 請求，向 Authorization Server 取得 Access Token，請求基本上會帶上剛拿到的 Authorization grant 以及用來驗證應用程式身份的相關資訊（Client ID、Client Secret 等）：

Authorization Server 在驗證後，就會在回傳中核發 Access Token，並提供相關資訊：

🎫 為什麼你應該了解不同的選項類型拿著 Access Token 取得資源

最後應用程式就能拿著這個 Access Token 向 Resource owner 依照自己被授與的權限取得資源：

OAuth2.0 四種授權類型流程

OAuth2.0 定義了四種應用程式取得 Access Token 的流程，又稱為「Grant Types」。文章上半部介紹了其中一種，而接下來將完整介紹不同的類性——要使用哪種流程，能依照應用程式的類型簡單劃分：

Authorization Code

這是最常見的類型，Server-side Application （Web server applications）最為適用——通常會由後端伺服器負責產生頁面（View）回傳給前端渲染。如此一來，大部分的邏輯處理程式碼，以及像應用程式的 Client Secret 等重要機密資訊，都能在伺服器端被保存，而非完全公開。

這種類型就是我們文章到目前為止介紹的流程：

應用程式將使用者導向 Google 進行身份驗證和授權。導頁的 URL 中透過為什麼你應該了解不同的選項類型 Query string 提供應用程式的身份，以及需要請使用者授予權限等相關資訊。（特別補充：前面範例使用的 response_type=code 代表應用程式請求的是 Authorization Code 這種 Authoriation Grant）
Google 接著負責使用者身份驗證，並詢問使用者是否同意授權（Consent）。
成功後，將依據 Redirect URI 將使用者導回應用程式指定路徑，並附上 Authoriation Grant——以當前類型的流程來說，就是回傳「Authorization Code」。
應用程式能拿著 Authorization Code 向 Authorization Server 交換取得 Access Token。
最終應用程式就能拿著 Access Token 向 Resource Server 取得資料。

Implicit

適合 Client-side applications 的類型——通常會是整個應用程式都在前端運行，依需求向後端 API 取得資料。例如單純的靜態網站或 Single Page Application(SPA) 都適用。

由於整個應用程式都在前端運行，所以會缺少「後端伺服器透過 Authorization Code Grant 交換 Access Token 」的步驟。取而代之的是請 Authorization Server 直接核發 Access Token。

Implicit Flow 流程：

應用程式將使用者導向 Google 進行身份驗證和授權。導頁的 URL 中透過 Query string 提供應用程式的身份，以及需要請使用者授予權限的相關資訊。（補充：在這要帶上的 Response Type 為 token 代表應用程式請求的是 Access Token）
Google 接著負責使用者身份驗證，並詢問使用者是否同意授權（Consent）。
成功後，將依據 Redirect URI 將使用者導回應用程式指定路徑，並附上 Authoriation Grant ——以當前類型的流程來說，就是回傳「Access Token」。
最終應用程式就能拿著 Access Token 向 Resource Server 取得資料。特別留意：不像 Authorization Code Flow，這邊是由前端獲得與管理 Access Token，並帶著 Access Token 發出請求前往取得資源，因此在安全性上「相對脆弱」。

Resource Owner Password Credentials

此流程是由使用者提供帳號與密碼等資訊給應用程式，由應用程式直接向 Authorization Server 交換 Access Token，體驗上和以往的帳號密碼登入雷同。

帳號與密碼等機密資訊（credentials）可能會被應用程式儲存起來，作為往後交換 Access Token 使用。因此「必須是使用者高度信賴的應用程式」才適合使用，且唯有前兩種皆不可行時，才會考慮使用當前類型的流程。因此，適用的情境，可能像公司內部的系統。

Resource Owner Password credentials 流程：

通常會透過表單或其他形式，讓使用者提供帳號與密碼的身份驗證資訊。
應用程式在取得使用者的帳號與密碼後，會提供給 Authorization Server 進行身份驗證。
Authorization Server 進行身份驗證成功後，就會核發 Access Token。
最終應用程式就能拿著為什麼你應該了解不同的選項類型 Access Token 向 Resource Server 取得資料。

Client Credentials

適合用在 machine-to-machine (M2M) applications——通常是由應用程式向 Authourization Server 請求取得 Access Token 以獲取「自己」的相關資源，而非使用者的資源。

這個流程已經跳脫使用者，因此，使用者身份驗證的流程將不再需要。取而代之的，是應用程式必須向 Authorization Server 提供驗證所需的自身資訊。

Client Credentials Flow 流程：

應用程式透過提供其 Client ID 及 Client Secret Token 等其他作為驗證的資訊（client credentials）給 Authorization Server 進行身份驗證。
Authorization Server 驗證成功後，核發 Access Token 給應用程式。
應用程式取得 Access Token 後，即能代表自己向 Resource Server 取得自己的相關資料。

OAuth 2.0 的應用很廣，最大的好處和廣泛應用的，是能讓使用者能允許第三方應用程式，取得其在另一個平台的資料，而不需要提供驗證資訊給該第三方應用程式。

它不僅能運用在 Web App 上，也能運用在 Mobile App、Desktop App 等不同類型的應用程式與情境中，但背後的概念在大方向上基本上是相同的。

這次的研究是主要是從 Web App 的角度去研究使用方式和認識概念，但由於不同的情境、不同的平台在使用上還是有所差異，期待未來有機會接觸更多的面向和應用場景。