針對 AEM 開發 SPA developing-spas-for-aem
單頁應用程式 (SPA) 可為網站使用者提供引人入勝的體驗。開發人員希望能使用SPA架構建立網站，而作者則想在Adobe Experience Manager (AEM)中為使用這類架構建立的網站順暢地編輯內容。
本文介紹當請前端開發人員為AEM開發SPA時應考慮的重要問題，並概述有關在AEM上部署SPA的AEM架構。
AEM的SPA開發原則 spa-development-principles-for-aem
在 AEM 開發單頁應用程式是假設前端開發人員在建立 SPA 時有遵守標準最佳做法。如果您身為前端開發人員，遵循這些一般最佳實務和一些AEM特定原則，您的SPA將可搭配AEM及其內容製作功能運作。
- 可攜性 -與任何元件一樣，元件應該儘可能建置為可攜式。 SPA 應該使用可攜帶和可重複使用的元件建置。
- AEM 促成網站結構 - 前端開發人員建立元件並擁有其內部結構，但依賴 AEM 來定義網站的內容結構。
- 動態呈現 - 所有呈現都應該是動態的。
- 動態路由 - SPA負責路由，而AEM會監聽路由並根據路由進行擷取。 任何路由也應該是動態的。
如果您在開發SPA時牢記這些原則，在啟用所有支援的AEM編寫功能時，SPA將會儘可能靈活且符合未來需求。
如果您不需要支援AEM編寫功能，您可能需要考慮其他SPA設計模型。
可攜性 portability
如同開發任何元件一樣，元件的設計應儘可能提高可攜性。 應避免任何影響元件可攜性或重複使用的模式，以確保日後相容性、彈性和可維護性。
產生的SPA應建置具備高度可攜性及可重複使用的元件。
AEM磁碟機網站結構 aem-drives-site-structure
前端開發人員必須自行負責建立用於建置應用程式的SPA元件資料庫。 前端開發人員可完全控制元件的內部結構。 但是，AEM在任何時候都擁有網站結構。
這表示前端開發人員可在元件進入點之前或之後新增客戶內容，且也可以在元件內進行第三方呼叫。 但是，前端開發人員無法完全控制元件的巢狀內嵌方式，例如，
動態演算 dynamic-rendering
SPA應該僅依賴內容的動態轉譯。 這是AEM擷取並轉譯內容結構之所有子項的預設預期。
任何指向特定內容的明確呈現都會視為靜態呈現，雖然支援此功能，但不會與AEM的內容製作功能相容。 這也不符合可攜性的原則。
動態路由 dynamic-routing
如同轉譯一樣，所有路由也應是動態的。 在AEM中，SPA應一律擁有路由，而AEM會監聽路由並根據路由擷取內容。
任何靜態路由都違反可攜性原則，而且會限製作者，因為與AEM的內容製作功能不相容。 例如，使用靜態路由，如果內容作者想要變更路由或變更頁面，作者必須要求前端開發人員這麼做。
AEM 專案原型 aem-project-archetype
任何 AEM 專案都應使用 AEM 專案原型，它支援使用 React 或 Angular 的 SPA 專案並使用 SPA SDK。
SPA設計模型 spa-design-models
如果遵循AEM中開發SPA的原則，則您的SPA將可搭配所有支援的AEM內容製作功能運作。
不過，在某些情況下，這並非完全必要。 下表概述各種設計模型、其優點和缺點。
將現有SPA移轉至AEM migrating-existing-spas-to-aem
一般而言，如果您的SPA遵循AEM的SPA開發原則，則您的SPA將在AEM中運作並可使用AEM SPA Editor進行編輯。
請依照下列步驟，讓現有的SPA準備好搭配AEM使用。
-
將您的JS元件模組化。
使其能夠以任何順序、位置和大小呈現。
-
使用Adobe SDK提供的容器，將您的元件放在熒幕上。
AEM提供頁面和段落系統元件供您使用。
-
為每個JS元件建立AEM元件。
AEM元件會定義對話方塊和JSON輸出。
面向前端開發人員的說明 instructions-for-front-end-developers
讓前端開發人員為AEM建立SPA的主要工作是就元件及其JSON模型達成共識。
以下概述前端開發人員在為AEM開發SPA時需要遵循的步驟。
-
同意元件及其JSON模型
前端開發人員和後端AEM開發人員需要就哪些元件是必要元件和模型達成共識，以便SPA元件與後端元件進行一對一比對。
AEM元件仍然主要用於提供編輯對話方塊和匯出元件模型。
-
在React元件中，透過
this.props.cqModel存取模型在同意元件且JSON模型就緒後，前端開發人員即可自由開發SPA，並可透過
this.props.cqModel存取JSON模型。 -
實作元件的
render()方法前端開發人員實作
render()方法，因為他們認為適合，並且可以使用cqModel屬性的欄位。 這會輸出插入頁面中的DOM和HTML片段。 這是在React中建立應用程式的標準方式。 -
透過
MapTo()將元件對應至AEM資源型別對應會儲存元件類別，並由提供的
Container元件在內部使用，以根據指定的資源型別擷取及動態例項化元件。這相當於前端和後端之間的「粘合」，因此編輯器可以知道哪些元件與react元件相對應。
Page和ResponsiveGrid是延伸基底Container的類別範例。 -
將元件的
EditConfig定義為引數MapTo()只要尚未轉譯或沒有可轉譯的內容，此引數是告訴編輯器元件應如何命名所必需的。
-
為頁面和容器擴充提供的
Container類別頁面和段落系統應該擴充此類別，好讓委派給內部元件的功能可如預期運作。
-
使用HTML5
HistoryAPI實作路由解決方案。當
ModelRouter啟用時，呼叫pushState和replaceState函式會觸發向PageModelManager發出的要求，以擷取缺少的模型片段。目前版本的
ModelRouter僅支援使用指向Sling模型進入點實際資源路徑的URL。 不支援使用虛名URL或別名。可以停用
ModelRouter，或將其設定為忽略規則運算式清單。
與AEM無關 aem-agnostic
這些程式碼區塊說明您的React和Angular元件如何不需要任何特定於Adobe或AEM的內容。
- JavaScript元件內的所有內容都與AEM無關。
- 不過，AEM的專屬之處在於，JS元件必須使用MapTo協助程式對應至AEM元件。
MapTo協助程式是可讓後端和前端元件配對的「粘合劑」：
- 它會告訴JS容器（或JS段落系統）哪個JS元件負責轉譯JSON中存在的每個元件。
- 它會將HTML資料屬性新增至JS元件轉譯的HTML，這樣SPA編輯器就知道在編輯元件時要向作者顯示的對話方塊。
如需有關使用MapTo和一般為AEM建立SPA的詳細資訊，請參閱所選架構的快速入門手冊。
AEM架構與SPA aem-architecture-and-spas
使用SPA時，AEM的一般架構（包括開發、製作和發佈環境）不會變更。 不過，瞭解SPA開發如何適應此架構會很有幫助。
-
組建環境
這是出庫SPA應用程式來源和元件來源的所在位置。
- NPM clientlib產生器會從SPA專案建立使用者端程式庫。
- 該程式庫由Maven取得，並由Maven Build外掛程式與元件部署到AEM Author。
-
AEM作者
內容是在AEM作者上建立，包括編寫SPA。
在製作環境中使用SPA編輯器編輯SPA時：
- SPA會要求外部HTML。
- CSS已載入。
- 已載入SPA應用程式的JavaScript。
- 執行SPA應用程式時會要求JSON，允許應用程式建置包含
cq-data屬性的頁面DOM。 - 此
cq-data屬性可讓編輯器載入其他頁面資訊，以便知道元件有哪些可用的編輯設定。
-
AEM發佈
這是發佈編寫的內容和編譯的程式庫（包括SPA應用程式成品、clientlibs和元件）以供公眾使用的位置。
-
Dispatcher / CDN
Dispatcher可作為AEM的快取階層，以供網站的訪客使用。
- 要求的處理方式類似於AEM作者上的要求，不過不會要求頁面資訊，因為只有編輯器才需要這樣做。
- 快取JavaScript、CSS、JSON和HTML，最佳化頁面以快速傳送。
後續步驟 next-steps
如需AEM中簡單SPA如何建構及其運作方式的概觀，請參閱React和Angular的快速入門手冊。
如需建立您自己的SPA的逐步指南，請參閱AEM SPA Editor快速入門 — WKND事件教學課程。
如需有關動態模型到元件對應及其在AEM中SPA內運作方式的詳細資訊，請參閱文章SPA的動態模型到元件對應。
如果您想在AEM中為React或Angular以外的框架實作SPA，或只是想深入瞭解適用於AEM的SPA SDK的運作方式，請參閱SPA Blueprint文章。