2014-09-05 10 views
5

Attualmente sto lavorando a un'applicazione web Meteor a lungo termine. Dove nel tempo gli sviluppatori verranno e andranno. Pertanto, per garantire che l'intera applicazione mantenga lo stesso aspetto e aspetto mi piacerebbe essere in grado di creare componenti standard con il sistema di modelli meteorici. Quindi i modelli di funzionalità non dovrebbero contenere alcun codice HTML di questo tipo dovrebbe essere contenuto nei modelli di componenti.Schema per la creazione di componenti riutilizzabili

Ho provato meteor-polymer ma si blocca solo la mia applicazione e sembra che dovrei usare il sistema di meteorologia invece di aggiungere un'altra libreria. Anche polimero dipende in larga misura il tag modello che Meteor dipende anche, quindi non sono del tutto sicuro

Fondamentalmente quello che voglio fare nei miei modelli è questo:

<template name="someRandomFeature"> 
    {{#_RadioGroup name="dataInput" context=. formData=formData}} 
     {{#_setLabel}}Test set{{/_setLabel}} 
     {{#_addRow}} 
      {{assignValues value="random"}} 
      {{#_setCaption}}Random{/_setCaption}} 
     {{/_addRow}} 
     {{#_addRow}} 
      {{assignValues value="expression"}} 
      {{#_setCaption}}Expression: {{_TextInput name="testSetExpression" inline=true}}{{/_setCaption}} 
     {{/_addRow}} 
    {{/_RadioGroup}} 

    {{#_FormGroup}} 
     {{#_Config}} 
      {{assignValues numRows=2}} 
     {{/_Config}} 

     {{#_setRow 0}} 
      {{#_SetLabel}}Number of tests{{/_SetLabel}} 
      {{#_setStageContent}} 
       {{> _DropDown name="numberOfTests" items=numberOfTestsList formData=formData}} 
      {{/_setStageContent}} 
     {{/_setRow}} 

     {{#_setRow 1}} 
      {{#_SetLabel}}To email address{{/_SetLabel}} 
      {{#_setStageContent}} 
       {{> _TextInput name='respondentSelection' formData=formData}} 
       <span class="help-block text-left">Send all test mails to this email adress</span> 
      {{/_setStageContent}} 
     {{/_setRow}} 
    {{/_FormGroup}} 
</template> 

Esempio di un componente:

<template name="_FormGroup"> 
{{#with numRows=0 context=. formdata=formdata stage='config'}} 
    {{#with execBlock UI.contentBlock}} 
     <div class="form-group"> 
      {{#each getRows}} 
       {{#unless ../disableLabels}} 
        <label class="control-label"> 
         {{#with _constructStageList 1='rows' 2=_id 3='label'}} 
          {{> UI.contentBlock stage=this stageContext=../../context}} 
         {{/with}} 
        </label> 
       {{/unless}} 

       <div class="row{{#unless ../disableLabels}} controls{{/unless}}"> 
        <div class="{{#if ../fullWidth}}col-md-16{{else}}col-md-8{{/if}}"> 
         {{#with _constructStageList 1='rows' 2=_id 3='content'}} 
          {{> UI.contentBlock stage=this stageContext=../../context}} 
         {{/with}} 
        </div> 
       </div> 
      {{/each}} 
     </div> 
    {{/with}} 
{{/with}} 
</template> 

E questo funziona, ma:

  1. componenti stessi risulta eccessivamente complessa di contesto, un sacco s streghe che fa comprendere la componente un inferno vivente
  2. Il modello ha rotto con un bel paio di aggiornamenti

Così qualcuno ha cercato di fare la stessa cosa ancora? E/o trovato un modello che funzioni per questo?

+0

Davvero un'ottima domanda! –

+0

Hai pensato di usare reagire? – TDmoneybanks

risposta

0

C'è un progetto in fase di sviluppo per fare esattamente questo: UI Harness, dai creatori di Respond.ly. È privato al momento però. Puoi informarlo a partire da Phil Cockfield’s talk at the July 2014 Devshop (YouTube link). Dal video del talk, dovresti avere qualche idea su come strutturare i tuoi componenti se non vuoi aspettare il rilascio di UI Harness.

+0

I progetti su github sono già aperti solo al sito .com che è chiuso (https://github.com/Respondly/meteor-ui-harness) Ma questa soluzione, anche se sembra promettente, non è proprio quello che sono cercando. –

Problemi correlati