strapi / rfcs

RFCs for Strapi future changes
70 stars 33 forks source link

Global naming convention and getters #2

Closed alexandrebodin closed 5 years ago

alexandrebodin commented 5 years ago

Introduce a global naming convetion for services, controllers and models.

Read the proposal here

Aurelsicoko commented 5 years ago

LGTM 👍


FYI, I tried to rewrite the entire controller User.js of the Users & Permissions plugin, and I found it was difficult to create the string to get a service. It wasn't natural to write :

strapi.service('plugins::users-permissions.user').add(ctx.request.body)

but it was easier in my mind to write this instead

strapi.plugin('users-permissions').service('user').add(ctx.request.body);

I think the main reason is that every part is dissociated from each other. First, I'm going into my plugin, I select the service I want to use, and then the method to call. Whereas, in the current proposal, the schema of thinking is a bit different.

Current proposal: Call the service > Find the location > Call the method

My draft proposal: Find the location > Call the service > Call the method

alexandrebodin commented 5 years ago

LGTM 👍

FYI, I tried to rewrite the entire controller User.js of the Users & Permissions plugin, and I found it was difficult to create the string to get a service. It wasn't natural to write :

strapi.service('plugins::users-permissions.user').add(ctx.request.body);

but it was easier in my mind to write this instead

strapi
  .plugin('users-permissions')
  .service('user')
  .add(ctx.request.body);

I think the main reason is that every part is dissociated from each other. First, I'm going into my plugin, I select the service I want to use, and then the method to call. Whereas, in the current proposal, the schema of thinking is a bit different.

Current proposal: Call the service > Find the location > Call the method

My draft proposal: Find the location > Call the service > Call the method

Interesting thought. In most frameworks there is only one root access to avoid increasing the API surface area. It might be more a matter of habits because you have to do strapi.plugins[plugin] right now :).

Anyway as long as we keep global UIDs we can provide plugin scoped getters quite easily. Something like that would do:

const ctx = {
  plugin(plugin) {
    return {
      service(key) {
        return ctx.service(`plugins::${plugin}.${key}`);
      },
      controller(key) {
        return ctx.controller(`plugins::${plugin}.${key}`);
      },
      model(key) {
        return ctx.model(`plugins::${plugin}.${key}`);
      },
    };
  },

  // root api
  service(key) {
    // implementation details
  },
  controller(key) {
    // implementation details
  },
  model(key) {
    // implementation details
  },
};

I'm not sure I would recommend it from the start though. it might also be handled in userland with a simple plugin ;)

derrickmehaffy commented 5 years ago

I see @Aurelsicoko's point of view with the old structure for plugins but realistically it's just a matter of mindset. Either way I like the proposal from @alexandrebodin and think it will work the way it was described but documentation will be important here.

Aurelsicoko commented 5 years ago

That's what I think too... just another way of thinking. I shared my point of view, it doesn't mean we should implement it, you have a better experience than me on this topic @alexandrebodin