直接建置：我們如何設計 Streamlit 來引導您取得進步

最初由 Thiago Teixeira 在 Streamlit 部落格上發佈

如果您正在閱讀本文，您可能已經熟悉 Streamlit。如果沒有，這裡有一個總結：Streamlit 是一個用於建立資料應用程式的 Python 框架。它固執己見，包含電池，並且與特定的設計系統緊密相連。

• 它專注於數據應用。 我們所做的一切都源自於此。我們的目標不是手機上的通用應用程式或您最喜歡的 SaaS，而是資料科學家和機器學習工程師需要使他們的工作對組織產生影響力的應用程式類型。
• 這是固執己見的，因為我們希望促進快速、迭代的工作流程，並堅持我們認為的工程最佳實踐。
• 它包含電池所以您開始使用所需的大部分內容都在庫本身中。
• 最後，它與設計系統相關，因此您無需花時間建立元件庫、視覺語言或標誌。您才剛開始，而且速度很快。

此時，我可以告訴您我們是如何開始 Streamlit 的。根據我們之前在工業界和學術界的經驗，關於它是如何從良好的預感開始的。關於我們如何深入不同的公司並觀察他們的資料科學家和機器學習工程師的工作方式以塑造 Streamlit。但 Adrien 在 5 年前就已經做得很好了，我認為我無法超越！

因此，我將討論我們對資料應用程式的深度關注如何轉化為我們每天做出的產品決策。為此，我將從一個故事開始......

10 名新進員工

曾幾何時，一個數據科學團隊為公司最重要的指標建立了一個強大的預測模型。財務團隊看到了它並且很喜歡它，然後要求提供一個可以在每週會議中使用的即時版本。因此，資料團隊向工具團隊提出了建立資料應用程式的請求，工具團隊將其放入佇列中。

三個月和多次會議後，應用程式交付了，它很漂亮。

但有一個問題：當財務部門嘗試時，這並不是他們所需要的。因此，他們向資料團隊提出了另一個請求，資料團隊將其傳遞給工具團隊，工具團隊將其放入隊列中。幾個月過去了。

此時，一位毫無戒心的新員工加入了數據團隊，並被分配了一個啟動項目：在等待工具團隊的真正的應用程序時，組裝一個快速數據應用程序來解鎖財務團隊.

經過一番谷歌搜尋後，新員工發現了 Streamlit，並在一天之內就能夠與同事分享一個最小的應用程式。它並不完美，但她解決了一些反饋並更新了應用程式。第二天，她向財務團隊的聯絡人展示了該應用程序，獲得了更多反饋，並相應地改進了應用程式。

三天之內，財務團隊在會議中定期使用該應用程式。他們收到了更多回饋，新員工很快就在新版本中解決了這個問題。

一週之內，執行長就開始使用該應用程序，新員工被譽為英雄？

為什麼會發生這種情況

我們已經無數次看到這個故事發生了。新員工的應用程式最終獲勝的原因是今天的簡單應用程式比晚了三個月的過度設計的應用程式要好。

事實上，這正是最好的新創公司建立產品的方式！他們發布最小可行產品（MVP），盡快將其交到客戶手中，並不斷迭代。

在過程中，他們逐漸強化底層基礎設施。因為新員工的故事有一個推論：隨著團隊繼續使用該應用程序，他們逐漸將其生產化。

那套客製化的 Pandas 轉換速度超慢？他們將其拉入單獨的資料管道和一些物化表中。

其他應用程式想要使用的複雜計算？他們將其轉移到 RESTful 服務。隨著應用程式的發展，他們將其重構為多個頁面。他們編寫測試，建立 CI。該應用程式變得防彈。

此流程的好處是顯而易見的：

1. 您可以建立更好的應用程式，因為在嘗試之前您通常不知道自己需要什麼。因此，透過構建和用戶測試，然後再次構建和用戶測試，你最終會得到一個更好的應用程序，而不是提前計劃好整個事情，但後來才意識到這不是你想像的解決方案。
2. 從第一天起您就獲得了價值。 當您建置和使用者測試時，您已經擁有了一個有用的應用程式。而且它只會變得越來越有用。
3. 您不會過度建造。 您不必在建立應用程式的同時建立管道，只需將應用程式拿出來，然後在證明其有用性時對其進行強化。然而，並非所有應用程式都有用，也並非所有有用的應用程式都存在足夠長的時間來需要強化。因此，您只會將寶貴的大腦週期花在既有用又持久的應用程式上。

開始的方式很簡單：只需建造它。

用心設計

我們認為新進員工的故事發生在這麼多不同的公司絕非偶然。我們喜歡認為這個故事的發生是因為我們有意設計 Streamlit 來促進前進。

當您第一次開始編寫應用程式時，前進進度意味著在 5 ​​分鐘內完成一份草稿，並且在某些方面已經有用。毫無疑問，讓應用程式變得更有用的一件事就是互動性。因此，從一開始，我們就有一種強烈的感覺，那就是我們應該讓互動性盡可能簡單。

