Ember-cli: Using a partial with pods

[nathanpalmer]

Assuming we have it setup in pod format is there a way to use a partial within the pod directory? I'm trying to avoid having to throw the template under templates.

var App = Ember.Application.extend({
  modulePrefix: 'test',
  podModulePrefix: 'test/pods',
  Resolver: Resolver
});

The file structure would look something like this.

pods/
pods/posts/
pods/posts/template.hbs
pods/posts/_post.hbs

It seems though that the file isn't even served up (doesn't show up in source) unless it's either called template or exists in the /templates/ directory.

[rwjblue]

That is correct, the file must either be in app/templates/ or be named template.*.

If you want your partial in the pods structure, you should be using {{partial 'posts/post'}}, and placing your file at app/pods/posts/post/template.hbs.

[rwjblue]

The above assumes that you want the file located under the app/pods/posts/ directory, if you just want it in app/pods/post/template.hbs then you would use {{partial 'post'}}.

[nathanpalmer]

Thanks for the response @rwjblue. So that seems to work with my simplistic example, however, looking through our app we have a good 3:1 ratio of main templates to partials. Creating a single folder with a single file for each of those seems a bit like overkill. To give an example here is a modal that we have.

setup/

setup/custom/
setup/custom/controller.js
setup/custom/view.js
setup/custom/template.hbs
setup/custom/facebook.hbs
setup/custom/upload.hbs

If that were done right for ember-cli it would look like this.

setup/

setup/custom/
setup/custom/controller.js
setup/custom/view.js
setup/custom/template.hbs

setup/custom/facebook/
setup/custom/facebook/template.hbs

setup/custom/upload/
setup/custom/upload/template.hbs

Is there a specific reason that we don't want any hbs to get pulled in under pods? Other than naming conflicts (two files with the same name but different extensions conflicting.)

And is there a way to modify this behavior? I assume it's happening on the node side.

[nkgm]

As a workaround you could keep your partials under:

app/templates/post

and then reference them as such from app/pods/post/template.hbs:

{{partial "post/yourpartial"}}

Having said that, I've been wondering the same thing myself. I've tried to treat everything outside the pod structure as the reusable stuff (eg tab views, table components etc) and everything inside the pod structure as the route specific stuff thus having a nice clean separation between the two, but that's just not possible atm. Interested to hear @rwjblue's take on this.

[eccegordo]

+1 on a more obvious way to do partials in pods.

A folder for each partial can be a bit overkill. Would be nice if there was a way to do relative paths.

Maybe I am just misapprehending the purpose of pods. But I would imagine a use case like this:

app/pods/peas/index/template.hbs
app/pods/peas/show/template.hbs
app/pods/peas/new/template.hbs
app/pods/peas/edit/template.hbs
app/pods/peas/partials/form.hbs

And assume some relative path syntax in the other other pod level templates
e.g.

    {{partial 'partials/form'}}

[buschtoens]

IMHO this is quite ugly. Considering that the pods structure is the new way to go (AFAIK), there should be a more obvious / tidy alternative.

I really like this one:

app/pods/taco/template.hbs
app/pods/taco/-description.hbs
app/pods/taco/-another-partial.hbs

This would comply with @stefanpenner's comment here.

[buschtoens]

@rwjblue Any thoughts on this? :)

A bunch of extra folders only containing one template.hbs is really... ugly.

[nkgm]

There's probably too much on their plate atm with 1.10 coming up. Thanks for mentioning @stefanpenner's comment - been wondering what the original intent was re. pods/partials.

[brandonjmckay]

:+1: Going to try keeping the partials in the /templates/... directory for now, love the idea of going forward with some kind of way of doing partials within the pod structure.

[rwjblue]

I personally am angling for partials to be deprecated for 2.0. In an all component world, it makes more sense for a component to handle the shared template.

[stefanpenner]

As components wouldn't shift the context anymore and we will allow for dynamic components. Then ya

[nathanpalmer]

@rwjblue @stefanpenner I had a similar discussion about partials as components yesterday. It depends on if the component can be created with a template only (I don't want the extra codefile) and if there is any performance overhead for instantiating a component versus rendering a partial.

[rwjblue]

Components can be template only or JS only.

[rwjblue]

Or both.

[buschtoens]

@rwjblue great news!

[eccegordo]

@rwjblue One of the features that makes partials potentially useful in some cases is that various properties are transparently available from the parent context (controller, etc).

Is there any mechanism to make components work in a similar way? e.g. where a component can seamlessly proxy attributes from a parent component or outer context like a controller or route?

I may have my terminology wrong here so an example:

Imagine a user form partial and/or component that binds to

• firstName
• lastName
• phone
• etc...

I would much rather be able to do

{{ user-form }}

rather than all the ceremony of

{{ user-form 
  firstName=model.firstName
  lastName=model.lastName
  phone=model.phone
  etc...
}}

or assuming direct access to properties

{{ user-form 
  firstName=firstName
  lastName=lastName
  phone=phone
  etc...
}}

Partials save us from some of this code overhead in our templates.

Apologies if this has been discussed in an rfc already.

[buschtoens]

{{user-form user=model}}?

[rwjblue]

Is there any mechanism to make components work in a similar way? e.g. where a component can seamlessly proxy attributes from a parent component or outer context like a controller or route?

No, and that is a feature, not a bug. ;)

