Helper for applying multiple plugins

[koskimas]

This can become a mess:

class BaseModel extends Plugin1(Plugin2(Plugin3({opt: 'foo'})(Plugin4(Model)))) {

}

Should we add a helper like this:

class BaseModel extends Model.plugin(Plugin1, Plugin2, Plugin3({opt: 'foo'}), Plugin4) {

}

Or would mixin be a better name for the method?

Arrays would also be supported:

class BaseModel extends Model.plugin([
  Plugin1, 
  Plugin2, 
  Plugin3({opt: 'foo'}),
  Plugin4
]) {

}

[devinivy]

Worth checking the API/implementation of this lib for inspiration https://github.com/justinfagnani/mixwith.js

If you go the direction you're hinting at, I'd request to at least let Model.plugin(P1, ..., Pn) extend from Model even if Model is already an extension of Objection.Model.

[koskimas]

@devinivy That library was my inspiration. I originally thought of adding a helper like:

class Person mixin(Model, Plugin1, Plugin2) {

}

but then the user would need to require the mixin helper. Since we are always mixin in stuff to Model or QueryBuilder or some othe known baseclass, we can make the mixin helper a static method.

The implementation would be as simple as this:

class Model {
  static plugin() {
    return _.flatten(_.toArray(arguments)).reduce((Model, Plugin) => {
      return Plugin(Model);
    }, this);
  }
}

Of course it will always extend this instead of objection.Model. The following two are equivalent:

class Person extends Model.plugin(Plugin1, Plugin2) {

}

class Person extends Model.plugin(Plugin1).plugin(Plugin2) {

}

[fl0w]

Wouldn't it be easier to have a callable api that just reassigns objection.Model with most recent "extends"?

objection.plugin(Plugin1)
objection.plugin(Plugin2)
objection.plugin(Plugin3)

[koskimas]

@fl0w Nope, then we would lose part of the flexibility. After that you would have no way to access the original unmodified Model. I think this comment by @devinivy explains it well.

[fl0w]

@koskimas understood. Storing the plugin/model chain layout wouldn't help either?

objection.inspectPluginChain = {
  original: Model,
  'plugin-name-1': Plugin1, 
  'plugin-name-2': Plugin2
}

Extending with intent is always an option but, correct me if I'm wrong, generally plugins would be used application wide? (considering soft-delete/case-conversion/auto-update-timestamps perhaps).

edit I'm not criticising the provided solution, just exploring by poking. Ignore if I'm annoying.

[koskimas]

generally plugins would be used application wide?

Probably, but nothing prevents you from doing

objection.Model = objection.Model.plugin(Plugin1, Plugin2);

[fl0w]

Ah, got it. Thanks. That's clean!

[koskimas]

Would you prefer mixin instead of plugin as the name? I think we could use this kind of helper because many people seem disgusted by

class BaseModel extends Plugin4(Plugin3(Plugin2({opt: 'foo'})(Plugin1(Model)))) {

}

This seems cleaner to me:

class BaseModel extends Model.mixin([
  Plugin1, 
  Plugin2({opt: 'foo'}), 
  Plugin3,
  Plugin4
]) {

}

[fl0w]

That's sort of reminiscent of a stack of decorators (visually).
I think it's generally easier to list than scope depth, so I personally prefer the latter.

edit, sorry, I prefer "mixin" - though I don't have any strong feelings. Can the term "plugin" be used in different contexts? I think "mixin" is more specific (thus easier to document?).

[koskimas]

Yeah, mixin is what we are doing. I think that's a better name. I'll still document plugin usage using simple function calls (like it is explained today) so that people see what is going on. I'll only add a side note about the mixin helper for the people that throw up in their mouth.

[vladshcherbin]

Maybe a simple compose helper like this one can be added for multiple plugins (which are called higher-order functions). It is widely used and tested by react users:

import { compose, Model } from 'objection'

class Animal extends Model {
  static tableName = 'animals'
}

// Single higher-order function
export default timestamps({ type: 'timestamptz' })(Animal)

// Multiple higher-order functions
export default compose(
  timestamps({ type: 'timestamptz' }),
  softDeletes
)(Animal)

Another way is to use decorators(babel stage 2 proposal), though I prefer compose helper:

@timestamps({ type: 'timestamp' })
@softDeletes
class Animal extends Model {
  static tableName = 'animals'
}

[koskimas]

@vladshcherbin The problem with applying the mixings after extending the parent class is that the class name will be the name of the last applied plugin class. All stack traces containing model methods will have confusing class names. Otherwise you can already do that.

I'm getting the feeling that no-one is especially thrilled about the plugin or mixin helper as a static member of Model. @devinivy Would you prefer a separate helper function in objection core:

import { mixin, Model } from 'objection'

class Animal extends mixin(Model, [Plugin1, Plugin2]) {
  static tableName = 'animals'
}

Or would you prefer no helpers at all?

@vladshcherbin If we go down that road, I could also add a compose function like you suggested.

[devinivy]

While it's not a big deal to me, I think it would be useful to have a very basic one in objection to reinforce the standard way to write an objection plugin. I think it would be positive for the objection ecosystem. Whether it's Model.mixin() or mixin(Model), I think it's fine :)

[vladshcherbin]

@koskimas maybe class name won't be wrong if higher-order function is defined like this one?

function timestamps(options) {
  return WrappedModel => (
    class extends WrappedModel {
      ...
    }
  )
}

[koskimas]

Try this:

class X {}
const f = (M) => class extends M {}
const Y = f(X);
console.log(Y.name);

and you get '' as an output. The last extending class has no name.

[vladshcherbin]

@koskimas actually it's giving me X as a result. Here is the jsbin example.

Using babel with env preset set to node 5 or higher, it also gives the same result of X - babel repl. With preset set to node 4 it gives '_class' - babel repl.

[koskimas]

Node 7 gives an empty string and so does node 4. I doubt that 5,6 or 8 act any different. Babel is not 100% compatible in this case. We can't write features for Babel. They must be written against ecmascript standard and actual native node.

[vladshcherbin]

@koskimas for me, babel is working exactly the same as node. Here is the same code with pure node 8:

[koskimas]

You're right. Node 8 does work like that. Older versions give the empty string. That's good news, but I suspect that many plugin developers give names to their plugin classes. Maybe we should add this to best practices and encourage people to leave the classes nameless.

[vladshcherbin]

@koskimas yeah, this will be great. With latest node versions and babel you get nice things like async/await, decorators, etc.

Adding plugins also becomes a joy with higher-order functions and a combining helper like compose. This is exactly the way I would add them in my projects.

[maprangsoft]

@vladshcherbin The problem with applying the mixings after extending the parent class is that the class name will be the name of the last applied plugin class. All stack traces containing model methods will have confusing class names. Otherwise you can already do that.

I'm getting the feeling that no-one is especially thrilled about the plugin or mixin helper as a static member of Model. @devinivy Would you prefer a separate helper function in objection core:

import { mixin, Model } from 'objection'

class Animal extends mixin(Model, [Plugin1, Plugin2]) {
  static tableName = 'animals'
}

Or would you prefer no helpers at all?

@vladshcherbin If we go down that road, I could also add a compose function like you suggested.

thank you very much.