CodeLove 論壇 - 免費自學作業包＆新手友善討論區，幫你轉職工程師！

👉 讀技術文章 👉 上自學課程 👉 討論區交流

🔍 搜尋結果：elixir

讓我們將函數式程式設計引入 OOP 程式碼庫

時間越長，我就越成為函數式程式設計的愛好者。即使當我在 OOP 程式碼庫中工作時，我也會嘗試應用旨在簡化程式碼並更輕鬆地預測結果的小概念。身為 Ruby 專家，我也喜歡使用功能程式碼編寫單元測試是多麼簡單。本文的目的是分享我對函數式程式設計概念的看法，並提出一種可以在已編寫的 OOP 程式碼中使用函數式概念的方法。希望我們能夠停止爭論哪種範式更好，並開始編寫好的想法，每次都能產生更好的程式碼！目錄 -- - [一開始，有函數式編程](#in-the-beginning-there-was-functional-programming) - [進入OOP，這個範式是什麼？](#entering-oop-what-is-this-paradigm) - [什麼是類別以及我們如何以不同的方式思考它](#what-is-a-class-and-how-can-we-think-about-it-differently) - [變異還是不變異：什麼是不變性](#to-mutate-or-not-to-mutate-what-is-immutability) - [床下的怪物：有什麼副作用](#the-monster-under-the-bed-what-are-side-effects) - [隔離一切：什麼是純函數](#isolate-everything-what-are-pure-functions) - [使用函數式模式而不需要完整的 haskell](#using-functional-patterns-without-going-full-haskell) - [結論](#conclusion) 一開始，有函數式編程 ---------- ![功能性](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/hpg7b5lx6czu67jv9e07.png) 函數式程式設計範式於 1958 年隨著第一個 Lisp 語言的出現而出現（美好的時光）。它的根源可以追溯到 Alonzo Church 的 lambda 演算。函數式程式設計的核心原則圍繞著最小化對程式碼庫中狀態的依賴。與允許狀態但強調封裝的物件導向程式設計 (OOP) 不同，函數式程式設計師努力優先編寫無狀態元件。這種方法鼓勵建立獨立於外部狀態變數的程式碼。此外，即使引入了狀態，在編寫狀態時也必須考慮不變性、函數的純度，甚至避免副作用。隨著本文的深入，所有這些概念都將進一步介紹。進入OOP，這個範式是什麼？ -------------- ![打開](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/em6b2ejnoml80awxyrhw.png) OOP，或更廣為人知的名稱為“物件導向程式設計”，是一種可以追溯到 1967 年的範式。其最偉大的代表是 Simula、Smalltalk 和 Java。背後的思想過程是透過強制封裝實踐來將這些狀態以及修改它們的任何行為分組到公共「實體」或「物件」下，從而減少「全局」狀態的數量。事實上，「物件導向程式設計」這個名字多年來一直被廣泛討論。 OOP 的建立者之一 Alan Key 實際上希望更多地關注該範例的訊息傳遞方面。這意味著我們應該強調封裝並允許物件之間進行狀態和行為的通訊。也許在不同的宇宙中，我們可以擁有「面向訊息的程式」。然而，OOP 這個名字已經經久不衰，而我們就在這裡！我不知道你怎麼想，但是這個考慮範式的另一個可能名稱的簡單過程讓我的思維變得瘋狂，重新思考了一些概念，並實際上簡化了我建置軟體的方式。什麼是類別以及我們如何以不同的方式思考它 -------------------- ![什麼是類](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/70x9cp26qi2cvx13dm3q.png) 我想每個人都聽過那個經典的講座，其中我們學到了“動物”類，其中包括“狗”類，對嗎？你可能聽過同樣的話（至少我聽過）。 > 類別是現實世界中實體的藍圖，描述其特徵和操作。雖然不正確，但我想建議稍微改變一下單字的用法，以幫助澄清封裝，以便更好地理解，就像它對我所做的那樣。讓我們考慮以下新引文： > 類別是一種封裝狀態和在該狀態上操作的行為的方法。這個簡單的字的改變確實讓我的思想改變了。我不再嘗試將類別視為現實世界的實體，而是開始簡單地將其視為將具有相似上下文的狀態分組在一起並公開對這些狀態進行操作的函數的另一種方式。我希望這個小小的改變也能幫助你回顧自己的概念！以這種方式抽象化這個概念的重要性是，在從具有不同結構（例如模組）的語言中讀取程式碼時變得熟練。我們可以觀察到這段 OOP 程式碼是用 typescript 寫的： ``` class Github { private _url: string; privale _repo: string; private _username: string; constructor(url: string, repo: string, username: string) { this._repo = repo this._username = username this._url = url } public createRepo(name: string): void { // TODO: do stuff here using the provided state in _url, _repo and _username } } ``` 與此 Elixir 程式碼完全等效，即使 Elixir 程式碼使用“模組”而不是“類別”： ``` defmodule Github do @url "" @repo "" @username "" defstruct url: @url, repo: @repo, username: @username def new(url, repo, username) do %Github{url: url, repo: repo, username: username} end def create_repo(%Github{repo: repo, username: username}, name) do # TODO: do stuff here using the provided state in url, repo, and username end end ``` 接下來我們將研究一些功能概念並進一步討論這些範例的合併，讓我們開始吧！變異還是不變異：什麼是不變性 -------------- ![不變性](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4fotff1cbifqi2c5ubtb.png) 現在我們正在達到第一個真正的功能概念，而且是一個非常重要的概念，我可以補充一下（一切都在這裡計劃）！為了正確理解不變性，讓我們回顧一下在程式設計中處理值的方式：通常，我們將值綁定到變數，以便稍後可以對它們進行操作，對嗎？就像簡單的事情 ``` # Bounding values to variables name = 'Cherry' age = 23 # Operating on it and bounding to another variable year_born = Time.now.year - age # Printing it puts "#{name} has #{age} years old and was born at #{year_born}" ``` 對於這些變數，透過更新其值來更改原始變數是很常見的，但這裡缺少的是：修改變數是一種**破壞性**操作。但為什麼？好吧，讓我們想像一下多個操作（函數或程式碼區塊）在不同時刻和頻率修改相同變數。在這種情況下，我們會產生很多問題，例如： - **1. 無法對操作重新排序或根本無法更改它們：**當我們有如此多的依賴程式碼時，甚至很難對程式碼進行重新排序或更改，因為所有內容都綁定到特定的更改順序。 - **2. 理解程式碼在做什麼的心理負擔：**雖然這是個人觀點，但我認為這是一個廣受認可的觀點。高度可變的程式碼很容易變得混亂且難以理解資料流，需要除錯器等工具來逐步完成轉換。 - **3. 測試時的困難：**模擬函數轉換的特定狀態確實很困難，這將逐漸擴展您的單元測試，直到它們不再是單元。不變性可以定義為避免更改（或變異）程式內任何變數的做法。儘管根據語言的不同，我們可能需要做出讓步並改變一些控制變數，但這裡要學到的總體教訓是： > 我們應該不惜一切代價避免改變沒有定義範圍的變數。透過這句話，我的意思是可以在函數內建立作用域變數並在那裡對其進行變異。然而，一旦您將這個可變變數傳遞給另一個函數，您就會增加改變相同變數的目標數量，並且您將慢慢失去控制。這正是我們想要避免的情況！床底下的怪物：有什麼副作用 ------------- ![副作用](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/yb1osy6ziacyc2l12h6v.png) 每當有人提出這個話題來討論時，這個話題就會引起很大的熱度。我可能不會涵蓋這個主題的每一個細微差別，但我一定會向您解釋它們是什麼以及我如何在我自己的軟體中管理副作用，好嗎？那麼，副作用就是透過呼叫協定（HTTP、WebSocket、GraphQL 等）甚至操作 stdin/stdout 與外部資源（或「外部世界」）互動的每一次計算。是的，我知道，即使是我們無害的`print`也會在這裡受到指責。 😔 但與變異性不同的是，我們不應該盡可能避免使用它，而應該將其隔離在單獨處理副作用的特定函數中。這樣，我們將程式碼分為「不執行任何副作用的函數」和「執行副作用的函數」。但為什麼要擔心這種分離呢？每次我們觸發對「外部世界」的任何操作時，我們都會失去對這個特定計算部分可能發生的情況的控制（例如在執行 HTTP 呼叫時，伺服器可能會關閉或可能根本不存在）。其他問題包括測試困難和程式碼可預測性降低。由於我們無法編寫沒有副作用的任何現實世界軟體，因此一般建議是將其聚集成小函數，透過對錯誤的適當抽象來單獨處理它。這樣，就可以只測試我們 100% 控制的函數，並模擬所有執行副作用的函數。例如，請考慮以下執行 HTTP 請求的函數以及轉換從該請求傳回的資料的小函數。 ``` require 'faraday' module MyServiceModule # This function perform side effects def perform_http_request conn = Faraday.new(url: "fakeapi.com") begin response = conn.get {ok: true, data: response.body} rescue => e {ok: false, error: e} end end # These functions doens't perform any side effects def upcase_name(name) return '' unless name.is_a?(String) name.upcase end def retrieve_born_year(age) return 0 unless age.is_a?(Integer) Time.now.year - age end end ``` > 看到我怎麼說「錯誤周圍的抽象」了嗎？這正是上面的程式碼範例中實現的，而不是讓異常在我們針對雜湊抽象的程式碼中冒泡。在使用「副作用」和「無副作用」之間的明確定義來定義這些函數之後，很容易預測程式碼中會發生什麼，也更容易測試，如下所示： ``` require 'minitest/autorun' class TestingStuff < Minitest::Test def test_upcase_name assert_equal MyServiceModule.upcase_name "cherry", "CHERRY" assert_equal MyServiceModule.upcase_name "kalane", "KALANE" assert_equal MyServiceModule.upcase_name "Thales", "THALES" end def test_retrieve_born_year Time.stub :now, Time.new(2024, 3, 5) do assert_equal MyServiceModule.retrieve_born_year 23, 2001 assert_equal MyServiceModule.retrieve_born_year 20, 2004 assert_equal MyServiceModule.retrieve_born_year 14, 2010 end end end ``` 這個策略真的很棒，因為您甚至不需要在測試時擔心副作用部分，只需為實際執行某些操作的程式碼轉換部分編寫斷言，您最終會得到更好的測試，真正驗證重要的內容您的程式碼庫的一部分！整齊吧？隔離一切：什麼是純函數 ----------- ![純函數](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/bgnpfyig36sssuio9qpy.png) 現在是時候總結到目前為止所獲得的所有知識了。在前面的範例中，我們觀察到程式碼分為「副作用」和「無副作用」。我們還看到了這些功能如何更容易測試，並且我們的主要轉換業務邏輯應該保持隔離。您想知道這些函數叫什麼嗎？它們是**純函數**！讓我們檢查純函數的正確形式定義並逐步探索這個概念。 > 純函數是尊重不變性、不執行任何副作用並且在給定相同參數的情況下傳回相同輸出的函數。基本上，純函數遵循我們之前提到的所有原則，而且它們總是為相同的參數產生相同的返回。讓我們來看看之前的函數。 ``` def upcase_name(name) return '' unless name.is_a?(String) name.upcase end upcase_name('cherry') # => Will be *always* CHERRY ``` 使用純函數，我們可以輕鬆定義多個斷言，因為我們不受任何需要大量模擬的上下文的約束。我們只需用靜態值傳遞所需的參數，就這樣！由於純函數非常小且可組合，因此它們的數量增加得非常快。為了解決這個問題，像 Elixir 這樣的函數式語言提供了像管道這樣的組合運算符，這使得按順序執行多個純函數變得非常容易。 ``` "cherry " |> trim |> upcase # => "CHERRY" ``` > 管道運算子源自 Bash 等函數。您可以在這裡閱讀更多相關資訊：\[ <https://dev.to/cherryramatis/linux-filters-how-to-streamline-text-like-a-boss-2dp4#what-is-a-pipeline> \] 使用函數式模式而不需要完整的 haskell ---------------------- ![都是功能啊](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/42ndx4tuvrs35q2woepg.png) 我一直害怕學習函數範式，因為社群透過使用現成的句子和大概念讓每個試圖學習一些小技巧的人變得非常複雜。在掌握了許多函數式語言並嘗試盡可能多地學習之後，我的目標是簡化這些概念，最重要的是，提倡在 OOP 程式碼中使用函數式概念。應用純函數（或純方法，如果您願意）、不變性和副作用分離可以使您的 OOP 程式碼看起來更乾淨和解耦。你不需要知道什麼是 monad 或如何在 Haskell 中手動編寫編譯器；您可以使用簡單而有效的函數概念來堅持使用 Ruby on Rails！我希望透過這篇小文章（以及本系列中的文章），無論您選擇哪種語言和框架，您都可以透過可組合性和簡單性來改進您的程式碼庫。結論 -- 這篇文章是我嘗試使函數範式的知識民主化（在我的能力和專業知識範圍內）。需要強調的是，我不是函數式專家，本文針對的是了解 OOP 並對函數式程式設計感興趣的初學者。我希望它有用，並且我願意提供任何需要的幫助。願原力與你同在🍒 --- 原文出處：https://dev.to/cherryramatis/ending-the-war-or-continuing-it-lets-bring-functional-programming-to-oop-codebases-3mhd

0個讚 0留言 80瀏覽

小編精選 - 技術文章翻譯 · 03月11日

TechSchool：學習程式設計的免費開源平台

自 2019 年以來，我在我的[YouTube 頻道](https://youtube.com/@DanielBergholz?si=WsZ062ZtA5MV3kX_)上發布了免費課程。很多時候，人們對我的影片發表評論，例如「哇，這門課程太棒了！比我購買的昂貴課程好多了！」。從那以後我開始反思。到底為什麼有人拿著數千美元的報酬來出售比我**免費**製作的課程還差的課程？另外，為什麼我的課程在 YouTube 上只有 100 次觀看？這不公平。辨識問題 ---- 有很多人想學習編程，也有很多免費課程。然而，大多數時候，這兩個群體不會見面。為什麼？有兩個原因。一是多個風投支持的掠奪性編碼訓練營花費數百萬美元瞄準新人，並告訴他們進入該行業的唯一方法是將所有錢花在昂貴的線上課程上。第二，YouTube 演算法超難掌握。如果您最近建立了一個頻道，可能需要**數年時間**才能吸引更多受眾。解決方案 ---- 如果我們可以輕鬆找到所有免費課程，而無需 YouTube 演算法的阻礙，那會怎麼樣？這就是 TechSchool 介入的地方。它是一個包含所有可能在雷達下傳播的免費內容的平台。它也是開源的，這意味著任何知道很酷課程的人都可以輕鬆打開 PR 來加入它。網址：https://techschool.dev GitHub：https://github.com/danielbergholz/techschool.dev 讓我們一起對抗昂貴的進入門檻吧！技術教育應該是免費的並且向所有人開放！我們都會成功的:fire: ![讓我們反擊吧！](https://media.giphy.com/media/3oEjI1erPMTMBFmNHi/giphy.gif) 免責聲明 ---- TechSchool 永遠是一項正在進行中的工作。隨著時間的推移，我們都會共同加入更多內容，因此，如果您不喜歡現在提供的選項，請等待幾週，然後重新存取該網站！我相信你會發現新的東西。技術堆疊 ---- 我在[README](https://github.com/danielbergholz/techschool.dev/blob/main/docs/tech-stack.md)中對所有內容進行了解釋，但總而言之，我決定使用 Elixir 和 Phoenix，因為它是一個非常棒的組合。我還在所有頁面上使用即時視圖，所以希望它們之間的過渡超級平滑！ --- 原文出處：https://dev.to/danielbergholz/announcing-techschool-a-free-and-open-source-platform-to-learn-programming-47fk

0個讚 0留言 121瀏覽

小編精選 - 技術文章翻譯 · 01月21日

🏞️5 個可供學習並獲得靈感的開源網路應用程式🙇‍♀️💡

0個讚 0留言 193瀏覽

小編精選 - 技術文章翻譯 · 01月17日

從 Next.js 到 Rails 再到 Elixir：我的 React.js 倦怠之旅

我自 2019 年以來一直是 Web 開發人員。我使用 React.js 和基於 React 的框架，如 Gatsby、Next、Remix、Astro 和 Hydrogen。我從來沒有對這些工具感到完全滿意，但是，作為一個深入 JS 生態系統的初學者，我從同行那裡聽到的都是這樣的話：「這就是方式，任何其他程式語言要么慢，要么老」。 ![就是這樣](https://media.giphy.com/media/stnjSj2vpLcM4rwmEH/giphy.gif) 結果，我習慣了巨大的複雜性：多個獨立的儲存庫、數千個函式庫和框架來實現簡單的事情、GraphQL、微服務、無伺服器、靜態網站產生、增量靜態再生、部分水化、 redux 、redux-thunk、babel、webpack、react 伺服器元件、伺服器操作等。這個清單還可以再持續 10 分鐘。直到有一天我說**受夠了！** 讓我們來看看我慢慢發瘋的完整時間線。這需要一段時間，在閱讀長篇文章之前，請隨意煮點咖啡！ --- ## 倦怠的時間表 ### [Gatsby.js](https://www.gatsbyjs.com/) 我記得完成我的訓練營並想：“我終於能夠建立我的作品集了！”，所以我做到了。只有一個小問題，我想在 Google 上建立索引，但是使用舊的「create-react-app」使這項任務幾乎不可能完成。很快我了解了 SEO 和 React 的水合循環，這讓我找到了這個問題的「解決方案」：Gatsby.js。靜態網站產生的想法對當時的我來說簡直是革命性的，畢竟沒有什麼比預先渲染 HTML 檔案更快了，對吧？我決定透過閱讀文件來學習這個新框架，讓我告訴你，這**不是**一次有趣的體驗。我以前從未聽說過 GraphQL，顯然，您需要它來產生所有靜態檔案（到底是什麼？？？）。我問我的一些網友，很難學習這些過度設計的廢話是否正常，他們回答說「技能問題，再努力一點！」。於是我更加努力，終於學會了之後，我把我的個人網站移植到了Gatsby上。 ![再努力一點](https://media.giphy.com/media/gzRiZROEyDCznPofKj/giphy.gif) 我的大部分頁面都成功在 Google 上建立了索引，幾個月來，我對結果非常滿意。然後另一個問題出現了：我的**很多**開發者朋友開始說“Gatsby 死了！建立 Next 是為了簡化靜態站點生成並提供伺服器端渲染”。 ### [Next.js](https://nextjs.org/) 我快速瀏覽了 Next 文件並**立即**愛上了它。我能夠在沒有 GraphQL 的情況下用三分之一的程式碼做與 Gatsby 相同的事情！我再次將我的作品集移植到另一個框架：Next。這次我確實有一次美好的經驗。部署到 Vercel 輕而易舉，「getStaticProps」和「getServerSideProps」功能很簡單，但功能非常強大，我可以選擇每個頁面的渲染樣式，整體來說非常靈活。不幸的是，我透過慘痛的教訓學到了一些東西：在 JavaScript 生態系統中，所有美好的事情都會結束。 ### [混音](https://remix.run/) 我清楚記得 Remix 發佈時的情景。多名科技影響者開始發布有關它的內容（一如既往）。然而，當時我在主頁上看到它不支援靜態網站生成，只支援伺服器端渲染，所以我想「等一下，這些年來投資於 [JAMstack](https://jamstack.org/) 都被扔在這裡了嗎？不可能，這個框架不會長久」。然而，令我驚訝的是，Remix 不僅生存了下來，而且還被 Shopify 收購 https://shopify.engineering/remix-joins-shopify ，並成為 Next 的重要競爭對手。幾個月過去了，我決定嘗試看看。我再一次感到驚訝，Remix 的主要座右銘是使用 Web 基礎知識，而不是像 Next 這樣過於複雜的快取系統。因此，在Remix 中編碼時，我腦中需要的思維模型要簡單10 倍：沒有全域狀態管理器，只需使用URL，更少的客戶端狀態，將所有邏輯移至伺服器，並使用cookie，無需使用完整堆疊中間的 REST API 非常簡單，只需將資料庫查詢移至「loader」函數即可。 ### 離開矩陣 ![離開矩陣](https://media.giphy.com/media/11e0gEWxYoSYTK/giphy.gif) 然後，突然間，真相呈現在我面前，我服下了紅色藥丸。我的腦海中開始浮現出多個問題：Remix 不就像所有其他「古老而無聊」的框架（如 Rails、Laravel 和 Django）一樣嗎？幾十年來，我們一直在使用伺服器端渲染進行全端 Web 開發，但 JavaScript 黑手黨集體認為這種方法是垃圾，將所有內容移至客戶端才是未來。難道同一個黑手黨認為 Rails 一直都是對的嗎？用 JS 框架做所有那些過度設計的怪物不是正確的舉動嗎？我開始質疑一切。這種「新」的 Web 開發方式更加簡單、快速。 ### 我已經完成了 Next 和 Vercel 我透過 [Next.js 應用程式路由器](https://nextjs.org/docs/app) 達到了臨界點。以下是 Vercel 向 Next 推送的所有錯誤的完整清單： - 曾經簡單的：「getStaticProps」和「getServerSideProps」函數現在變得複雜而麻煩。目前，沒有特定的位置來新增 API 呼叫或資料庫查詢，您可以將它們寫入任何您想要的位置！在多年前使用 PHP 犯了同樣的錯誤之後，我們開始再次將業務邏輯與 UI 混合。難道前端開發者不吸取過去的教訓嗎？如果我刪除按鈕會發生什麼事？這是否會破壞我的使用者身份驗證流程，因為資料庫呼叫位於其中？您的前端應該 100% 可廢棄且可更換。你相對於競爭對手的競爭優勢在於業務邏輯，它應該與 UI 層完全隔離。 ![可怕的 Next.js 程式碼](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kp41ds14loo21xgimcza.png) - 接下來是伺服器優先。這聽起來沒那麼糟吧？畢竟，這解決了 SEO 問題並立即向用戶展示新鮮內容。問題在於，大多數現有的 Next 程式碼庫都依賴客戶端程式庫，例如樣式元件和一些全域狀態管理器。這是什麼意思？隨著此類重大變化的不斷發生，您的應用程式將在幾週而不是幾年內變成遺留軟體。更多的時間花在保持所有依賴項最新上，而不是做重要的事情：發布功能。 - Vercel 從 Meta 聘請了多名 React 核心團隊成員。這帶來了嚴重的利益衝突，因為這些工程師現在（據稱）正在發布有利於 Next 的功能，而不是優先考慮那些可以幫助所有基於 React 的框架（如 Remix）的功能。 ![Vercel 正在破壞 React](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9ye40ykjgrd3z10t5nx7.png) 我再也受不了了。我對自己說：你知道嗎？我厭倦了一遍又一遍地重新學習相同的框架，我完全不同意這種新的範式。毫不奇怪，其他內容創作者也經歷了類似的情況： https://youtu.be/zkCBSz353fc?si=z3-FDVgcB3xfp06h https://youtu.be/Zt8mO_Aqzw8?si=10fy1d-ZoB7t3Uc_ --- ## 啟蒙之路我非常累。在厭倦了所有的 React 工具後，我開始了尋找更簡單的 Web 框架的旅程。以下是我一直在尋找的先決條件： - 含電池 - 約定優於配置 - 良好的開發體驗 - 現代化且高性能的前端我的第一個反應是查看 [Stack Overflow Survey 2023](https://survey.stackoverflow.co/2023/#section-most-popular-technologies-web-frameworks-and-technologies) 中的頂級框架。我立即從清單中刪除了所有與 JS、C# 和 Java 相關的內容。我從來沒有興趣學習後兩個，它們看起來醜陋且冗長。所以剩下的選項是：Laravel (PHP)、Django (Python)、Rails (Ruby) 和 Phoenix (Elixir)。 Python 是我在網路工程學位期間使用的語言，我獲得了非常愉快的體驗。 Django 似乎遵循約定優於配置的理念，但最終讓我放棄它的是沒有一個好的內建工具來在前端工作。論壇上的大多數人都說他們使用[HTMX](https://htmx.org/) 和[Alpine](https://alpinejs.dev/)，但是，兩者都是您需要安裝的外部依賴項。放棄Laravel 是非常困難的，因為它具有驚人的成本效益，有數百個官方軟體包可以處理新創公司可能需要的幾乎所有內容，例如託管、身份驗證、條紋支付等。對於前端，他們創造了[慣性。Node.js](https://inertiajs.com/)，這是一種非常簡單而優雅的方式，可以在前端使用 React 的同時保持 Laravel 的高生產力和強大功能。百分之百誠實地說，我沒有選擇 Laravel 的唯一原因是 PHP 的語法，它看起來很難看，到處都是一堆 `$` 和 `->`。 ### Ruby on Rails Ruby on Rails 無需介紹。它是 Web 開發框架的元年，其革命性的「15 分鐘建立部落格」至今仍令人印象深刻。在我開始抱怨我發現的所有問題之前，讓我們先從好的方面開始。與 Python 類似，Ruby 是一種可以向非技術人員展示的語言，他們會理解該軟體想要做什麼。它是**迄今為止**我見過的最容易閱讀和最美麗的語言。我很快就意識到，[編寫視覺上令人愉悅的程式碼](https://world.hey.com/dhh/a-writer-s-ruby-2050b634) 是Rails 團隊的首要任務，這對我來說來說是新的。更不用說 Rails 幾乎發明了「包含電池」和「約定優於配置」的哲學，所以這不會是一個問題。在一份文件中，我提供了任何類型的 Web 應用程式所需的一切。在前端，有 [Hotwire](https://hotwired.dev/)，這是一種非常簡單且輕量級的方法，可以實現 SPA 框架提供的所有 UX 改進。我一直很好奇測試這個庫的極限，它看起來非常有前途。好吧，Rails 在紙面上滿足了我想要的框架的所有先決條件。我們來試試吧！我在本地測試的第一件事是“railsscaffold”命令。我立即感到震驚。一個指令就能產生 CRUD 所需的一切？決不！ ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/58lbioexmot9412kojr5.png) 在 Node + React 領域，要實現相同的目標，我需要手動編寫所有程式碼（這裡沒有生成器）並安裝一堆程式庫，例如：Vite、prisma、express、react router、redux、redux-thunk 、 vitest、cypress 、react 測試庫、zod、typescript、eslint、prettier、1000 個不同的插件，甚至可能還有GraphQL 或tRPC。基本上就是一個已經有 900 個依賴項的 package.json。在“railsscaffold”最初的震驚之後，當我從控制器打開程式碼時，我再次震驚了： ``` class ArticlesController < ApplicationController def index @articles = Article.all end def show @article = Article.find(params[:id]) end def new @article = Article.new end def create @article = Article.new(article_params) if @article.save redirect_to @article else render :new, status: :unprocessable_entity end end def edit @article = Article.find(params[:id]) end def update @article = Article.find(params[:id]) if @article.update(article_params) redirect_to @article else render :edit, status: :unprocessable_entity end end def destroy @article = Article.find(params[:id]) @article.destroy redirect_to root_path, status: :see_other end private def article_params params.require(:article).permit(:title, :body) end end ``` 這是所有後端程式碼嗎？只需幾行？這不可能！這非常簡單，看起來就像一個「低程式碼」工具。它簡單、優雅、可讀性極強，這是我們在 JS 領域很少見的。好吧，好吧，你現在一定在想：「這個來自網路的瘋狂 React 開發者說他最終使用了 Elixir，所以 ruby 一定有問題！」。你是對的，我的匿名朋友，有些事情讓我很惱火，讓我們談談。首先，我們需要解決房間裡的大象：從 React + Typescript 轉向動態類型語言並不容易。從我開始編寫程式碼的那一刻起，我的 VScode 上就沒有出現智慧感知或充滿程式碼建議的下拉式選單，我感到盲目和迷失。這是一種可怕的感覺，我可能會在函數名稱上輸入錯誤，直到網站投入使用時才意識到！我知道我們可以編寫測試，但這是我希望在 IDE 上立即辨識的錯誤類型，而不是在測試或部署期間辨識。另一件我以為我會喜歡但最終討厭它的事情是：太多的魔法。在 Typescript 程式碼庫中，我可以點擊任何類別或函數的頂部，前往原始程式碼並查看其實作方式。在 Rails 上，我到底在哪裡進行驗證（例如）？我是否在控制器內建立私有函數？有專門的資料夾嗎？不，正確的位置是在模型內部。為什麼？因為這就是它的工作原理，所以您要么採用該約定，要么很難編寫 Ruby 程式碼。我根本無法對一切在幕後如何運作產生“直覺”，我必須盲目地相信維護者在組織一切方面做得很好。為了解決我的挫折感，我開始寫前端程式碼。如何建立元件？ [部分](https://guides.rubyonrails.org/layouts_and_rendering.html#using-partials)。如何定義該元件的 prop 類型？沒有辦法做到這一點，您需要打開它並直觀地查找其中的所有變數。做一些互動怎麼樣？建立國家？嗯，有帶有 [Stimulus](https://stimulus.hotwired.dev/) 的 Hotwire，但是正如您所看到的，您需要手動建立“重新渲染”功能，它沒有找到一種方法像React 這樣改變狀態後自動重新渲染頁面。 ``` // src/controllers/slideshow_controller.js import { Controller } from "@hotwired/stimulus" export default class extends Controller { static targets = [ "slide" ] initialize() { this.index = 0 this.showCurrentSlide() } next() { this.index++ this.showCurrentSlide() } previous() { this.index-- this.showCurrentSlide() } showCurrentSlide() { this.slideTargets.forEach((element, index) => { element.hidden = index !== this.index }) } } ``` 我再一次感到沮喪。我非常接近找到完美的框架！如果 Rails 失敗，我想嘗試的下一個框架是什麼？靈丹妙藥。 ### 長生不老藥和鳳凰我必須說實話，我已經沒有耐心了。我嘗試了多種不同的生態系統，我幾乎確信要堅持使用 Ruby on Rails，並放棄對完美的追求。直到我的 YouTube 推薦部分出現了一個影片： https://www.youtube.com/live/bfrzGXM-Z88?si=Xsa7yCKeVSY5R3sT 堅持，稍等！在這裡我們可以看到一位 React 開發人員說了很多關於函數式程式設計、Elixir 和 Phoenix Live View 的好話。也許我應該嘗試一下！我做的第一件事就是打開Elixir 和Phoenix 的文件，我真的很喜歡這樣一個事實：所有包都使用[Hex Docs](https://hexdocs.pm/) 以相同的方式進行記錄，您只需要取得習慣於單一介面以學習新事物。另一個好處是，您只需閱讀文件即可真正學習 Elixir，無需昂貴的課程！在其他所有生態系統中，我必須透過付費課程學習語言，然後透過閱讀文件來學習框架。然後是時候開始編寫程式碼了。很快我就明白函數式程式設計與 OOP 有很大不同。我們來做一個小小的比較： ``` // JS const obj = {name: "daniel"} obj.age = 25 // result: obj = {name: "daniel", age: 25} ``` ``` # Elixir obj = %{name: "daniel"} obj = Map.put(obj, :age, 25) # result: obj = %{name: "daniel", age: 25} ``` 或者您可以使用管道運算子透過更簡單的語法實現相同的效果： ``` # Elixir with pipe operator obj = %{name: "daniel"} |> Map.put(:age, 25) # result: obj = %{name: "daniel", age: 25} ``` 最初，您可能會發現它的可讀性較差且更複雜，但我保證隨著時間的推移它會變得有意義！嗯，至少對我來說是這樣。身為 React 開發人員，我已經習慣了到處都可以看到多個函數，甚至前端元件也是函數！更不用說建立類別有時被 JavaScript 黑手黨視為一種程式碼味道。我的大腦已經針對這種新範式進行了“塑造”，這對我來說很自然。自從我在大學獲得網路工程學位以來，我上過幾門關於物件導向程式設計的課程，但它從來沒有「受歡迎」。我無法將複雜的問題建模為類別和物件。隨著時間的推移，使用多個函數來「改變」一個變數是我在腦海中建模的方式。主要框架怎麼樣？包含鳳凰電池嗎？約定優於配置？ **是的！** 老實說，生態系統與 Rails 不在同一水平，但已經達到了 95%。除非您需要非常具體的功能，Phoenix 都能滿足您的需求。我幾乎被 Elixir 迷住了，我的清單中缺少兩件事：良好的開發人員體驗和現代/高效能的前端程式碼。 José Valim 宣布他正在嘗試為該語言加入類型，但 Elixir 目前還沒有這些類型，所以我很擔心。如何在沒有類型的情況下獲得智能感知和自動完成？很快我發現這些功能不一定相關。在 VScode 上安裝 [ElixirLS 擴充功能](https://marketplace.visualstudio.com/items?itemName=JakeBecker.elixir-ls) 後，我感到很驚訝。可以在隨機資料夾的隨機模組內定義函數，將其導入其他位置，並取得它的智慧感知和文件！我從靜態類型語言中獲得了這些好處，而無需編寫類型的麻煩，簡直太棒了！ https://elixir-lang.org/blog/2022/10/05/my-future-with-elixir-set-theoretic-types/ 我對前端的最後一個擔憂是由 Phoenix [Live View](https://hexdocs.pm/phoenix_live_view/welcome.html) 解決的。在程式碼方面，這正是文件主頁中讓我信服的部分： ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5sjzj90khytebnk523fm.png) 您可以為每個元件定義“props”，如果類型不匹配，您的 IDE 中會出現錯誤，就像 React 一樣！感人的！使用者體驗怎麼樣？每當使用者點擊連結時是否會載入整個頁面？一定不行！即時視圖與客戶端建立 WebSocket 連接，然後每次頁面轉換只是透過 Websocket 進行內容交換，不會發出新的 HTTP 請求。此外，所有狀態都在伺服器端進行管理，這意味著 Trello 等豐富的用戶體驗過去由於加載過多的 JavaScript 而在客戶端非常卡頓，現在變得非常快！ Elixir 處理所有複雜的狀態邏輯並將頁面的更新部分傳送到前端。看看這裡的完整解釋： https://youtu.be/wrmVk2czqMg?si=ZoWAlPjQC-svmV3Y 由於我們使用 WebSocket 來建立 UI，因此建立像 Twitter 這樣的「即時」應用程式只需要幾行程式碼！ https://youtu.be/MZvmYaFkNJI?si=gAow6oIjgf8_OTkg ## 結論可以肯定地說，「完美的技術堆疊」並不存在。解決所有問題的靈丹妙藥是我們在腦中創造的幻覺，以不斷尋找和建構最優化的工具。然而，在個人層面上，完美的堆疊確實存在。因為每個開發人員都有偏好，您可以輕鬆找到適合您標準的工具。如果你有和我類似的旅程，完美的可能就是長生不老藥和鳳凰！所以試試看吧，也許你會像我現在一樣喜歡它。如果您讀到了這篇文章的結尾，那您就太棒了！非常感謝您抽出寶貴的時間，希望我能為您的職業生涯帶來一些價值。 ![結束](https://media.giphy.com/media/lD76yTC5zxZPG/giphy.gif) --- 原文出處：https://dev.to/danielbergholz/from-nextjs-to-rails-then-elixir-my-journey-through-reactjs-burnout-h8d

0個讚 0留言 298瀏覽

小編精選 - 技術文章翻譯 · 11月12日

我使用了幾款文字編輯器的心得：sublime、vim、emacs、vscode

0個讚 0留言 461瀏覽

小編精選 - 技術文章翻譯 · 11月10日

CRUD API 掰掰啦！該用用看 ElectricSQL 的即時 PostgreSQL 功能囉！

原文出處：https://dev.to/lovestaco/good-bye-crud-apis-hello-sync-realtime-postgresql-with-electricsql-1f8j ## API 的混亂：我們的互動是否過於複雜？ Web 應用程式上的每個操作都會觸發一系列網路呼叫。以在 Instagram 等社群媒體平台發佈貼文為例。開啟貼文會觸發 _GET_ API 呼叫，點擊「讚」會觸發 _POST_ API 呼叫，評論會引發另一個 _POST_ API 呼叫。每次互動、每次點擊和每次提交都會從前端到後端發出一串 API 呼叫，以獲取或更新資料庫中的資料。這種傳統的設定雖然實用，但卻在使用者介面和後端之間堆積了多層互動。每個新增的層都是潛在的故障點、延遲點或瓶頸。對於開發人員和工程師來說，管理這種複雜的 API 可能是一項日常工作。每個 API 呼叫都經過精心設計、測試和維護。時間和資源方面的開銷是真實存在的。此外，另一端的使用者經常發現自己在等待這些網路呼叫完成，即使只是一瞬間。在速度和即時互動決定使用者體驗的時代，這些微小的延遲可能會累積起來，影響使用者的參與和滿意度。現在，想像一個可以減少大量 API 呼叫的設置，一個允許與資料庫直接互動、消除延遲和混亂的設置。這就是 _ElectricSQL_ (ESQL) 發揮作用的地方... ## ElectricSQL：消除 API 混亂 ESQL 提出了一種更乾淨、簡化的方法。它與 Postgres DB 一起執行，減少了對多個 API 呼叫的需求。使用 ESQL，評論或投票等操作在瀏覽器本機儲存 (SQLite) 內的專用表中處理，然後與 Postgres 同步。此設定無需呼叫後端 API 將資料儲存到 Postgres，從而減少了通訊層數和相關延遲。前端和資料庫現在可以更直接、更有效率地互動。這簡化了開發人員的工作流程並加快了前端的使用者互動速度。現在讓我們看看這是如何實現的以及內部發生了什麼。 ## 使用 Electric 實現瀏覽器和 Postgres DB 之間的交互 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/mo9tibjk0w89uada9d8v.png) 此圖示範了瀏覽器和 Postgres 資料庫之間透過_Electric 服務_進行的通訊路徑。本質上，[Electric Sync Service](https://electric-sql.com/docs/usage/installation/service)，一個[Elixir應用程式](https://elixir-lang.org/)，https://electric-sql.com/docs/intro/active-active 使用者本地資料庫與Postgres之間的資料複製。瀏覽器透過 [electric-sql](https://www.npmjs.com/package/electric-sql) 函式庫與本機資料庫互動。本地資料庫連接到_Electric服務_，Electric-SQL中有一個衛星，用於與_Electric服務_通信，並用於本地資料庫和Postgres之間的資料複製。每當本地資料庫或 Postgres 中發生資料變更時，_Electric 服務_ 都會充當衝突解決程序，確保無縫資料複製。此配置無需呼叫 API 來儲存評論或更新等新資料條目，從而簡化了資料互動過程。繼續閱讀全文 [https://journal.hexmos.com/reduce-apis-using-electric/](https://journal.hexmos.com/reduce-apis-using-electric/)

0個讚 0留言 145瀏覽

小編精選 - 技術文章翻譯 · 02月22日

適用於各種軟體開發技能：2023 推薦練習的專案開發

0個讚 0留言 1,483瀏覽

歡迎發文

💡 記錄日常工作的實踐、心得

💡 發表對生活和職場的感悟

💡 針對感興趣的事件發表隨筆或者雜談

💡 詳細介紹你掌握的一門語言、一個技術，或者一個興趣

💡 或者，就直接把你的部落格搬到這裡（支援 API 可以撈）