Pourquoi le cli d'ember ne génère-t-il pas le pont d'application pour le fichier hbs lors de la génération du composant depuis addon?

Quand je lance ember g component foo-bar dans un projet Ember Addon (disons addon-project), il génère ce qui suit:Pourquoi le cli d'ember ne génère-t-il pas le pont d'application pour le fichier hbs lors de la génération du composant depuis addon?

// addon-project/addon/components/foo-bar.js 
import Ember from 'ember'; 
import layout from '../templates/components/foo-bar'; 

export default Ember.Component.extend({ 
    layout 
} 

// addon-project/addon/templates/components/foo-bar.hbs 
{{yield}} 

// addon-project/app/components/foo-bar.js 
export { default } from 'addon-project/components/foo-bar';

je remarquai que cela ne génère pas addon-project/app/templates/components/foo-bar.js d'exporter le modèle de composant, mais lier explicitement le modèle à l'aide layout.

Pourquoi ne pas générer addon-project/app/templates/components/foo-bar.js? Y a-t-il une raison à ce comportement?

également pourquoi layout importé en utilisant un chemin relatif au lieu de chemin absolu (c.-à-import layout from 'addon-project/templates/components/foo-bar

Source

2016-07-27 lordofthefobs

Première - quelle version de ember-cli utilisez-vous Blueprints dépend de la version

Pour moi, il faut faire ensuite

vvs ~/r/e/test-addon> ember -v 
ember-cli: 2.6.3 
node: 4.4.7 
os: darwin x64 
vvs ~/r/e/test-addon> ember g component test-component 
Could not start watchman; falling back to NodeWatcher for file system events. 
Visit http://ember-cli.com/user-guide/#watchman for more info. 
installing component 
    create addon/components/test-component.js 
    create addon/templates/components/test-component.hbs 
installing component-test 
    create tests/integration/components/test-component-test.js 
installing component-addon 
    create app/components/test-component.js

il génère donc modèle aussi bien

Suivant - il utiliser connexes chemin d'importation layour pour diminuer le nombre de places qui dépend de addon namespace (qui est défini dans index.js - donc si vous changez cet espace de noms à l'avenir - vous devez mettre à jour uniquement les fichiers explicitement mappés dans l'application)

Oh. Il n'a pas généré de cause de pont de modèle dans la disposition utilisée par le composant. Il vous permet d'étendre le composant sans définir de modèle (vous pouvez simplement étendre le composant original, ajouter/modifier la logique et ignorer le modèle de création) Si vous utilisez le modèle au lieu de la mise en page, vous devez définir le modèle manuellement.

Source

2016-07-27 23:24:39

J'ai testé les deux 2.4.3 et 2.7.0. En fait, il n'a pas généré le fichier de pont pour le modèle pour vous non plus. Il a généré le composant, le modèle, le test pour le composant et le pont pour le composant mais PAS le pont pour le modèle. Je me demande pourquoi il n'a pas généré le fichier 'test-addon/app/templates/composants/test-component.js' dans votre cas – lordofthefobs

re: ne dépend pas de l'espace de noms addon ... Cette logique n'a pas de sens à moi. 1) Pourquoi changeriez-vous votre espace de noms d'addon? Cela ne semble pas être quelque chose que vous devriez ou devriez faire. Et même si vous le devez, vous pouvez simplement "trouver et remplacer tout". 2) l'utilisation du chemin relatif est fragile. Si vous avez plusieurs couches d'organisation, vous finirez par "../../../../". Et si vous vous déplacez autour de votre fichier, vous devrez vous assurer que vous avez le bon nombre de ../ 3) Et c'est le seul endroit où j'ai vu EmberCLI utiliser le chemin relatif. Même Ember Data utilise l'espace de noms 'ember-data' en interne, pas le chemin relatif. – lordofthefobs

Pourquoi le cli d'ember ne génère-t-il pas le pont d'application pour le fichier hbs lors de la génération du composant depuis addon?

Répondre

Questions connexes