Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Components with templates in pod structure #30

Closed
rlivsey opened this issue Feb 28, 2014 · 15 comments · Fixed by #53
Closed

Components with templates in pod structure #30

rlivsey opened this issue Feb 28, 2014 · 15 comments · Fixed by #53

Comments

@rlivsey
Copy link
Contributor

rlivsey commented Feb 28, 2014

This might be one for discourse, but wondering how to handle components with templates when in the pod structure (ie not storing them in the templates directory).

At the moment this works, but is a bit weird:

/components/foo-bar.js
/components/foo-bar/template.handlebars

But I'd like something like:

/components/foo-bar/component.js
/components/foo-bar/template.handlebars

or maybe:

/components/foo-bar/index.js
/components/foo-bar/template.handlebars

Is there a way to configure the resolver to handle that / or alternatives?

@rwjblue
Copy link
Member

rwjblue commented Feb 28, 2014

@rlivsey - With the current implementation, you would use the following:

/foo-bar/component.js
/components/foo-bar/template.hbs

I would agree that the following would be better for components:

/components/foo-bar/component.js
/components/foo-bar/template.hbs

I agree that that seems odd, and have been thinking of allowing an escape hatch (exactly the same as the current resolver does for resolveModel and friends), but enabling a bit more reuse in the code. This is possible now, but you would have to essentially rewrite our custom resolveOther, and that stinks.

I need to break up resolveOther into smaller chunks allowing overriding the individual methods (closer to the Ember Data adapter's ajax, ajaxOptions, headers, etc).

@rlivsey
Copy link
Contributor Author

rlivsey commented Feb 28, 2014

Gotcha, for now I'll keep with the template being in a sub-directory as at least then it's in the same part of the tree.

@merlinchen
Copy link

@rjackson - Is It possible to put componet in nested directories? Like:

/nested/foo-bar/component.js

And specify this component in template like:

{{nested/foo-bar}}

@DougPuchalski
Copy link

👍 for

/components/foo-bar/component.js
/components/foo-bar/template.hbs

Also This seems even better, maybe only two files doesn't call for a folder

/components/foo-bar.js
/components/foo-bar.hbs

@williamli
Copy link

+1 for

    /components/.../foo-bar/component.js
    /components/.../foo-bar/template.hbs

or

    /.../foo-bar/component.js
    /.../foo-bar/template.hbs

the above might have template of the component /nested/foo-bar clashing into the route /nested/foo-bar so maybe /components/nested/foo-bar/... seems to be a better option

anything but

    /components/.../foo-bar.js
    /components/.../foo-bar/template.hbs

maybe i am having an OCD attack... I will just try not to think about it 🙈

@rlivsey
Copy link
Contributor Author

rlivsey commented Jun 13, 2014

I'm currently re-writing paths in my project so I can store them where I think they should live and have broccoli move them to where the resolver can find them.

Massive hack, but works for now.

// move components/foo-bar/component.coffee -> components/foo-bar.coffee
// move app/components/foo-bar/template.handlebars -> app/templates/components/foo-bar.handlebars
// move app/components/foo-bar/foo-controller.coffee -> app/controllers/components/foo-bar/foo-controller.coffee
app = rewritePath(app, function(pathToFile) {
  if (pathToFile.match(/\/component.coffee$/)) {
    return pathToFile.replace(/\/component.coffee$/, '.coffee')
  }

  var match;
  match = pathToFile.match(/components\/(.*)\/template\.handlebars/)
  if (match) {
    return "app/templates/components/"+match[1]+".handlebars"
  }

  match = pathToFile.match(/components\/(.*)\/(.*)\.handlebars/)
  if (match) {
    return "app/templates/components/"+match[1]+"/"+match[2]+".handlebars"
  }

  match = pathToFile.match(/components\/(.*)\/(.*)-controller\.coffee/)
  if (match) {
    return "app/controllers/components/"+match[1]+"/"+match[2]+".coffee"
  }

  match = pathToFile.match(/components\/(.*)\/(.*)-view\.coffee/)
  if (match) {
    return "app/views/components/"+match[1]+"/"+match[2]+".coffee"
  }
})

@rwjblue
Copy link
Member

rwjblue commented Jun 13, 2014

After the recent refactoring, I think we finally have a nice structure for handling this with minimal changes.

var CustomResolver = Resolver.extend({
  podBasedModuleName: 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 + '/' + parsedName.type;
  }
});

PR incoming.

@rwjblue
Copy link
Member

rwjblue commented Jun 13, 2014

Submitted #53 fixing.

@williamli
Copy link

@rjackson thanks. how can it get this over in ember-cli?

@rwjblue
Copy link
Member

rwjblue commented Jun 13, 2014

You can make a custom resolver that does this fairly easily (see code pasted above).

Then use that CustomResolver as your Resolver (at application extend/create time).

See here for a sample Ember CLI app with this modification.

@DougPuchalski
Copy link

@rjackson This is great, thank you for this refactor. Huge win.

To make this slightly less invasive, I've renamed that method as-is and have added it, and some others, to the lookup patterns.

  moduleNameLookupPatterns: Ember.computed(function(){
    return Ember.A([
      this.mainTemplateBasedModuleName,
      this.explicitTemplateBasedModuleName,
      this.componentModuleName,
      this.podBasedModuleName,
      this.mainModuleName,
      this.defaultModuleName
    ]);
  }),

  // https://github.com/stefanpenner/ember-jj-abrams-resolver/issues/30#issuecomment-46008394
  componentModuleName: 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 + '/' + parsedName.type;
  },

  // Resolves: pods/posts/posts.hbs
  mainTemplateBasedModuleName: function(parsedName){
    var podPrefix = this.namespace.podModulePrefix || this.namespace.modulePrefix;
    var fullNameWithoutType = parsedName.fullNameWithoutType;

    if (parsedName.type === 'template') {
      return podPrefix + '/' + fullNameWithoutType + '/' + fullNameWithoutType;
    }

    return null;
  },

  // Resolves: pods/posts/comments.hbs
  explicitTemplateBasedModuleName: function(parsedName){
    var podPrefix = this.namespace.podModulePrefix || this.namespace.modulePrefix;
    var fullNameWithoutType = parsedName.fullNameWithoutType;

    if (parsedName.type === 'template') {
      return podPrefix + '/' + fullNameWithoutType;
    }

    return null;
  },

@simonexmachina
Copy link

I would be great to have a solution for this that doesn't involve a custom resolver. Are there any thoughts on this front?

@rwjblue
Copy link
Member

rwjblue commented Aug 7, 2014

Unless I am mistaken this is already possible without modification.

See #61

@rwjblue
Copy link
Member

rwjblue commented Aug 7, 2014

And #53

kratiahuja pushed a commit to kratiahuja/ember-resolver that referenced this issue Aug 5, 2016
@JulianLeviston
Copy link

This is a naming question.

If we have a component called big_combo, which has two files in it... component.js and template.hbs, the template is obviously called the template, what is the component javascript file called? given that the component is the combination of both the component.js and template.hbs files? "The component's component file" sounds a bit odd.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants