3

В моем Многоквартирный приложение, у меня есть много примеров следующее:слагающих вид HTML с условной логикой

<!-- ko if: tenantA() --> 
<div>Tenant One snippet</div> 
<!-- /ko --> 
<!-- ko if: tenantB() --> 
<div>Tenant Two snippet</div> 
<!-- /ko --> 
<!-- ko if: userTypeA() --> 
<div>User type A snippet</div> 
<!-- /ko --> 
<!-- ko if: userTypeB() --> 
<div>User type B snippet</div> 
<!-- /ko --> 

Это упрощенно пример, но вы получите картину - многие компоненты увеличить составлены на основе по бизнес-логике из разных точек данных.

Преимущество этого в том, что у меня есть один вид, а область действия решения более управляема, но это немного грязно. Какие альтернативные образцы существуют?

Я рассматривал возможность расщепления всего и всего, что отображается при условии, в html-шаблон и рендеринг html на основе логики в модели js viewmodel, но это вводит большую сложность в мои модели просмотра и путает мой размер решения (это важно для меня для быстрой навигации во время dev).

Я работаю с durandal и нокаутом, но отмечен Aurelia, потому что когда-нибудь буду мигрировать и думаю, что это скорее вопрос шаблона, чем конкретный технологический вопрос.

+0

Есть ли c исключительные исключения? –

ответ

1

HTML-шаблоны всегда имеют тенденцию становиться грязными и трудными в обслуживании, когда ваше приложение начинает расти.

Я предлагаю вам разбить свой HTML на несколько компонентов там. Это будет проще в обслуживании, и самое главное, вы в конечном итоге повторно используете все эти компоненты.

Одним из величайших примеров будет JSX, который лучше всего работает с React.js, где вы можете писать HTML внутри JS. поэтому вы можете разделить приложение на поддерживаемые компоненты. дать JSX попробовать, это действительно облегчает вашу жизнь, как разработчик шрифтов.

+1

В Aurelia было бы легко. Лучшей практикой было бы создание компонентов (для модульности и повторного использования), а затем использование свойства 'if.bind' для их включения или отсутствия в DOM. – LStarky

3

логический шаблон, Программное обеспечение Дизайн Концепции

Вы определенно хотите, чтобы думать в терминах components, независимо от того, на каком языке или рамки вы хотите использовать для реализации.

  1. Разделите приложение на разные виды (возможно, по одному для каждого элемента меню навигации).
  2. Подразделение каждого из этих видов дальше (по мере необходимости) в зависимости от того, какие функции они обслуживают. Мне нравится, как панели Bootstrap помогают вам визуализировать это.
  3. Разработайте каждый из этих компонентов и дайте им имена, такие как ContactList, ContactEdit, ContactView и т. Д. Разработайте HTML-представления и JavaScript-модели с использованием TypeScript или других языков для каждого из этих компонентов. Обязательно используйте логику MVC, чтобы отделить ваши представления от данных, используя заполнители в представлении, чтобы указать, где вы будете заполнять данные. Представления похожи на шаблоны.
  4. Используйте свой собственный язык или фреймворк, чтобы связать все это вместе.

Вот отличный учебник по Component-Based Software Architecture and Design.

Aurelia Компонент Logic

настоящее время я использую Аурелий, и так как вы упомянули, мы будем использовать рамки Aurelia в качестве примера для иллюстрации вышеуказанных принципов.Лучшей практикой было бы создание компонентов (для модульности и повторного использования), а затем использовать свойство if.bind для их включения или отсутствия в DOM.

Пример:

<tenant-one if.bind="tenantA"></tenant-one> 
<tenant-two if.bind="tenantB"></tenant-two> 

Или только показать/скрыть каждый компонент из представления (но включают все в DOM), вы бы использовать show.bind вместо if.bind, но это, кажется, имеет меньше смысла для вашего использование случай.

Aurelia Связывание данных

Поскольку я не знаю, что вы на самом деле надеюсь показать здесь, приведенный выше код основан на фрагменте кода в вопросе. Однако для похожих представлений, где будут изменяться только данные (например, шаблон), вы привязываете данные от родителя к ребенку, чтобы он мог отображаться правильно. В Aurelia это будет выглядеть так.

Пример:

<tenant-view data.bind="tenantData"></tenant-view> 

Более сложный пример:

<tenant-view fname.bind="firstName" lname.bind="lastName" data.bind="tenantData"></tenant-view> 

В каждом из этих примеров, вам нужно будет разработать 4 файлов. Вам понадобится основной (родительский) контейнер, у которого есть представление и viewmodel. Модель просмотра будет отвечать за получение или доступ к информации арендатора, а затем передачу ее каждому из дочерних компонентов. Детский компонент будет иметь свою собственную точку зрения и viewmodel.

Например, вид TenantView (сильно упрощены) может быть таким:

<template> 
    <p><strong>Tenant Name: </strong>${fname} ${lname}</p> 
    <p><strong>Additional Data: </strong>${data}</p> 
    <p if.bind="data.rentDue">Tenant's rent is due!</p> 
</template> 

И тогда TenantView ViewModel (опять же, весьма упрощенным) может быть таким:

import { bindable, bindingMode } from 'aurelia-framework'; 

export class TenantView { 
    @bindable fname; 
    @bindable lname; 
    @bindable data; 
} 

Once у вас есть этот компонент, вы должны вставить его (необязательно) в родительский вид, например:

<template> 
    <h1>Contact View</h1> 
    <h2>${firstName} ${lastName}</h2> 

    <tenant-view if.bind="cat == 'tenant'" fname.bind="firstName" lname.bind="lastName" data.bind="contactData"></tenant-view> 

    <phone-numbers data.bind="contactData"></phone-numbers> <!-- another component --> 

    <page-footer></page-footer> <!-- another component --> 

</template> 
+0

Это хорошо, но это технологическое решение. Я бы хотел отвлечь это на тип ответа типа «шаблон», поскольку, по моему мнению, это будет более ценно для будущих читателей. Вы рекомендуете извлечь компоненты просмотра в отдельные файлы, а затем оставить логику представления в представлении, правильно? – SB2055

+0

Моя единственная проблема с этим в том, что у меня есть сотни примеров этого - где представление зависит от некоторого состояния. Извлечение их в отдельные файлы будет кошмаром для обслуживания. – SB2055

+0

Ваши взгляды должны содержать соответствующую логику для адаптации к разнообразию потребностей, не требуя при этом разных файлов вида для каждого из них. Вы будете отображать только разные файлы вида, если есть значительная разница в цели или структуре. Я предполагаю, что вы уже знаете, как связать свойства parent-child. – LStarky