Svelte

在Svelte中处理单个组件的状态非常简单。 但是如何在组件之间传递状态呢？ 使用props传递状态 第一种策略是其他UI框架常见的策略，即使用props传递状态，将状态上升。 当一个组件需要与另一个组件共享数据时，可以将状态上升到组件树中的共同父级。 状态需要通过props传递，直到到达需要此状态信息的所有组件。 这是使用props完成的，我认为这是最好的技术，因为它很简单。 有关props的更多信息，请参考Svelte Props教程。 Context API 有些情况下，props并不是一个实用的方法。也许两个组件在组件树中距离太远，我们必须将状态移动到顶层组件。 在这种情况下，可以使用另一种技术，称为context API，它非常适合让多个组件与后代组件进行通信，而无需传递props。 context API由svelte软件包提供的两个函数提供：getContext和setContext。 您可以设置与键关联的上下文对象： <script> import { setContext } from 'svelte' const someObject = {} setContext('someKey', someObject) </script> 在另一个组件中，您可以使用getContext来检索分配给键的对象： <script> import { getContext } from 'svelte' const someObject = getContext('someKey') </script> 您只能在使用setContext的组件或其子代之一中使用getContext检索键。 如果要让两个位于两个不同组件树中的组件进行通信，那么我们还有另外一个工具：stores。 使用Svelte stores 当组件需要相互通信而无需传递太多props时，Svelte stores是一种非常好的工具来处理应用程序的状态。 首先，您必须从svelte/store中导入可写的writable： import { writable } from 'svelte/store' 然后使用writable()函数创建一个存储变量，将默认值作为第一个参数传递： const username = writable('Guest') 这可以放在一个单独的文件中，您可以将其导入多个组件中，例如称为store.js的文件中（它不是一个组件，因此可以是.js文件而不是.svelte）： import { writable } from 'svelte/store' export const username = writable('Guest') 加载此文件的任何其他组件现在都可以访问存储：...

