blender視圖縮放

A concept to help Elm Views scale as applications grow larger and more complicated.

當(dāng)應(yīng)用程序變得更大和更復(fù)雜時(shí)，可幫助Elm Views擴(kuò)展的概念。

In Elm, there are a lot of great ways to scale the Model, and update, but there is more controversy around scaling the view. A lot of the debate is around Reusable Views versus Components. Components are not recommended, but a lot of people are still advocating for them. ?This article presents an idea that hopefully strengthens the argument for Resuable Views.

在Elm中，有很多很棒的方法可以縮放Model和進(jìn)行update ，但是圍繞縮放view存在更多爭(zhēng)議。 關(guān)于可重用視圖與組件的爭(zhēng)論很多。 不建議使用組件，但是許多人仍在倡導(dǎo)使用它們。 本文提出了一個(gè)想法，希望能加強(qiáng)對(duì)可恢復(fù)觀點(diǎn)的爭(zhēng)論。

In almost all cases, the scaling problem comes down to enforcing consistency, which usually means allowing child views to make some adjustments to the master view, while at the same time not allowing child views to make a mess.

在幾乎所有情況下，縮放問題都?xì)w結(jié)為強(qiáng)制執(zhí)行一致性，這通常意味著允許子視圖對(duì)主視圖進(jìn)行一些調(diào)整，而同時(shí)不允許子視圖造成混亂。

I will be using Richard Feldman's excellent Real World app (specifically written to demonstrate scaling in Elm) as an example, as it is contains a lot of current best practice techniques, it is well known (2000+ stars and 300+ forks) and Richard is a well known Elm expert.

我將以Richard Feldman出色的“ 真實(shí)世界”應(yīng)用程序 (專門為演示Elm中的縮放比例而編寫)作為示例，因?yàn)樗S多當(dāng)前的最佳實(shí)踐技術(shù)，眾所周知(2000多顆星星和300多顆叉子)和Richard是一位著名的榆木專家。

I will be suggesting some improvements to this code, so I want make a clear at this point that I mean no disrespect by this (I would bet large sums of money that he did it in about one tenth of the time it would have taken me!). You could also argue that the problems are small and not worth fixing. Ultimately, this decision is yours, but by the end of the article I hope to persuade you that there are problems, and that they are fixable if you think it is worthwhile.

我將建議對(duì)此代碼進(jìn)行一些改進(jìn)，因此我想在此說明一下，我的意思是不要無視此事(我敢打賭，他花了大筆錢才花了我將近十分之一的時(shí)間) ！)。 您還可以爭(zhēng)辯說問題很小，不值得解決。 最終，這是您的決定，但是到本文結(jié)尾，我希望說服您存在問題，并且如果您認(rèn)為值得的話，這些問題是可以解決的。

具有條件的主視圖功能 (Master view functions with conditionals)

One option is to define a master view function. This function takes care of shared concerns, like the header bar and overall layout. Then it calls child view functions depending on the current view and / or has parameters to control child specific behaviour.

一種選擇是定義主視圖功能。 此功能可解決共享問題，例如標(biāo)題欄和整體布局。 然后，它根據(jù)當(dāng)前視圖調(diào)用子視圖函數(shù)，并且/或者具有控制子特定行為的參數(shù)。

This works, but can quickly lead to:

這行得通，但可以很快導(dǎo)致：

• An explosion of parameters, potentially forcing your child views to return a lot of things they don't care about.
  參數(shù)的爆炸式增長，可能會(huì)迫使您的孩子視圖返回很多他們不在乎的東西。
• A mixing of responsibilities between master and child views.
  主視圖和子視圖之間的職責(zé)混合。
• Extra code and duplication.
  額外的代碼和重復(fù)。

In the Real World App, a parameter of type Page is passed to the master view so that it can render a navbar link as active. There is a large case statement that uses this parameter to work out what which link is active, and it would be a lot easier for the child just to specify this.

