Skip to content

Instantly share code, notes, and snippets.

@trabus
Last active August 29, 2015 14:17
Show Gist options
  • Save trabus/0a3d100aedc21e9b338f to your computer and use it in GitHub Desktop.
Save trabus/0a3d100aedc21e9b338f to your computer and use it in GitHub Desktop.
Resolver ideas to work with pods and structures

Resolver Idea for Structures

Resolver rules don't belong in structures

Structures don't need to have the lookup pattern defined in them, they should instead conform to available patterns provided by the resolver. The issue is that the resolver deals with compiled modules, and structures are for pre-compilation. The resolver does have a role in how structures should work, but it shouldn't be coupled to the way the structure is defined. The difficulty of getting the resolver rules out of the structure and into the resolver also shows that it's not the right path.

The resolver could use a hash to resolve different types, defining the prefix to use for each, as well as the structures supported (implied by the prefix). For this example let's assume there is no 'pods' folder, but rather the prefix describes the structure used in the folder. We should also assume that modules of a specific type are only generated in pod or type structure, not both. This config example is a bit contrived, and doesn't take into account all factors in the existing resolver. We'd likely have default behavior that would kick in when an unknown type is encountered. Unknown types would use type structure, as it is currently done (I think).

The following would not necessarily need to be a config, it could be generated, but a config is the easiest way for me to communicate the idea.

var config = {
  // patterns/rules
  patterns: {
    type: ['root','prefix','name'],
    pod: ['root','prefix','name','type']
  },
  // structure for prefix
  prefixes: {
    components: 'pod',
    helpers: 'type',
    initializers: 'type',
    mixins: 'type',
    models: 'pod',
    resources: 'pod',
    services: 'type',
    utils: 'type'
  },
  // prefix to use by type
  types: {
    adapter: {
      prefix: 'models',
      suffix: 'js'
    },
    component: {
      prefix: ['resources','components'],
      suffix: 'js'
    },
    controller: {
      prefix: 'resources',
      suffix: 'js'
    },
    helper: {
      prefix: 'helpers',
      suffix: 'js'
    },
    initializer: {
      prefix: 'initializers',
      suffix: 'js'
    },
    mixin: {
      prefix: 'mixins',
      suffix: 'js'
    },
    model: {
      prefix: 'models',
      suffix: 'js'
    },
    resource: {
      prefix: 'resources',
      suffix: 'js'
    },
    route: {
      prefix: 'resources',
      suffix: 'js'
    },
    serializer: {
      prefix: 'models',
      suffix: 'js'
    },
    service: {
      prefix: 'services',
      suffix: 'js'
    },
    template: {
      prefix: ['resources', 'components'],
      suffix: ['hbs', 'handlebars']
    },
    transform: {
      prefix: 'transforms',
      suffix: 'js'
    },
    util: {
      prefix: 'utils',
      suffix: 'js'
    },
    view: {
      prefix: 'resources',
      suffix: 'js'
    },
    default: {
      prefix: '',
      suffix: 'js'
    }
  }
}

// root is provided as modulePrefix, or an array of strings. 
//We'll assume it is 'my-app' for this example
// given a path to resolve: resolve('type:name')
resolve('component:taco-bell')

// The following would actually be handled through a method like parseName.
//=================================================
// assume type and name are already parsed
// lookup prefix by type first
var prefix = config.types[type].prefix; // ['resources','components']
var suffix = config.types[type].suffix;

// lookup structure by prefix
var structure = config.structures[prefix]; // 'pod'

// lookup pattern by structure
var pattern = config.patterns[structure]; // ['root','prefix','name','type']
//=================================================
// resulting in:
{
  root: 'my-app',
  name: 'taco-bell',
  type: 'component',
  prefix: ['resources','components'],
  suffix: 'js',
  structure: 'pod',
  pattern: ['root','prefix','name','type']
}

//generated lookup paths
'my-app/resources/taco-bell/component.js'
'my-app/components/taco-bell/component.js'
// lookup template
resolve('template:taco-bell')

{
  root: 'my-app',
  name: 'taco-bell',
  type: 'template',
  prefix: ['resources','components'],
  suffix: ['hbs', 'handlebars'],
  structure: 'pod',
  pattern: ['root','prefix','name','type']
}

// generated lookup paths
'my-app/resources/taco-bell/template.hbs'
'my-app/components/taco-bell/template.hbs'
'my-app/resources/taco-bell/template.handlebars'
'my-app/components/taco-bell/template.handlebars'
// lookup validator
resolve('validator:email')

// because validator is an unknown type, default is to use the type name pluralized as the prefix

{
  root: 'my-app',
  name: 'email',
  type: 'validator',
  prefix: 'validators',
  suffix: 'js',
  structure: 'type',
  pattern: ['root','prefix','name']
}

// generated lookup paths
'my-app/validators/email.js'

This is just a rough pass on the idea. Please poke holes in it and let me know if I'm off base. I'll be adding this to the structures RFC after review, and then using that to base the pods RFC from, including the research here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment