研發實戰：Moziila分享混合現實編輯器MrEd的開發經驗和教訓

查看引用/信息源請點擊：映維網

MrEd是一個實驗性混合現實體驗編輯器

（映維網 2019年08月12日）MrEd是Moziila日前發布的一個實驗性混合現實編輯器，並旨在探索MR故事在線編輯的可能性。日前Mozilla團隊的Josh Marinacci分享了他們在開發過程中的經驗教訓。下面是映維網的具體整理：

當我們開始構建MrEd時，我們認為這會成為一種傳統的Web服務。潛在用戶訪問網站，創建帳戶，然後可以在網站構建體驗並將其保存到伺服器。我們以前開發過這樣的軟體，所以對相關要求十分熟悉。但當我們開始實際構建MrEd時，我們意識到其他挑戰的存在。

首先，MrEd的目標人群是學生，其中大多數是年輕人。我曾在幾個夏天輔導過孩子們，我知道他們通常沒有電子郵件地址，即使有，追蹤學生行為存在隱私和法律方面的問題。另外，我們知道這是一個終究會結束的實驗，但我們不希望學生失去對他們剛學到的工具的訪問許可權。

經過一番思考後，我們認為Glitch可能是一個答案。它支持匿名使用，並允許你輕鬆地進行利用。它內置了一個不錯的CDN，非常適合託管模型和360度圖像。如果能夠託管編輯器和文檔，Glitch將成為實驗完成後繼續存在的的完美平台。

Glitch的缺點是，它的大多數高級功能都沒有文檔介紹。經過大量研究，我們想出了如何修改Glitch來解決一系列的問題，而我們現在希望向你分享我們的解決方案。

1. Glitch與Git Repo

Glitch的編輯器非常適合編輯一個小項目，但不適用於構建大型軟體。我們從一開始就知道我們需要在本地機器編輯並將代碼存儲在GitHub repo中。問題是如何將代碼導入Glitch？我們發現，Glitch支持從現有的Git repo中創建一個新項目。這非常棒。

我們現在可以創建一個編輯器，並按照我們喜歡的方式設置項目，在Git中保存，然後在需要時創建一個新的Glitch。我們專門構建了一個名為mred-base-glitch的新repo，並在readme中記錄了具體的步驟。

2. 集成React

MrEd是用React開發，所以接下來的挑戰是如何將React應用程序變成Glitch。在開發期間，我們使用hotreloading dev伺服器在本地運行應用程序。但最終，我們需要可以託管在任何位置的靜態文件。由於我們的應用程序是使用create-react-app進行開發，所以我們可以使用npm run build構建靜態版本。問題是，為了計算最終的URL引用，它要求你在package.json中設置hostname屬性。這不適合我們，因為Glitch可以重命名為任何一切。解決方案是將主機名設置為「.」，這樣所有URL都是相對的。

接下來我們希望隱藏編輯器。在Glitch中，用戶可以編輯器左側發現一個文件列表。儘管顯示asset和腳本沒有什麼問題，但我們希望隱藏生成的React代碼。事實證明，如果它以「.」開頭，Glitch將隱藏任何目錄。因此，在我們的基礎repo中，我們將代碼放到public/.mred。

最後的挑戰是，如何在現有Glitch中更新編輯器，同時不會覆蓋用戶創建的asset和文檔。

我們不是將所有一切都放到同一個git repo中，我們創建了兩個repo：mred只包含在React中構建編輯器的代碼；mred-base-glitch則包含默認文檔和行為。第二個repo將第一個repo集成為git子模塊。編輯器的編譯版本同樣存放在mred repo中。這樣，編輯器的源代碼和編譯版本都可以在git中進行版本控制。

每當你想要在現有Glitch中更新編輯器，你可以轉到Glitch控制台並運行git子模塊init和git子模塊更新。然後，你可以通過刷新Glitch UI進行更新。儘管這是一個手動步驟，但學生們可以通過老師指導輕鬆完成。

3. 載入文檔

編輯器是一個靜態React應用程序，託管在用戶的Glitch中，但它需要在某個位置保存在編輯器中創建的文檔。Glitch沒有提供用於以編程方式載入和保存文檔的API，但任何Glitch都可以安裝NodeJS伺服器，所以我們用express創建了一個簡單的文檔伺服器。doc伺服器掃描文檔和腳本目錄並生成用於編輯器的JSON API。

對於啟動頁面，我們希望用戶在打開編輯器之前查看當前項目的列表。就這一點而言，doc伺服器在「/」位置具有路由，後者返回包含作為鏈接的列表的網頁。對於需要是absolute的URL，伺服器使用Glitch提供的魔術變數來確定主機名：process.env.PROJECT_DOMAIN。

相較於比腳本和文檔，asset有點棘手。編輯器需要一個可用asset列表，但我們不能只掃描asset目錄，因為asset實際上並未存儲在你的Glitch中。相反，它們儲存在Glitch的CDN中。但是，Glitch確實有一個名為.glitch-assets的隱藏文件，它將所有asset列為JSON文檔，包括mime類型。

我們發現學生想要使用諸如如GLB和WAV等不被Glitch識別的文件。你仍然可以將這些文件上傳到CDN，但.glitch-assets文件不會列出正確的mime類型，所以我們的文檔伺服器為它們計算了新的mime類型。

在Glitch中使用一個小型文檔伺服器為我們提供了非常大的靈活性。這絕對是設計方面的勝利。

4. 用戶認證

另一個挑戰是用戶認證。Glitch具有用戶的改變，不允許一名用戶在未經許可的情況下編輯某人的Glitch。但這個用戶系統不作為API公開。我們的代碼無法知道與編輯器交互的人是不是Glitch的所有者。有傳聞稱未來Glitch將提供這樣的功能，但現在我們用密碼文件先行創建了這樣一個功能。

事實證明，Glitch可以擁有一個名為.env的特殊文件，並用於存儲密碼和其他安全環境變數。這個文件可以通過Glitch中運行的代碼讀取，但在再次利用時不會複製，所以如果有人要使用你的Glitch，他們將無法知曉你的密碼。我們要求學生在製作完成後立即設置密碼。然後，doc伺服器將使用密碼驗證與編輯器的通信。

5. 未來功能

我們設法修改Glitch以滿足我們的需求，而我們發現效果不錯。當然，我們希望在以後添加一系列的功能。

官方文檔：我們上面所做的幾乎所有事情都是在支持論壇進行了大量研究後所得出，並得到了Glitch工作人員的幫助。除了基本項目開發之外，官方沒有太多的介紹文檔。如果除常見問題解答之外還有一個官方文檔網站，那就太好了。

真正的身份驗證API：使用.env文件是一個非常棒，但如果編輯器本身可以正確響應用戶則更棒。如果用戶未登錄，則可以顯示體驗的僅播放視圖。如果用戶已登錄但不是Glitch的所有者，它可以顯示Remix按鈕。

一種以編程方式填充asset的方法。當從GitHub克隆時，你在Glitch中看到的所有內容都來自於基礎的git repo，除asset之外。要創建帶有預設asset列表的Glitch，你需要通過可視界面手動上傳文件。沒有其他辦法將asset存儲在git repo中或以編程方式上傳它們。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！