在Real World App中，將Page類型的參數(shù)傳遞到主視圖，以便它可以將導(dǎo)航欄鏈接呈現(xiàn)為活動(dòng)狀態(tài)。 有一個(gè)大寫的語句使用此參數(shù)來確定哪個(gè)鏈接處于活動(dòng)狀態(tài)，對(duì)于孩子來說，僅指定此鏈接會(huì)容易得多。

The line below shows the master view passing Page.Home, which has to match up with Home.view home. This is easy to get wrong, there is no help from the compiler or type system, and really it is the responsibility of the child view the specify this.

下面的行顯示了傳遞Page.Home的主視圖，該視圖必須與Home.view home匹配。 這很容易出錯(cuò)，沒有來自編譯器或類型系統(tǒng)的幫助，這實(shí)際上是指定此子視圖的職責(zé)。

viewPage Page.Home GotHomeMsg (Home.view home)

viewPage Page.Home GotHomeMsg (Home.view home)

There is some duplication when creating the NavBarLink Html, and the linkTo function will accept any Html, although only very particular Html is valid.

創(chuàng)建NavBarLink Html時(shí)會(huì)有一些重復(fù)，并且linkTo函數(shù)將接受任何Html，盡管只有非常特殊的Html有效。

約定與信任 (Convention and trust)

Another possibility is for child views to be responsible for keeping shared elements consistent, by convention and trust.

子視圖的另一種可能性是根據(jù)約定和信任負(fù)責(zé)使共享元素保持一致。

Arguably this also happens in the Real World App. The Home, Article and Profile views all have the concept of a banner. The banner is different in each view, but presumably is meant to be a consistent and recognisable visual element (essentially, it's the title / header for the view). The views don't share any code for these banners, and as a result of this they are not the same size or colour. You could theoretically try and enforce a convention using tests, but it would be difficult, and probably not worthwhile.

可以說，這在真實(shí)世界應(yīng)用程序中也會(huì)發(fā)生。 “ 主頁” ，“ 文章”和“ 個(gè)人資料”視圖均具有橫幅的概念。 橫幅在每個(gè)視圖中都是不同的，但大概是一個(gè)一致且可識(shí)別的視覺元素(實(shí)際上，它是視圖的標(biāo)題/標(biāo)題)。 視圖不共享這些橫幅的任何代碼，因此，它們的大小或顏色都不相同。 從理論上講，您可以嘗試使用測(cè)試來強(qiáng)制執(zhí)行約定，但是這很困難，而且可能不值得。

輔助功能 (Helper functions)

Another possibility is for child views to be responsible for keeping shared elements consistent, but by using some helper functions. This is definitely a step forward, and is probably the most common solution I see in the wild. The functions can go in the same file and be next to each other. This makes it easier to see that they are related and are representing the same visual element, and easier to make them consistent.

子視圖的另一種可能性是負(fù)責(zé)使共享元素保持一致，但是要使用一些輔助函數(shù)。 這絕對(duì)是向前的一步，可能是我在野外看到的最常見的解決方案。 這些功能可以放在同一文件中，并且可以彼此相鄰。 這使得更容易看到它們是相關(guān)的并且代表相同的視覺元素，并且更容易使它們保持一致。

However, there are still some drawbacks. The main one is that the child views have to know to use the helper functions, and there is nothing enforcing this. This isn't a huge deal when you only have one shared element and one function to call, but as applications get bigger, you end up with a combinatorial explosion of differences in the shared visual elements. Most people tame this by providing a number of small, focused functions for the various differences. Then the child view has to know about all these functions, and how to compose them, and there no help from the compiler.

但是，仍然存在一些缺點(diǎn)。 主要的一點(diǎn)是子視圖必須知道如何使用幫助器功能，并且沒有什么強(qiáng)制執(zhí)行此功能。 當(dāng)您只有一個(gè)共享元素和一個(gè)函數(shù)要調(diào)用時(shí)，這并不是什么大問題，但是隨著應(yīng)用程序變得越來越大，您最終將共享視覺元素之間的差異組合起來爆炸。 大多數(shù)人通過為各種差異提供一些小的，集中的功能來馴服這一點(diǎn)。 然后，子視圖必須了解所有這些功能以及如何編寫它們，并且編譯器沒有任何幫助。

Again, this arguably occurs in the Real World App: for example in this part of the Profile.view function, which needs to know how to use the viewTabs, Feed.viewArticles and Feed.viewPagination helper functions, and what Html they need to be contained in.

同樣，這可以說是發(fā)生在Real World App中：例如，在Profile.view函數(shù)的這一部分中 ，它需要知道如何使用viewTabs ， Feed.viewArticles和Feed.viewPagination幫助器函數(shù)，以及它們需要使用的viewTabs Feed.viewArticles包含在。

使用主視圖類型縮放 (Scaling with Master View Types)

In order to overcome these problems, I propose using a Type to define your site structure (I rather pompously call this a "Master View Type"). Child views then return this type, and the master view takes it as a parameter and returns the html.

為了克服這些問題，我建議使用一種Type來定義您的站點(diǎn)結(jié)構(gòu)(我相當(dāng)稱呼它為“主視圖類型”)。 然后，子視圖返回此類型，而主視圖則將其作為參數(shù)并返回html。

For the Real World App examples we have been looking at, the Master View Type is below (Viewer is the person viewing the page in the Real World App). You could arguably have more general banner types here, such as AvatarBanner, or even IconBanner (instead of ViewerBanner) depending on your domain.

對(duì)于我們一直在查看的Real World App示例，下面是Master View Type( Viewer是在Real World App中查看頁面的人)。 可以說，根據(jù)您的域的不同，這里可能有更通用的橫幅類型，例如AvatarBanner或什至IconBanner(而不是ViewerBanner)。

type alias Page ={ activeNavBarLink: NavBarLink, banner: Banner, body: Html Msg}type Banner =TextBanner TextBannerProperties| ViewerBanner Viewer| ArticleBanner Viewer ArticlePreviewtype NavBarLink =NavBarLink NavBarLinkProperties

To demonstrate this, I have create a repository with just the Header and Banner parts of the Real World App and then created a new repository after refactoring to use a ?Master Page Type, NavBarLink Type and Banner Type. You can peruse the code to get a feel for how it works.

為了演示這一點(diǎn)，我創(chuàng)建了一個(gè)僅包含Real World App的Header和Banner部分的存儲(chǔ)庫，然后在重構(gòu)后使用Master Page Type ， NavBarLink Type和Banner Type創(chuàng)建了一個(gè)新的存儲(chǔ)庫。 您可以細(xì)讀代碼以了解其工作原理。

To my mind, using a Master Page Type has the following benefits:

我認(rèn)為，使用母版頁類型具有以下好處：

• Writing the master view code is easier
  編寫主視圖代碼更容易
• Writing the child view code is easier
  編寫子視圖代碼更容易
• Communication and understanding are improved, as UI concepts now have names
  交流和理解得到改善，因?yàn)閁I概念現(xiàn)在有了名稱
• Theming / redesigning a site is a lot easier
  主題化/重新設(shè)計(jì)網(wǎng)站要容易得多
• Elm packages can provide UI templates
  Elm包可以提供UI模板

The master view can precisely define what it will accept / support via the types, with union types and opaque types. Non supported combinations can be made unrepresentable or uncreatable.

主視圖可以通過聯(lián)合類型和不透明類型通過類型精確定義它將接受/支持的內(nèi)容。 不受支持的組合可能無法顯示或無法創(chuàng)建。

In my example repository the NavBarLink type is opaque, so it is only possible to create supported NavBarLinks (home, article and viewer). In a similar way Banner is a union type, which means that only supported variants can be represented.

在我的示例存儲(chǔ)庫中， NavBarLink類型是opaque ，因此只能創(chuàng)建受支持的NavBarLinks( home ， article和viewer )。 以類似的方式Banner是聯(lián)合類型 ，這意味著只能表示受支持的變體。