假設您正在使用 Sapper 建立一個 Svelte 應用程式，並且您有一個動態的頁面路由，例如 /routes/[id].svelte。 您想要獲取 URL 的動態部分（在此案例中是 id），並且您知道可以在元件的 <script context="module"> 段落中的 preload() 函數中獲取它： <script context="module"> export async function preload({ params }) { const { id } = params } </script> 但問題是，您需要在 preload() 之外使用它，以執行其他操作。 解決方式是從 preload 中返回它，並使用通常的 export * 語法將它定義為元件的 prop。 以下是一個示例： <script context="module"> export async function preload({ params }) { const { id } = params return { id } } </script> <script> export let id if (typeof window !...

Svelte 模板提供了一個很棒的 each 區塊，讓我們可以對陣列或任何可迭代的內容進行迭代： <script> let goodDogs = ['Roger', 'Syd'] </script> {#each goodDogs as goodDog} <li>{goodDog}</li> {/each} 但是，如果你想要根據一個變數重複執行區塊呢？假設我們有一個變數 rows 儲存了一個數字，我們想要使用它作為迴圈變數。 我們可以通過創建一個陣列並使用 Array(n) 的語法來實現我們的需求。這將創建一個以 n 項初始化的陣列： {#each Array(rows) as _, row} {row} {/each}

如何避免 Svelte 將模板的部分內容渲染到客戶端 HTML 註釋非常適合在頁面中隱藏元素。 在 HTML 中，您可以這樣添加註釋： <!-- 這裡是一個註釋 --> 您也可以在區塊中使用註釋，以隱藏多行 HTML 代碼： <!-- 這是一個 註釋 在這裡 --> 請注意，這仍然可以在頁面源代碼中看到。瀏覽器只是將其隱藏起來，但可以隨時查看該註釋。 您可以在 Svelte 模板中使用相同的註釋。但是在 Svelte 中，您不會將被註釋的部分發送到瀏覽器。該部分被完全刪除，只保留在源文件中，對頁面生成的 HTML 不可見。 這在我看來是一個好事情。

學習如何在Svelte中使用props，讓具有父子關係的兩個組件彼此通信。 您可以使用import ComponentName from 'componentPath'的語法將Svelte組件引入到任何其他組件中： <script> import SignupForm from './SignupForm.svelte'; </script> 路徑相對於當前組件路徑。./表示“這個相同的文件夾”。您可以使用../回到上一級文件夾，以此類推。 一旦這樣做，您就可以在標記中使用新引入的組件，就像使用HTML標籤一樣： <SignupForm /> 通過這種方式，您正在形成兩個組件之間的父子關係：一個是導入組件，另一個是被導入組件。 通常情況下，您希望父組件將數據傳遞給子組件。 您可以使用props來實現。props的行為類似於純HTML中的屬性，它們是單向通信的形式。 在這個例子中，我們將disabled prop傳遞給它，並將JavaScript值true傳遞給它： <SignupForm disabled={true}/> 在SignupForm組件中，您需要導出disabled prop，如下所示： <script> export let disabled </script> 這是表明該prop對父組件可見的方式。 在使用組件時，您可以傳遞一個變量而不是一個值，以動態更改它： <script> import SignupForm from './SignupForm.svelte'; let disabled = true </script> <SignupForm disabled={disabled}/> 當disabled變量值變化時，子組件將以新的prop值進行更新。例如： <script> import SignupForm from './SignupForm.svelte'; let disabled = true setTimeout(() => { disabled = false }, 2000) </script> <SignupForm disabled={disabled}/>

我在使用Svelte時遇到了一個需求，需要在元素上動態應用一些CSS屬性，當其中一個變量具有特定的值時。 我找到的最簡單的解決方案是在selected變量值為true時添加一個HTML類，然後我寫了一些針對具有該類的元素的CSS： <style> /\* ...其他CSS... \*/ span.cell.selected { outline-color: lightblue; outline-style: dotted; } </style> <span class="cell {selected === true ? 'selected' : ''}"> {value} </span> 這種需求是如此常見，以至於Svelte添加了將類名綁定到變量值的功能： <span class="cell" class:selected="{selected}"> {value} </span> 更簡潔的方式是使用簡寫符號： <span class="cell" class:selected> {value} </span>

學習如何在Svelte中導入組件 Svelte提供了單文件組件。每個組件都在.svelte文件中聲明，在其中可以編寫所需的HTML標記、CSS和JavaScript。 下面是一個簡單的Svelte組件示例，保存在名為Button.svelte的文件中： <button>按鈕</button> 您可以在該組件中添加CSS和JS，但這個純HTML標記已經是組件的標記，無需用其他特殊標記包裹它。 要將該組件的標記從該組件中導出，您不需要做任何操作。現在，您可以使用import ComponentName from 'componentPath'語法將其導入到任何其他Svelte組件中： <script> import Button from './Button.svelte'; </script> 現在，您可以在標記中使用這個新導入的組件，就像使用HTML標記一樣： <Button />

學習如何從 Svelte 組件導出函數和變數 你知道可以使用以下語法將一個 Svelte 組件導入另一個組件中： <script> import Button from './Button.svelte'; </script> 如果你想要導出更多東西呢？ 那麼你必須在組件中使用特殊的 script 標籤，並添加 context="module" 屬性進行導出。 以下是一個示例。假設你有一個名為 Button.svelte 的 Button 組件： <button>A button</button> 而且你希望其他組件能夠修改該按鈕的顏色。你可以使用 props，這只是一個示例。或者你可以提供一個名為 changeColor 的函數。 你可以在這個特殊的 script 標籤中編寫並導出它： <script context="module"> export function changeColor() { //...添加邏輯... } </script> <button>A button</button> 警告：我沒有實現實際的功能，但你可以理解這個示例。 需要注意的是，你可以在組件中添加另一個“普通”的 script 標籤。 現在其他組件可以導入 Button（默認導出）和 changeColor 函數： <script> import Button, { changeColor } from './Button.svelte' </script>

當你想要建立一個新應用程式時，你有兩個選擇。 第一個選擇是使用你已經熟悉的技術來建立。如果你熟悉 React，那就繼續使用 React。 另一個選擇是選擇全新的技術堆疊。如果你熟悉 React，你可能會選擇使用 Svelte 或 Vue.js。如果你熟悉 Swift，你可能會選擇使用 React Native。 這是一個困難的問題，因為作為一個開發者，我認為我們應該平衡對某個技術的深入了解，成為該技術的專家，以及對各種技術都有一定的了解。 如果你所有的應用都使用 React，你就永遠不會知道 Vue.js 的優勢。相反的情況也是如此。 當 Twitter 或 Reddit 上出現關於 Vue vs React（或其他任何東西）的「在線戰爭」時，大多數時候，一方的支持者對另一方並不是非常了解，只是根據其他人的話來進行討論。 但在選擇技術堆疊之前，很少有時間能夠探索所有選項。 通常情況下，我可能會堅持使用我最熟悉的技術堆疊，目前恰好是 React 和 Next.js，除非我確定或認為其他技術是最佳選擇。三年後，我的默認選擇可能完全不同。我並沒有對工具產生依賴，我不是一個 React 開發者。我只是一個碰巧是軟體工程師的人，碰巧經常使用 React。 很久以前，我非常深入地研究了一個技術堆疊，然後一個新的項目出現了，其中使用 Node.js 或許是更好的選擇。我們作為一個團隊決定全力支持 Node.js，儘管我們遇到了很多未知的問題，但我認為這是一個不錯的選擇。 每次切換到新的技術堆疊時，你知道你正在放棄什麼，但你不知道你真正要面對什麼。 但這就是你建立專業知識的方式。下一個項目你就會知道這是否是一個好的選擇。只有時間能夠告訴你。

我已經在這個博客上寫了很長一段時間了。在這段時間裡，我涵蓋了許多不同的主題。 回顧往事，我從一些隨機的 Web 開發主題開始，然後專注於 Go、React、Node.js、CSS、HTML、瀏覽器 APIs、Next.js、Vue.js、Svelte、數據庫、Python、Swift，甚至電子學和 C 語言。 有時候，當我有希望寫一些與我通常所寫的主題不同的內容時，我會考慮一下。 這是我的博客，它不是一本名為“Web 開發”或其他類似的出版物。 儘管如此，當你長時間寫關於一個主題時，即使是像我這樣涵蓋了廣泛範圍的主題，你也會開始覺得自己與讀者之間有一個“合約”。 如果我決定寫關於 X 的內容而讀者對此不感興趣，會發生什麼事呢？他們會停止閱讀或關注這個博客嗎？他們會取消訂閱郵件通訊嗎？ 除非你完全偏離了主題，否則幾乎從不會有這種情況。 你讀到了上面的主題列表嗎？它們之間幾乎沒有什麼相關性，除了它們都與編程有關。但是一位 React 開發者對於 C 語言或 CSS 沒有興趣。 因此，廣泛的專業領域是編程，在這個領域下我可以寫關於任何事情。 如果我開始寫關於園藝、狗、或者徒步旅行之類的內容，那就不一樣了。 有時候我會談論商業方面的事情，或者內容的製作，但這些都是相關的。 我考慮過在旅行時寫一些類似“旅遊博客”的帖子，只是為了做些不同的事情。也許有一天我會寫，儘管我不想讓讀者困惑。還有 Google 啊哈哈。 對我來說，規則是寫我想寫的內容。每天寫一篇帖子是關鍵。否則我早就停下來了。如果有一天我想寫關於旅行、烹飪或其他任何事情的內容，我就會去寫。 有時候我寫一篇關於如何為數字遊牧在整個歐洲旅行期間設置我的面包車的帖子，說實話，關於這些主題我獲得了更多的回覆。也許只是因為在他們那個時代這有些不尋常。 我將來要做的一件事是開始寫關於 SwiftUI 和 iOS 開發的內容。我已經考慮了好幾個月了。其實，我想已經有幾年了。 但現在我覺得是合適的時候了。 過去，我決定寫一些我不是非常熱衷的主題，比如數據庫。我對數據庫有多少熱情呢？我開始寫了幾天後就停下來了。 但我想，我可以寫一些我對於 iOS 應用的想法，計劃階段，開發過程，上架 App Store，等等的內容，這可能是我的一部分讀者非常感興趣的內容。 也許他們也有一個 iOS 應用的想法，這可能會是他們開始的觸發點。 我是否對 Web 開發厭倦了？絕對不是。而且任何 iOS 應用也需要與 Web 或 API 相應的對應組件，所以這不意味著我會停止寫關於它的內容。 而且我喜歡 JavaScript。 我只是喜歡編程。用代碼創造事物。不管是 Web 應用、iOS 應用還是桌面應用，都無關緊要。 對我來說，改變一下我寫關於什麼的方式只是為了多元化並保持我的能量水平高。 對我來說一直都是這樣。我會工作在一個 Web 應用上，然後轉到 iOS 應用，然後再轉到 macOS 開發，然後再回到 Web 應用。...