{{ user-form
firstName=model.firstName
lastName=model.lastName
phone=model.phone
etc...
}}

Whats wrong with {{user-form model=model}} or {{user-form user=model}}?

[rwjblue]

Also, in these cases using a {{user-form}} components gives you a specific place to put user form related logic. In many apps today, these sorts of form specific computed properties have been added to the same controller that you might use for displaying a user. It seems much better to me to have small focused components in this way.

[eccegordo]

Nothing is inherently wrong with the pattern of

{{user-form user=model}}

The only thing is that sometimes the attributes that may not be neatly organized into a single model. So then I have to be explicit (which I understand is a feature not a bug)

{{ user-form 
firstName=user.firstName
lastName=user.lastName
phone=addressBook.phone
etc...
}}

My only gripe is that I have gotten so use to marshaling all those attributes into a controller. Was just wondering if components could serve the purpose where a parent component could behave as a controller does today, and a child (or nested component) could behave like a template partial or view does today.

I totally understand the value of isolation of component scope. Just wondering what we lose by deprecating things like partials.

Anyway, that being said in my apps I am very heavy on the use of components anyway. Just find sometimes in specific cases partials are a little easier to use.

[buschtoens]

I'm on vacation (happy new year!) and only got my phone, otherwise I'd probably find out where to put this, but I got an idea.

It would be sexy if this...

```hbs {{user-form firstName=model.firstName lastName=model.lastName phone=model.phone }}

...was equal to...

```hbs
{{user-form model}}
``````

As far as I can see, this is 100% backwards compatible and allows for great flexibility.

Otherwise you'd have to either prefix the attributes in the template with model. or pass in each attribute by hand, which can get tedious very quickly.

[eccegordo]

@buschtoens That would be a very nice feature.

[rwjblue]

{{user-form model}}

Components are not allowed to have ordered params (only hash params).

you'd have to either prefix the attributes in the template with model.

We are removing Ember.ObjectController in 2.0 (and deprecating in 1.11). So you will have to prefix your model properties in your templates either way...

[buschtoens]

Components are not allowed to have ordered params (only hash params).

This is exactly why this would be backwards compatible. Starting from the next minor version update, components would accept one ordered parameter (or multiple maybe) and the traditional hash params. Those params are then merged from left to right.

{{order-summary
 model
 freeDrinks=freeDrinks
 deliveryCost="7.5"
}}

// order-summary.hbs
{{#if model.tacos}}
 You ordered {{model.tacos}} tacos. Good choice! 
{{/if}} 

{{#if model.tortillas}}
 You ordered {{model.tortillas}} tortillas. Yummy! 
{{/if}}

You get {{model.freeDrinks}} free drinks. And the delivery cost is ${{model.deliveryCost}}. Thanks! 

The great advantage here is, that you don't have to explicitly pass in each and every value, but could just throw in the current model or other objects.

[eoinkelly]

I would like to +1 for partials being loaded from pod directories. I think there is a use case for not forcing the "template" of a pod to be a single file.

We are currently building a prototype app (btw: so much :heart: for how easy this is with ember-cli) using pods. Because the design is still not settled we have a lot of example content hard-coded into the templates. We are currently putting our partials in templates/*.hbs but ideally we would keep them with their pod - they are sometimes re-used within a pod but never between pods. I think this situation would be mirrored by many "content heavy" sites.

I don't think components would be a good fit for this as the "natural home" for those templates feels like it is the pod itself given that there is no re-use outside it - we are simply trying to make long HTML templates more tractable.

[jfcouture]

For those interested, I've been using the following hack to be able to use partials in the pod directory.

// in Brocfile.js
// load all .hbs files, not just those named template
EmberApp.prototype._podTemplatePatterns = function() {
  return this.registry.extensionsForType('template').map(function(extension) {
    return new RegExp('.' + extension + '$');
  });
};

// in app/app.js
// based on https://github.com/ember-cli/ember-cli/pull/1439#issuecomment-50027971
var CustomResolver = Resolver.extend({
  // add a new function to use in the lookup paths (can be first/last/wherever)
  moduleNameLookupPatterns: Ember.computed(function(){
    var arr = this._super();
    arr.unshift(this.handleArbitraryTemplateInPodFormat);
    return arr;
  }),

  // load any template/partial in my pods
  handleArbitraryTemplateInPodFormat: function(parsedName) {
    var podPrefix = this.namespace.podModulePrefix || this.namespace.modulePrefix;

    var fullNameWithoutType = parsedName.fullNameWithoutType;

    if (parsedName.type === 'template') {
      fullNameWithoutType = fullNameWithoutType.replace(/^components\//, '');
    }

    return podPrefix + '/' + fullNameWithoutType;
  }
});

[brandensilva]

It's been awhile since this has been discussed. Has everyone decided on nested folder spaghetti or what for something simple like partials?

Right now I'm just leaving the partials in the original template directory structure while the top level resources sit in their pod directory.

If we are going the route of transforming partials into template only components, is their a performance hit for this?

[gnz00]

+1

[ivanbanov]

+1

[lindem]

Just found this issue because I have something that might have been nice to do with partials. Are there any tangible, official moves into the direction of removing or deprecating partials by now, did I miss the memo, or any other news from this past discussion?