Registry set component - Maybe it's an antipattern?

Kirby components is a really powerful way to jack in to common classes of Kirby, by extending them and override the methods.

When I write “plugin” below I don’t mean a custom plugin for the current site, but a plugin that can be used anywhere.

A component can only be used ones

Let’s say we register a component in a plugin that can be used by many sites. It means that no other plugins can use that same component. If another plugin also register the same component, only one of them is used. By this reason I think it’s really crucial that we should think twice before we use a component. There is always a big risk that we block another plugin function, or get blocked by it outselves.

Compared to other Kirby features

Most of them

Most of the Kirby features uses an unique key of some kind which makes it possible to just hang on unlimited things. Examples are fields, templates, snippets, widgets, tags, blueprints, controllers, page methods, pages methods etc. If we just name them unique enough, they will not collide with other plugins.

Models

Because models extends a class I think this case has the same problems as components.

Kirby Architect made me think

@AugustMiller github.com/AugustMiller/kirby-architect/issues/4

It’s really a complete different topic. It’s about having the plugin register a page method or not. In this case it’s up to the site admin to set up the page method himself/herself. Then the site admin can use an own key for it and the chance of collision is up to the user.

So how is this even relevant? It made me think that a plugin approach is to let the admin set up things himself/herself, instead of having the plugin do it.

Thoughts

In cases where we use page methods in plugins, I think it’s fine both to have them there or not have them there, depending in what the plugin does.

I see much more danger in register components and even models by a plugin. Maybe we should follow a kind of @AugustMiller approach and add all the core stuff in the plugin, but not register the component and instead let the user set up the component?

The advantage would be that the site admin can now use two or more plugins with the same component.

Future

I think the best solution would be to figure out a better core function to hook into the components.

A big problem would be for Kirby to know the order of these “hooks”. It could be solved by adding a dependency array with keys. If other plugins register “hooks” with these keys, they will be loaded first.

What do you think?

2 Likes