Required Properties（必備屬性）

有時，您的組件需要設置一些屬性，但沒有合適的默認值。例如，您可能關心按鈕的易訪問性（Accessibility），因此當您創建了一個AccessibleButton控件，它至少應該有一個description屬性。

但是，按鈕具有description屬性這一事實并不意味著任何人都會設置它。所以您或您的同事可能會在某個時候用以下代碼實例化組件：

關于易訪問性就講到這里：現在description屬性只是一個空字符串！當然，您可以為屬性設置一個默認值，但是用哪個呢？“Button”基本沒用。"您不應該聽到這個"？好吧，至少QA現在可能會針對它。但是，如果QML引擎知道需要設置此屬性，不是更有用嗎?

不幸的是，在Qt 5.15之前沒有辦法強制設置description屬性。但從Qt 5.15開始，這就成為可能:

現在，如果創建一個AccessibleButton，但沒有設置description屬性，那么整個應用程序將無法啟動。但如果該組件是動態創建的(例如通過Loader加載)，則無法做到這一點。這種情況下，將僅出現運行時警告。

我們還計劃為qmllint和QtCreator添加更多的工具支持，以便在未設置Required Properties時顯示警告。

Required Properties和Delegates

此外，Required Properties在Delegates中扮演著特殊的角色。正如您可能知道的，Delegates可以通過名稱以及其他屬性，如model和index，直接訪問所提供的模型角色。

如果您的Delegates不包含Required Properties，則此處不會發生任何更改。但是，如果它們包含至少一個Required Properties，那么這些名稱就不能再訪問了。相反，您必須將它們顯式的指定為Required Properties。

然后QML引擎將相應設置Required Properties。請注意，如您的model是可編輯的，新方法和舊方法之間有一個重要的區別：使用舊方法，您可以這樣寫代碼：

model也會相應更新。但如果你這樣寫代碼

然后，description的綁定將被破壞(QML引擎將會打印警告)，model將不會被更新。我們決定采用這種行為，以確保無論在delegates中或在delegates之外使用，components的行為不會有太大的差異。此外，我們也不鼓勵任何人對屬性執行命令式賦值(因為這通常會破壞綁定)。

如果您確實想要更新model的值，當然還有一種辦法可以實現：將model設置為Required Properties并用以下代碼

我們建議您始終在Delegates中使用Required Properties。這避免了非限定查找，后者對工具來說是個問題，并往往會降低處理速度。

Inline Components（內聯組件）

Qt 5.15中的另一個新特性是內聯組件。顧名思義，它們允許您在文件中定義一個新組件。基本語法是

在文件內部，您可以通過名稱引用新組件，就像在其自己的文件中定義的一樣。讓我們以LabeledImage組件為例來說明其工作原理:

您也可以在其它文件中引用該組件。在這種情況下，您需要在其名字之前加上包含其組件的名稱:

您可能會想，既然QML已經有了組件類型，為什么還要使用內聯組件呢？查看前面的示例，我們可以看到，內聯組件使您可以執行組件無法執行的以下操作:

您可以在沒有Loader開銷的情況下創建組件實例。

您可以在屬性聲明中使用組件類型。

您可以在定義組件的文件之外的其他文件中引用該組件。

希望您能和我們一樣方便地找到內聯組件!

Nullish Coalescing（空值合并）

最后一個新語言特性是由我們的實習生Maximilian Goldstein實現的。雖然QML通常只支持EcmaScript 6，但是Maximilian為一個即將提出的語言特性增加了支持，該特性正在被添加到最新的EcmaScript標準中：空值合并。引用MDN:

空值合并操作符(??)是一個邏輯操作符，當其左側操作數為空或未定義時，返回其右側操作數，否則返回其左側操作數。

有關詳細信息，請參閱MDN頁面。下面是一個示例，演示如何在QML中使用它來設置JSON中的屬性，并在未提供屬性的情況下提供合理的默認值。

注意我們在設置brightness時不能用“||”代替“??”。因為settings.brightness可能已經是0，在這種情況下，我們將獲取默認值。