Vaadin 10+作为CUBA UI的未来
從一開始，Vaadin就成為CUBA平臺用戶界面的基石和重要組成部分。 由于其創(chuàng)新的方法，它幫助CUBA將企業(yè)用戶界面開發(fā)帶到了一個非常有希望的（如今是默認）的WEB領(lǐng)域。 Vaadin最令人興奮的部分之一是整個開發(fā)都是同構(gòu)的，并且主要使用Java完成，從而避免了開發(fā)人員與相當不穩(wěn)定且快速變化的前端世界進行交互。
如您所見，Vaadin的重要部分之一是功能豐富的UI（在Vaadin 8的情況下基于GWT小部件）。
與現(xiàn)代Web UI套件相比，即使在今天，Vaadin小部件仍然屬于最復雜和最先進的部件，尤其是在企業(yè)需求方面。 首先，我們談?wù)摰氖窃诘湫偷腃UBA應(yīng)用程序組件中大量使用的組件，例如表，網(wǎng)格，組合框。 例如，只要嘗試找到帶有Table的流行UI工具包，即可提供拖放列重新排序或動態(tài)列控件。
Vaadin的故事
CUBA平臺使用Vaadin的歷史悠久。 該平臺為用戶提供了從Vaadin 5到Vaadin 8的幾乎無縫遷移。為了提供這種遷移，我們必須在Vaadin之上構(gòu)建并保持API。 此外，我們擴展了一些組件，甚至分叉框架本身為我們的客戶提供獨特的功能，并注入所需的擴展點。 在服務(wù)器端，平臺提供數(shù)據(jù)綁定和數(shù)據(jù)感知組件，這是通用UI的最重要功能。
為了加快開發(fā)速度并啟用快速開發(fā)工具（Studio），我們引入了XML描述符-建立數(shù)據(jù)綁定UI的聲明性方法：
<layout> <grid spacing= "true" height= "200" > <columns count= "4" /> <rows> <row flex= "1" > <label value= "Field 1" align= "MIDDLE_LEFT" /> <textField height= "100%" /> <label value= "Field 2" align= "MIDDLE_LEFT" /> <textField height= "100%" /> </row> <row flex= "2" > <label value= "Field 3" align= "MIDDLE_LEFT" /> <textField height= "100%" /> </row> </rows> </grid> </layout>Pure Vaadin:
GridLayout tableHeader = new GridLayout( 3 , 2 ); ????Label nameLabel = new Label( "Field 1" ); nameLabel.setWidth(lastnameWidth + 2 * 6 , Unit.PIXELS); tableHeader.addComponent(nameLabel, 0 , 0 , 0 , 1 ); Label countryLabel = new Label( "Field 2" ); countryLabel.setWidth(countryWidth + 2 * 6 , Unit.PIXELS); tableHeader.addComponent( new Label( "Field 3" ), 1 , 0 ); Label bornLabel = new Label( "Field 4" ); bornLabel.setWidth(bornWidth + 2 * 6 , Unit.PIXELS); tableHeader.addComponent(bornLabel, 2 , 0 , 2 , 1 ); tableHeader.addComponent(countryFilterBox, 1 , 1 ); ????// Put the header and table inside a vertical layout layout.addComponent(tableHeader); layout.addComponent(table); ????// Adjust the table height a bit table.setPageLength(table.size());我們設(shè)法建立了自己的組件列表（基于Vaadin原語）：
- 組表
- 表格（以前是FieldGroup）
- PickerField
- LookupPickerField
- 令牌表
- MaskedField
- 建議字段
- 貨幣字段
話雖這么說，CUBA在Vaadin框架之上提供了很多功能，以使開發(fā)人員的生活更輕松，并使開發(fā)達到更高的水平。 CUBA團隊進行了繁重的工作，以在更新基礎(chǔ)的Vaadin框架時實現(xiàn)非常平滑，字面上看不見的遷移。
新挑戰(zhàn)
定制和本地交互
GWT非常復雜，并且創(chuàng)建UI小部件是一個充滿挑戰(zhàn)且耗時的過程。 經(jīng)驗豐富的開發(fā)人員肯定知道在通過本機平臺進行人工抽象時，您必須付出高昂的代價。 對于GWT，我們必須與Java世界中的瀏覽器JS API進行交互。
響應(yīng)式布局
即使對于企業(yè)界面，針對不同屏幕尺寸的可調(diào)能力也已成為關(guān)鍵要求。 僅由于上述在本機平臺上的額外抽象性，使響應(yīng)式UI很難。 盡管您可以使用CssLayout或特殊的加載項來創(chuàng)建響應(yīng)式UI，但是服務(wù)器端的標準布局和計算在這種情況下不能很好地發(fā)揮作用。
使用第三方庫
Web的發(fā)展非常Swift，有大量的Web軟件包（npm> 1M）在Vaadin 8應(yīng)用程序中幾乎沒有用，因為它不使用現(xiàn)代的前端工具和構(gòu)建系統(tǒng)。
GWT開發(fā)陷入困境
在某個時候，谷歌停止了GWT的積極開發(fā)。 這不僅與官方支持有關(guān)，而且與生態(tài)系統(tǒng)有關(guān)。
Vaadin流
為了對前端生態(tài)系統(tǒng)更加開放，Vaadin開始開發(fā)Vaadin框架的后繼產(chǎn)品。 新方法的核心是Vaadin Flow ，該技術(shù)可為基于Web組件而不是GWT小部件的新UI層提供服務(wù)器端模型和基本數(shù)據(jù)綁定。
考慮下圖：
如您所見，Vaadin已將基于GWT的客戶端替換為基于本機Web技術(shù)的新客戶端。
Vaadin成分
新的Vaadin 組件是Vaadin GWT小部件的后繼產(chǎn)品。 它們是使用純Web技術(shù)（HTML，JavaScript）和Polymer 2庫從頭開始構(gòu)建的Web組件。
Web組件
最初，Web組件是在大多數(shù)現(xiàn)代瀏覽器中實現(xiàn)的一組標準：
- 自定義元素
- 影子大教堂
- HTML模板
- HTML導入-> ES模塊
長期以來，Web組件非常有前途，許多人（包括我在內(nèi)）都將其視為React和Angular等框架的本地替代品，這些框架也利用基于組件的方法。 但是隨著時間的流逝，這些標準中的一些已被瀏覽器丟棄，而另一些則需要進行重大改進，這一點變得顯而易見。 如今，從上面的列表中，只有自定義元素和Shadow DOM仍用于Web應(yīng)用程序開發(fā)中。 甚至從Chrome刪除了HTML導入。 如今HTML模板看起來已經(jīng)過時了，例如，新的Polymer方法： lit-html僅在幕后使用它們。
我們還嘗試使用Web組件，這是我們嘗試在Polymer庫之上構(gòu)建以客戶端為中心的UI的一部分。 在某個時候，我們決定將工作轉(zhuǎn)向基于React的方法，因為Polymer盡管具有Web Component支持解決方案的勇敢使命，但開發(fā)人員的經(jīng)驗很差，生態(tài)系統(tǒng)很小（即使已經(jīng)存在了幾年），最后還是不清楚not recommended在新項目解決方案發(fā)布之時發(fā)布Polymer 3。 聚合物用戶不得不等了將近一年，直到lit-html和LitElement最終發(fā)布。
從我們的經(jīng)驗中得出的另一個觀察結(jié)果：盡管受到use the Platform座右銘的擁護者的大力推動，但是在開發(fā)現(xiàn)代前端應(yīng)用程序時，仍然幾乎不可能擺脫轉(zhuǎn)譯/捆綁的步驟。 盡管標準正在為所有瀏覽器采用困難的方法和解決API帶來困難，但社區(qū)創(chuàng)建了許多工具和庫來解決相同的問題。
例如，Shadow DOM的主要目的是封裝CSS樣式，以免溢出到組件的本地DOM或從組件的本地DOM溢出。 這個想法很棒，但是大多數(shù)瀏覽器都花了幾年的時間（幸好Edge遷移到了Chromium）。 同時，React生態(tài)系統(tǒng)由大量樣式庫實現(xiàn)，這些樣式庫可以解決相同的任務(wù)，甚至可以解決更多問題 ，而不會產(chǎn)生Shadow DOM的重大 陷阱 。
但是，Web組件具有非常重要的獨特功能：它們是平臺（瀏覽器）的一部分。 從理論上講，它們不受任何特定框架的約束，是通用的，可以在任何地方使用。 從這個角度來看，這似乎是UI Kit或獨立組件（而不是應(yīng)用程序）的合理選擇，不僅由Vaadin做出，而且例如由Ionic和SAP做出。
瓦丹14
基于Vaadin Flow的Vaadin 10已于2018年中期發(fā)布 。很快就很明顯，UI套件缺少許多重要組件，只包含基本組件。 此外，客戶端構(gòu)建管道還包括一個Bower依賴管理器–該工具已于2017年棄用，并且不與事實上的標準npm生態(tài)系統(tǒng)相交。
因此，我們將Vaadin 10發(fā)布視為試驗性的，并決定等到新技術(shù)變得更穩(wěn)定為止。 在Vaadin 14 LTS 于 2019年8月到來之前，共有3個主要版本，其中包括對npm的高度支持和更強大的UI套件。 這敦促我們仔細觀察并親身體驗Vaadin 14。
UI套件
即使沒有深入研究代碼庫，很明顯，與Vaadin 8小部件相比，許多屬性和行為也發(fā)生了變化。 通常，這還不錯，但是對于CUBA，這意味著在某些方面，不會直接替換當前支持的功能/ API。
在完整性方面，仍然有一些缺少的核心組件已在CUBA中使用：
- 日歷
- 樹
- 雙柱
某些以前免費的組件和功能成為Pro組件的一部分：例如，RichTextArea現(xiàn)在是Pro組件的一部分，Vaadin Grid Pro中提供了Grid的編輯模式。
PickerField
作為評估過程的一部分，我們?yōu)閂aadin 14重新實現(xiàn)了CUBA的PickerField組件：
說到服務(wù)器端，Vaadin Flow提供了驚人的功能，可以使用Java API與客戶端（DOM元素，事件等）進行交互。 Vaadin組件隨附了便捷的Java API：
Accordion accordion = new Accordion(); ... accordion.open( 1 );非Vaadin組件沒有此類API，但是您仍然可以通過DOM API對任何元素使用通用方法：
例子1
if (value == null ) { getElement().removeProperty( "value" ); } else { getElement().setProperty( "value" , getStringRepresentation(value)); }例子2
getElement().appendChild( new Element[]{Element.createText(text)});盡管服務(wù)器端非常漂亮和清晰，但客戶端卻花了我們90％的精力。 我們首先要提到的是，核心Vaadin組件當前是由Polymer 2構(gòu)建的。為了支持Vaadin 14+的Polymer 3，它們似乎已自動轉(zhuǎn)換。 通常，Polymer 2和Polymer 3具有相同的API（這就是為什么可以進行自動轉(zhuǎn)換的原因），但是，導入和樣式聲明之間存在細微的差異。
另一個棘手的話題是樣式和自定義：由于Shadow DOM，您根本無法將樣式應(yīng)用于隨機元素（僅適用于設(shè)計為可通過使用自定義CSS屬性進行樣式設(shè)置的元素）。 Vaadin組件具有用于自定義的插槽（Shadow DOM的另一個強大但復雜的部分）。 它們非常適合簡單的用例，但是在嘗試實現(xiàn)更高級的用例時，您很快就會遇到限制。
因此，在實現(xiàn)PickerField時，我們將通過復制粘貼樣式和Vaadin組件的其他部分結(jié)束，并在本機input元素之上構(gòu)建該組件（從@vaadin導入的唯一可重用的東西是幾個Mixins）。
我們不怪Vaadin，因為Vaadin尚未設(shè)計（也不應(yīng)該）作為另一個UI套件的基礎(chǔ)，它只是表明對我們來說，支持所有附加功能在客戶端將是大量工作我們?yōu)殚_發(fā)人員提供了很長一段時間。 當前應(yīng)該以Polymer 3為基礎(chǔ)的作品（已經(jīng)處于維護模式），所有已知的開發(fā)人員都遇到Polymer2的缺陷。
最新消息
就在撰寫本文時，Vaadin宣布所有核心組件都將在TypeScript和LitElement上進行重寫。 我們對這一決定持積極態(tài)度，因為我們在TypeScript方面的豐富經(jīng)驗證實，它可以避免JS中缺少靜態(tài)類型所引起的大量錯誤，有助于理解代碼庫的結(jié)構(gòu)，執(zhí)行安全的重構(gòu)等。
不過，LitElement / lit-html看起來有點令人懷疑：我們理解這一選擇，因為它是Polymer的后繼者，并利用了React發(fā)明的強大的聲明式渲染（view = f（state））方法。 但是它仍然是：
- 很新 。
- 具有運行時（與Stencil和Svetle之類的已編譯方法不同）。 為了同時支持基于聚合物和基于Lit的組件，Vaadin應(yīng)將兩個庫都交付給客戶端。
- IDE支持差。 有一些VS Code插件，但是IntelliJ / WebStorm中不提供支持 ，這使得點亮的模板看起來非常混亂。
- 不是SSR –友好。
出現(xiàn)了許多新問題：
LitElement + TypeScript是否將取代當前基于Polymer 3的方法來開發(fā)應(yīng)用程序前端？
如果是，那么類似React的渲染將如何與服務(wù)器端Java API一起工作？
更新資料
Vaadin 15附帶了客戶端引導程序和TypeScript 支持 。
結(jié)論
Vaadin是一種獨特的產(chǎn)品，可為Java提供便利的Web開發(fā)。 Vaadin Flow帶來了全新的客戶端方法，我們認為這是很有前途的。 但是，組件集仍在不斷發(fā)展，并正在走向穩(wěn)定。
我們可以肯定地說一件事：由于全新的客戶端，我們將無法為從Vaadin Flow之上構(gòu)建的新UI提供平滑的遷移路徑。
同樣，我們認為在客戶端技術(shù)上開始在其之上進行所有CUBA組件的大規(guī)模遷移仍然有些模糊和不穩(wěn)定。 我們決定將積極的開發(fā)推遲到新的Web組件集可用之前。 我們?nèi)詴芮嘘P(guān)注Vaadin的發(fā)展，并準備在其變得更加穩(wěn)定后對其進行重新評估。
同時，我們還試圖提供一種替代的，友好的，客戶端友好的方法來創(chuàng)建UI：請參閱我們最近關(guān)于TypeScript SDK和React Client的博客文章。
翻譯自: https://www.javacodegeeks.com/2020/01/vaadin-10-as-the-future-of-cuba-ui.html
總結(jié)
以上是生活随笔為你收集整理的Vaadin 10+作为CUBA UI的未来的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Apache Camel 3只有2个月的
- 下一篇： 灰玛瑙的功效与作用 灰玛瑙的功效与作用有