Components as the first item in the Pods folder

Questions General
1

I hope this question is not seen as frivolous or pedantic, but I’m wondering whether there is a way to have the Components folder appear first under the Pods project structure. It just feels out of place that the entire set of components sits alphabetically amongst all of the features, and it would be neat if it could sit as the first item in the folder. If this isn’t possible that’s ok, but if it is then I’d be keen to hear about it.

Possible solutions:

  1. Name all routes in the application to come alphabetically after “Component” [not good]
  2. Give Components a custom name (e.g. (Components) ) [is this possible?]

Thanks,

Dave

2

I’m not completely sure what you mean. Can you share a rough outline of your current folder structure (personally, I love to use tree or exa for this)?

3

Hi Robert,

Apologies, looking at my original message it was a bit vague.

I am using the Pods project structure and it looks like this:

app/
    models/
    modifiers/
    pods/
        application/
        boards/
            board/
        ...
        components/
        index/
        search/
        sign-in/
        ...
styles/
tailwind/

etc.

I have opted to create some of the models outside of pods where they don’t pertain to a single feature (i.e. I use the --classic option to generate them).

Clarifying my original question, I feel that components shouldn’t just float/sit in the middle of the pods folder, and it would be nice if I had the option to either move it out of pods, or place it alphabetically at the top of the folder, for example by being able to name it “(components)” as opposed to “components”. If there was an option to configure alternate folder names that would be nice (like we specify the pods folder name and location), but I understand that that option probably doesn’t exist.

Hopefully that clarifies things.

Thanks,

Dave

4

Check out this older post - explains how to insert a module resolver ahead of what ember does on its own. Log the type of the parsedName parameter out to the console and you’ll see the nature of what you need to do.

Also, for es6, import Resolver from ‘ember-resolver’ and subclass, overriding the same methods as in the post.

5

Thanks @Dathan, your suggestion looks promising but I still have my training wheels on! Should I be creating my own custom resolver, subclassing the resolver and then using this in app/app.js in place of the default?

6

If using classes, then yes, subclass the resolver and put it in app/resolver.js then you can import it to your app.js. Here is ours from one of our projects where we altered how services were resolved and introduced a new service-api concept (we don’t use ember-data due to a number of scalability and atomicity limitations):

app/app.js

import Application from '@ember/application';
import Resolver from './resolver';
import config from './config/environment';

export default class App extends Application {
  modulePrefix = config.modulePrefix;
  podModulePrefix = config.podModulePrefix;
  Resolver = Resolver;
}

app/resolver.js

import Resolver from 'ember-resolver';

export default class CustomResolver extends Resolver {
  customModuleResolution(parsedName) {
    const svcPrefix = `${this.namespace.modulePrefix}/services`;
    const {type, fullNameWithoutType} = parsedName;

    if (type === 'service-api') {
      const module = `${svcPrefix}/${fullNameWithoutType}/api`;
      return module;
    }

    if (type === 'service') {
      const module = `${svcPrefix}/${fullNameWithoutType}/service`;
      return module;
    }

    return undefined;
  }

  get moduleNameLookupPatterns() {
    const patterns = super.moduleNameLookupPatterns;

    // Insert our custom pattern ahead of existing
    return [this.customModuleResolution, ...patterns];
  }
}

Also, if you return undefined or a module that cannot be found, the next method in the array returned by moduleNameLookupPatterns is tried automatically.

7

Much appreciated Dathan. I’ll have a play.