例如，您不必建立一個帶有滑桿的“視圖”，然後建立一個帶有回呼函數的“控制器”來修改滑桿使用的“模型”（換句話說，MVC 範例）。相反，我們想出了一個單行解決方案：

value = st.slider("選擇一個數字", 0, 100)

您輸入該內容並獲得一個已經執行某些操作的應用程式。 前進！

然後，在兩年後建立 Session State 時，我們很快就了解到所提出的 API 很容易導致差一錯誤，而唯一有效的解決方案是回調。我們過去使用MVC 和類似範例的經驗給我們帶來了創傷，我們花了相當多的時間來解決這個問題，想出了一個明確的“Streamlit-y”版本的回調，避免了所有的複雜性。而且 - 更重要的是 - 該解決方案不會強迫您從一開始就使用回調，而是允許您稍後根據需要對它們進行分層。 前進！

另一個對我們（當然還有社區）來說很親近的例子是造型。一方面，我們要做的最簡單的事情就是直接在 Streamlit 中加入對 CSS 的支持，例如 st.css(...) 或 st.write(..., style="css 位於這裡」）。但當我們嘗試它時，我們注意到不受限制的樣式訪問很快就會成為前進的障礙。人們並沒有將第一個版本提供給利害關係人，而是陷入了梳理 MDN、對抗級聯、調整選擇器以及沉迷於單一像素的困境。而且，最糟糕的是，最終結果往往是不穩定且分散注意力的。

因此，我們透過問自己以下問題來解決這些請求：

• 「人們試圖解決的根本問題是什麼？」
• 「這個問題有多常見？」
• 「我們可以自己解決這個問題並幫助解放開發者嗎？」

根據這些問題的答案，我們採用以下兩種方法之一：

1. 為問題提供單行、固執己見的解決方案

   這件事發生在幾個月前。我們注意到大量開發人員使用 CSS hacks 將徽標放置在應用程式的左上角，因此我們決定為他們提供 st.logo() 的單行解決方案。這個新命令繪製他們的自訂徽標，使其響應側邊欄的狀態，確保它不重疊任何內容，並且預設情況下看起來不錯。

   這也是我們添加文字顏色、標題下的線條、容器周圍的邊框、垂直對齊、材質圖示等的方式。就視覺效果和行為而言，它們當然是固執己見的解決方案，但優點是您只需說出您想要的內容，Streamlit 就會做到，然後您就可以繼續進行下一件事。 前進！

2. 提供一組精選的旋鈕…然後觀看

   當單行固執己見的解決方案無法解決問題時，我們會引入一組最小的“旋鈕”，觀察結果並迭代。由於我們不想破壞相容性，因此我們的大多數功能都是單向門，這意味著我們必須謹慎行事。

   一個例子是主題。每個人都希望他們的應用程式與公司的顏色相匹配，當然，確切的顏色因公司而異。但 Streamlit 的介面由幾十種顏色組成，選擇視覺上令人愉悅的組合可能會花費數小時。因此，我們解決這個問題的第一個嘗試是讓您只選擇 4 種顏色，Streamlit 會為您計算所有其他顏色。 前進！

   我們現在正忙於在幕後思考針對這個問題的第二次嘗試——一個擴展的解決方案，為您提供更多的旋鈕（甚至超越顏色！）而不犧牲迭代速度。同樣，我們也在考慮除列之外的新的、更靈活的佈局選項。

   我們現在沒有什麼要宣布的，但請務必留意？

總之，我們不希望任何事情分散您對前進的注意力。我們採取的每一步，都盡最大努力提供一個框架，抽象化 HTML、JS、CSS、HTTP、路由、序列​​化、回調和各種工程細節。這樣，您就可以專注於讓利害關係人掌握數據的力量，這樣他們也可以取得進展。

迭代成就完美

在 Streamlit，我們自己就是 Streamlit 的狂熱用戶，這意味著我們有自己的煩惱和功能請求。我們分享您的痛點，並且我們始終對庫進行迭代​​。我們永遠不想停止迭代！我們對此的承諾體現在我們每月發布新版本的方式上。

Streamlit 社群和您的聰明才智也為我們帶來了啟發。我們不斷遇到應用程式和自訂元件，它們以我們從未想過的方式突破了 Streamlit 的界限，為我們提供了將事物引入核心庫的新想法。社區無疑是這項工作中最好的部分！

因此，我們為您準備了更多內容。我們的開發是開放的，因此您始終可以在roadmap.streamlit.app 上找到我們的路線圖，或者參加下一季度展示會，我們的產品經理將在其中討論Streamlit 的最新動態，例如垂直對齊和高級主題。

迭代的美妙之處在於，最好的日子總是在前方。我們很榮幸能與您同行。

串流媒體快樂！ ？

以上是直接建置：我們如何設計 Streamlit 來引導您取得進步的詳細內容。更多資訊請關注PHP中文網其他相關文章！