It would be possible for a programmer to simply change these files, but a proficient programmer would recognise the patterns and follow them. If this isn't enough and you are feeling paranoid, then you can require stricter code review on such files, potentially taking advantage of CODEOWNERS functionality on GitHub and GitLab. In the extreme you can ?provide the modules via an elm package, and restrict push access to the underlying repository.

程序員可以簡(jiǎn)單地更改這些文件，但是精通的程序員會(huì)識(shí)別并遵循這些模式。 如果這還不夠，您會(huì)感到偏執(zhí)，那么您可能需要對(duì)此類文件進(jìn)行更嚴(yán)格的代碼審查，從而有可能利用GitHub和GitLab上的CODEOWNERS功能。 在極端情況下，您可以通過elm包提供模塊，并限制對(duì)基礎(chǔ)存儲(chǔ)庫的推送訪問。

Child views don't have to do anything more than create an instance of the types. The helper functions all return types, so it's easy to see which functions can be used in a particular context, and is impossible to use functions in the wrong context. For example, if a function returns a HeaderBarLink, it is impossible to mistakenly use this function to create a link in the FooterBar, or elsewhere on the page. Child views can also leave some of the complexity to the master view. For example, the child view can define a list of options to choose from, and the master view can render this using buttons, a drop down list or an autocomplete list, depending on the number of options.

子視圖除了創(chuàng)建類型的實(shí)例外，無需執(zhí)行其他任何操作。 輔助函數(shù)將所有返回類型用作函數(shù)，因此很容易看出可以在特定上下文中使用哪些函數(shù)，并且不可能在錯(cuò)誤的上下文中使用函數(shù)。 例如，如果一個(gè)函數(shù)返回HeaderBarLink ，則不可能錯(cuò)誤地使用此函數(shù)在FooterBar或頁面的其他位置創(chuàng)建鏈接。 子視圖也可以將某些復(fù)雜性留給主視圖。 例如，子視圖可以定義一個(gè)選項(xiàng)列表，主視圖可以根據(jù)選項(xiàng)的數(shù)量使用按鈕，下拉列表或自動(dòng)完成列表來呈現(xiàn)。

The master page type also provides names for UI concepts, which can then be discussed. For example, a designer could say "Let's move the NavBarLinks to the left hand side", and everybody would know what they meant. A product owner could say "Let's create a new page with an IconBanner, and we'll use the current weather api for the icon" and again, everybody would know what they mean. You can look at this excellent thoughtworks article for more details of this.

母版頁類型還提供UI概念的名稱，然后可以對(duì)其進(jìn)行討論。 例如，設(shè)計(jì)師可以說“讓NavBarLinks移到左側(cè)”，每個(gè)人都會(huì)知道它們的意思。 產(chǎn)品負(fù)責(zé)人可能會(huì)說：“讓我們用IconBanner創(chuàng)建一個(gè)新頁面，然后我們將使用當(dāng)前的天氣api作為圖標(biāo)”，同樣，每個(gè)人都會(huì)知道它們的含義。 您可以查看這篇出色的Thoughtworks文章，以獲取更多詳細(xì)信息。

Since the responsibility for turning the Master View Type in to html is all in the same place, it is easy to make drastic changes to the look and feel of a website, and to do theming. These changes and themes can alter the Css and the Html, which is something that the normal theming techniques just can't do. Pragmatically, your Master View Type will often have a body: Html Msg property (to allow child views complete flexibility on the child specific parts of the page) so there would still be some sprawling code to fix up, but it will definitely be a lot easier.

由于將“主視圖類型”轉(zhuǎn)換為html的責(zé)任都在同一個(gè)地方，因此很容易對(duì)網(wǎng)站的外觀和風(fēng)格進(jìn)行重大更改并進(jìn)行主題化。 這些更改和主題可能會(huì)更改Css 和Html ，這是常規(guī)主題技術(shù)無法做到的。 實(shí)用上，您的“主視圖類型”通常會(huì)有一個(gè)body: Html Msg屬性(允許子視圖在頁面的子特定部分上具有完全的靈活性)，因此仍然會(huì)有一些龐大的代碼需要修復(fù)，但是肯定會(huì)有很多更輕松。

