我試圖了解 Servant 的 serveWithContext 函式的目的。檔案指出它不是 ReaderT Monad 的替代品，但我不確定它試圖解決的問題是 ReaderT 尚未解決的問題。
例如，這是來自servant-auth GitHub頁面上的示例：
unprotected :: CookieSettings -> JWTSettings -> Server Unprotected
unprotected cs jwts = checkCreds cs jwts :<|> serveDirectory "example/static"
server :: CookieSettings -> JWTSettings -> Server (API auths)
server cs jwts = protected :<|> unprotected cs jwts
let jwtCfg = defaultJWTSettings myKey
cfg = defaultCookieSettings :. jwtCfg :. EmptyContext
api = Proxy :: Proxy (API '[JWT])
_ <- forkIO $ run 7249 $ serveWithContext api cfg (server defaultCookieSettings jwtCfg)
似乎 serveWithContext 被用來將 Cookie 和 JWT 設定傳遞給處理程式，但我不明白為什么這不能用 ReaderT 來完成。此外， serveWithContext 似乎兩次傳遞這些值：一次作為系結到的 Context 物件，另一次作為cfg函式呼叫中的引數server defaultCookieSettings jwtCfg。
如果有人能為我揭開仆人的背景關系型別的神秘面紗，我將不勝感激。
uj5u.com熱心網友回復：
似乎機器Servant沒有對您選擇定義處理程式的底層 monad 做出假設。這意味著它不能強迫您選擇任何特定的 monad（例如，例如ReaderT）以回應路由中存在的某些組合器，并且它不會對您選擇的 monad 做出“反應”以啟用某些行為。
在servant-auth的情況下，我們需要向servant提供一些關于如何處理cookies等的額外 資訊。
什么Context系統做它收集在一個位置引數，額外的資訊route，hoistServerWithContext并且serveWithContext，同時還讓你選擇的任何單子你的愿望。引數的確切型別取決于 API 中存在的路由組合器。
該仆人教程大約有一些段落ContextS：
當有人向我們的“私有”API 發出請求時，我們將需要向服務提供驗證用戶名和密碼的邏輯。[...] Servant 0.5 引入了 Context 來處理這個問題。[...] 想法很簡單：向服務函式提供一些資料，然后將這些資料傳播到處理每個組合器的函式。
至于
此外， serveWithContext 似乎兩次傳遞這些值
我不確定，但我懷疑checkCreds采用csand jwtsas 引數只是作為一個示例，說明如果純粹在處理程式中完成身份驗證，而沒有 Servant 本身的幫助，則將如何執行身份驗證。相比之下，protected端點已經接收到認證結果作為引數；它不必自己執行。
在實際應用程式中，server不會采用這些引數，它們只會在Context.
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/370613.html