3

conditionnelle Dans mon application mutualisée, j'ai bien des cas, des éléments suivants:Composer une vue HTML avec la logique

<!-- 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 --> 

Ceci est un exemple simplificatrice, mais vous obtenez l'image - de nombreux composants d'une vue plus large sont composés à base sur la logique métier à partir de différents points de données. L'avantage de ceci est que j'ai une vue et l'empreinte de la solution est plus maniable, mais c'est un peu brouillon. Quels modèles alternatifs sont là? Je envisageais de scinder tout ce qui est affiché à condition dans un template html et de rendre html basé sur la logique dans le js viewmodel, mais cela introduit plus de complexité dans mes viewmodels et embrouille mon empreinte de solution (ceci est important pour moi pour une navigation rapide pendant dev).

Je travaille avec durandal et knock-out mais marqué Aurelia parce que je vais migrer un jour et pense qu'il s'agit plus d'une question de modèle que d'une question technologique particulière.

+0

conditions exclusives? –

Répondre

1

Les modèles HTML ont toujours tendance à devenir désordonnés et difficiles à maintenir une fois que votre application commence à grossir.

Je vous suggère de casser votre code HTML en plusieurs composants là-bas par Il sera plus facile à maintenir et le plus important, vous finirez par réutiliser tous ces composants. L'un des plus grands exemples serait JSX qui fonctionne le mieux avec React.js où vous pouvez écrire du HTML dans JS

Ainsi, vous pouvez diviser votre application en composants maintenables. Essayez JSX, cela rend votre vie plus facile en tant que développeur de polices.

+1

Dans Aurelia ce serait facile. La meilleure pratique serait de créer les composants (pour la modularité et la réutilisation), puis d'utiliser la propriété 'if.bind' pour les inclure ou non dans le DOM. – LStarky

3

Motif logique, Concepts Software Design

Vous voulez certainement penser en termes de components, quelle que soit la langue ou le cadre que vous choisissez d'utiliser pour la mise en œuvre.

  1. Diviser votre application dans différents points de vue (peut-être un pour chacun des éléments du menu de navigation).
  2. Subdivisez chacune de ces vues en fonction des types de fonctions qu'elles servent. J'aime la façon dont les panneaux de Bootstrap vous aident à visualiser cela.
  3. Développez chacun de ces composants et donnez leur des noms, tels que ContactList, ContactEdit, ContactView, etc. Développez des vues HTML et JavaScript, TypeScript ou d'autres modèles viewmodels pour chacun de ces composants. Assurez-vous d'utiliser la logique MVC pour séparer vos vues des données, en utilisant des espaces réservés dans la vue pour indiquer où vous allez remplir les données. Les vues sont comme des modèles.
  4. Utilisez votre langue ou cadre spécifique pour relier tous ensemble.

Voici un excellent tutoriel sur Component-Based Software Architecture and Design.

Component Aurelia Logic

J'utilise actuellement Aurelia, et depuis que vous avez mentionné, nous allons utiliser le cadre Aurelia comme exemple pour illustrer les principes ci-dessus.La meilleure pratique consiste à créer les composants (pour la modularité et la réutilisation), puis à utiliser la propriété if.bind pour les inclure ou non dans le DOM.

Exemple:

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

Ou seulement afficher/masquer chaque composant de la vue (mais inclure tous dans les DOM), vous utiliseriez show.bind au lieu de if.bind, mais qui semble faire moins de sens pour votre cas d'utilisation.

Liaison de données Aurelia

Comme je ne sais pas ce que vous espérez réellement afficher ici, le code ci-dessus est basé sur l'extrait de code dans la question. Cependant, pour les vues similaires où seules les données changeront (comme un modèle), vous lierez les données du parent à l'enfant afin qu'elles puissent s'afficher correctement. Dans Aurelia, cela ressemblerait à ceci.

Exemple:

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

Plus Exemple complexe:

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

Dans chacun de ces exemples, vous devez développer 4 fichiers. Vous auriez besoin du conteneur principal (parent) qui a une vue et un viewmodel. Le viewmodel serait chargé de récupérer ou d'accéder aux informations sur le locataire, puis de les transmettre à chacun des composants enfants. Le composant enfant aurait ses propres vues et viewmodel.

Par exemple, la vue TenantView (très simplifiée) pourrait ressembler à ceci:

<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> 

Et puis peut-être comme viewmodel de TenantView (encore une fois, très simplifié) ceci:

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

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

Une fois Si vous avez créé ce composant, vous devez l'insérer (facultativement) dans la vue parente, comme ceci:

<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

C'est bien, mais c'est une solution spécifique à la technologie. J'aimerais résumer ceci en une réponse de type «définition de modèle», car je crois que cela serait plus utile pour les futurs lecteurs. Vous recommandez d'extraire les composants d'affichage dans des fichiers séparés et de laisser la logique d'affichage dans la vue, n'est-ce pas? – SB2055

+0

Mon seul problème avec ceci est que j'ai des centaines d'instances de ceci - où la vue dépend de certaines conditions. Extraire ceux-ci dans des fichiers individuels sera un cauchemar de maintenance. – SB2055

+0

Vos vues doivent contenir la logique appropriée pour s'adapter à la diversité des besoins, sans nécessairement exiger des fichiers de vue différents pour chacun. Vous n'afficheriez que des fichiers de vue différents s'il existe une différence significative de but ou de structure. Je suppose que vous savez déjà comment lier les propriétés parent-enfant. – LStarky