Finally, it opens up possibility of providing ready made themes and site layouts as packages. This would allow you to just do the following to get a working app, complete with layout and styling:

最后，它提供了將現(xiàn)成的主題和站點(diǎn)布局作為軟件包提供的可能性。 這將使您只需執(zhí)行以下操作即可獲得可運(yùn)行的應(yīng)用程序，包括布局和樣式：

• create-elm-app

  create-elm-app

• elm install elm-bootstrap-starter-template

  elm install elm-bootstrap-starter-template

• Write some code to create the Master Page Type
  編寫一些代碼來創(chuàng)建母版頁類型

• elm-app start

  elm-app start

Companies could create packages like these to ensure a consistent look and feel across their applications. Open source designs and layouts could emerge and become commonplace, similar to the way that Bootstrap has revolutionised html and css design. Developers with limited design skills (like me) could concentrate on the the bits they are best at (the logic), but still produce produce elegant websites using these packages.

公司可以創(chuàng)建這樣的軟件包，以確保整個(gè)應(yīng)用程序的外觀一致。 開源設(shè)計(jì)和布局可能會(huì)出現(xiàn)并變得司空見慣，類似于Bootstrap徹底改變了html和css設(shè)計(jì)的方式。 設(shè)計(jì)技能有限的開發(fā)人員(如我)可以專注于他們最擅長的部分(邏輯上)，但仍可以使用這些軟件包來生成美觀的網(wǎng)站。

To demonstrate this I have created a bootstrap starter master view package. It mimics the layout and design of the bootstrap starter template. I have then used this package in a demo elm application. You can browse the demo application to see how it looks, and view the source to see how it works.

為了演示這一點(diǎn)，我創(chuàng)建了一個(gè)bootstrap starter主視圖包 。 它模仿了引導(dǎo)程序入門模板的布局和設(shè)計(jì)。 然后，我在演示elm應(yīng)用程序中使用了此軟件包。 您可以瀏覽演示應(yīng)用程序以查看其外觀，并查看源代碼以查看其工作方式。

All these advantages come at a small to negative cost. There is a little more code for the new types, but some duplication is removed. You can view the source of the Real World App repositories from before and after refactoring to use a Master Page Type for the full details.

所有這些優(yōu)點(diǎn)付出的代價(jià)很小或?yàn)樨?fù)。 新類型還有更多代碼，但是刪除了一些重復(fù)項(xiàng)。 您可以在重構(gòu) 前后查看“真實(shí)世界”應(yīng)用程序存儲(chǔ)庫的源， 以使用母版頁類型獲取完整的詳細(xì)信息。

結(jié)論 (Conclusions)

Master View Types bring a lot of benefits (view code is easier to write and maintain, UI concepts are named and UI packages are possible) for little or no cost. They should improve the code of any Elm application that has issues around enforcing consistency (while allowing flexibility) in their view code, which in my experience is most medium and large applications.

主視圖類型帶來了很多好處(視圖代碼更易于編寫和維護(hù)，命名UI概念并且可以使用UI包)，而幾乎沒有成本。 他們應(yīng)該改進(jìn)任何Elm應(yīng)用程序的代碼，這些應(yīng)用程序在其視圖代碼中存在圍繞加強(qiáng)一致性(同時(shí)允許靈活性)的問題，據(jù)我的經(jīng)驗(yàn)，這是大多數(shù)中型和大型應(yīng)用程序。

翻譯自: https://www.freecodecamp.org/news/scaling-elm-views-with-master-view-types/

blender視圖縮放

總結(jié)

以上是生活随笔為你收集整理的blender视图缩放_如何使用主视图类型缩放Elm视图的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。