Rename plugins

[zaceno]

The mechanism for plugins has proven a generally useful way to separate the concerns of your app into separate modules.

If for example, you are writing an admin interface for a blogging platform, you might want to separate your code into auth, posts, comments, et c modules, containing the state, actions, events relevant to each respective topic.

By exposing each module's state, actions, events as a plugin, it becomes very convenient to bring them together in a single app using app({ ... plugins: [auth, posts, comments], ...})

However, the word "plugins" implies it is only meant for more general, reusable things. Not as a way to structure your app. Therefore, I move that the name "plugins" be changed to something else. The question is what?

Either, we find a suitable noun, such as "modules" (except "modules" might cause some confusion), or, perhaps we don't hard-code a name into hyperapp, and instead declare the plugins with a verb, such as: app({ ... compose: [auth, posts, comments] ...}). Other options, besides "compose", might be "include" or "merge".

If we go the "verb" route, we'll still need a noun to use instead of "plugins", for docs and discussions. But we're more free to use a longer, descriptive name, like "hyperapp-modules" for example.

At the moment, I think my vote is on: app({ ... include: [foo, bar] ...}) and calling the includees "hyperapp-modules" in the docs

[zaceno]

Another idea might be to simply rename plugins to "mixins"

[selfup]

I would prefer mixins for this 😄

[jorgebucaran]

@zaceno I like mixins too, but do mixins encompass plugins conceptually? If they do, then I think we may have a winner.

I was just worried that people looking at "mixins" may think of them as a simple to structure/compose apps, but not as plugins. If that's not the case then it's good.

[zaceno]

@jbucaran Good question... I think mixins probably do encompass plugins but it's kind of open to interpretation.

The way I see it, a mixin works by augmenting the functionality of something, whereas a plugin is more about using an interface to couple two things together. So... I guess I see mixins as one way to plug something in, and at the same time they are more broadly useful.

Sorry if that sounded vague and rambling... :)

[jorgebucaran]

That's okay. Mixins is a more vague concept just like hyperapp plugins are a vague feature named plugins for lack of a better name.

Starting to like mixins; it sounds less harmful than plugins too 😆.

How do you...?

Just use a mixin for that.

@dodekeract @lukejacksonn @pedroborges @itrelease What do you think?

[FlorianWendelborn]

@jbucaran I don't really care about semantics. So for ease-of-use I'd vote to keep the current name so nobody has to change it in their sourcecode.

[jorgebucaran]

@dodekeract Thanks for the feedback. I'm not happy about breaking the API either, but #190 will break it too anyway, and @zaceno's point is convincing.

[SkaterDad]

I personally feel that plugins is the right word for it. My stance on naming things overall is that it doesn't really matter, and devs are smart enough to figure it out.

For reference, the Hapi ecosystem consists of plugins as well. The recommended way of building Hapi apps is to create multiple plugins (consisting of routes, server methods, etc) and compose them together. Their way of doing it is a lot more complicated, but the concept is the same.

[jorgebucaran]

The reason I went with plugins in the first place is because it's a familiar term. Everyone has heard about plugins, but not everyone has heard about mixins.

[jorgebucaran]

@SkaterDad Any thoughts with regards to mixins?

[SkaterDad]

@jbucaran When I hear mixins, I think of code that you sprinkle in where necessary to merge a re-usable bit of logic into something. Kind of how React used to promote the pure render mixin that would insert a shouldComponentUpdate function into your components. Or how you can use mixins in SASS to merge the properties of a base style into a more specific class.

For me, I see plugins as something globally applicable (like sugar in a cake), but mixins are things you sprinkle in where needed (like sprinkles).

[jorgebucaran]

Sprinkles! 😆

@zaceno Any remarks?

[jorgebucaran]

Riot has mixins btw.

• http://martinmuzatko.github.io/riot-cheatsheet/#cheatsheet-mixin

[zaceno]

@jbucaran: For me what characterizes a mixin is not so much how much you use it, as how. It comes down to the design pattern. So maybe mixins aren't the best term either, but it's broad enough to encompass many use-cases, which is why I like it.

"Plugins" make me think of things like backbone-plugins. So: something exclusively for extending your framework. That's why I think this is a problem. Because when you use plugins not to extend/augment hyperapp itself, but just to structure your own code, it feels like you're doing something wrong, when you're not.

[jorgebucaran]

@zaceno @SkaterDad

Which one is less worse?

Functionality-wise, whatever we end up going with will not modify how this feature works.

Plugins is a familiar term, and familiarity is useful when teaching/learning new concepts. That's why we changed model to state, merged subs/hooks into events and also: https://github.com/hyperapp/hyperapp/issues/190.

Mixins is not unheard of, but it's more obscure than plugins. I agree that the term mixins is more precise than plugins when you think about how this feature is implemented though. I also like the sound of it!

Question:

1) Are mixins a superset or a subset of plugins? 2) If current hyperapp plugins are actually mixins, then what would actual plugins be (in theory)?

[zaceno]

@jbucaran It's hard to say categorically, because as you point out, it's a lot about the general perception of what things mean, or how heavy/complicated things are percieved to be (wether or not they actually are). But I'll answer as best I can:

1. Yes. Mixins are a superset of plugins. Mixins are things that get mixed in, and plugins are one of several things that can be mixed in. (That said, you can also add plugins to a framework via other patterns like dependency injections, standardized interfaces...)

2. Something I would consider an actual plugin would be things like: a logger, a time-travelling debugger, a general REST-backend-data synchronizer.

I would consider these as both plugins and mixins because:

a) They expand the framework with general functionality (= plugin) b) They do said expansion by mixing in events, actions and state (= mixin)

If however, I separate various concerns of my app into separate modules (like authentication, blog posts, comments, user-management...), and combine them together into a single app using the feature currently called "plugins" -- then these things are:

a) Adding app-specific functionality -- NOT general (= NOT a plugin) b) Doing so by mixing in events, actions and state (=mixin)

[zaceno]

I'd like to add that the one reservation I have about the word "mixin" is that it is kind of already taken.

Most who know the term may believe we are talking about the OO-pattern of assigning bound functions to objects after instantiation.

... but on the other hand, unless we invent a completely new word, any term we choose will have the potential of causing confusion. We should just try to cause as little confusion as possible. I feel like we can do better than "plugins", but I'm just one guy...

[selfup]

Vue does mixins as well: https://vuejs.org/v2/guide/mixins.html

tl;dr Mixins are a flexible way to distribute reusable functionalities for Vue components

And Vue also has Plugins! Very good descriptions in both: https://vuejs.org/v2/guide/plugins.html#ad

tl;dr Plugins usually add global-level functionality to Vue.

[jorgebucaran]

Well, I definitely want to go with one concept only.

@selfup It's good to know that Vuejs also has mixins, I think that works as +1 for mixins.

Who else is using mixins and how?

[selfup]

Angular 2/3/4 seems to have Mixins as well however not officially but through typescript decorators

[lukejacksonn]

A discussion here from marionette, they have behaviors I think.. https://github.com/marionettejs/backbone.marionette/issues/1491 and and mixins https://github.com/onsi/cocktail

[jorgebucaran]

@SkaterDad Do you see using mixin as detrimental for hyperapp?

[SkaterDad]

@jbucaran I don't see calling them mixins as detrimental, but I also don't see how it would be beneficial.

If you're going through the effort to push a breaking change, maybe go bold and rename "plugins" to the Japanese translation, using the actual characters? That way people who use hyperapp will get to learn something :smile:

Google said "plugin" -> プラグイン Is that right?

[jorgebucaran]

Very funny. And, yes, プラグイン, that's how they're called. 😄

[SkaterDad]

I take it back. プラグイン appears to be 15 bytes, so that's a big penalty compared to "plugins" or "mixins".

[jorgebucaran]

@zaceno I like the sound of mixins and I realize mixins in hyperapp would not be the same mixins talked about in:

• https://medium.com/@dan_abramov/mixins-are-dead-long-live-higher-order-components-94a0d2f9e750
• https://facebook.github.io/react/blog/2016/07/13/mixins-considered-harmful.html
• https://www.quora.com/Why-are-mixins-so-bad

But they seem to have a bad reputation, so I'm not sure this change would be better than worse.

[zaceno]

Seems from the articles you linked, react-mixins have a bad reputation in the react community. I'm thinking of mixins more along the line of a design pattern (https://www.safaribooksonline.com/library/view/learning-javascript-design/9781449334840/ch09s13.html) -- and like all design patterns, it's sometimes good, sometimes bad. Use when appropriate :)

[jorgebucaran]

That's a good reference.

Let's see how people react to this: #194.