Example tools

[Kiarokh]

fix https://github.com/jgroth/kompendium/issues/114 fix https://github.com/Lundalogik/crm-feature/issues/3170

check this out in Lime Elements: https://github.com/Lundalogik/lime-elements/pull/2077

[jgroth]

I've been thinking a bit about these components and how to handle them. They might solve a problem I did not intend Kompendium to solve when I first created it so perhaps they should live somewhere else. My reasoning is that when you write your documentation and the example components, you can do so without having to worry about how they are going to be used at all. They are not dependent on Kompendium, since Kompendium is just a wrapper application that renders the documentation and examples in a special way. If the examples themselves rely on Kompendium (which they will do if they start using components from it), it will be harder to move the documentation to another tool in the future if that need arises.

I'm not going to block this from being merged, just want to hear your thoughts on the matter before we decide how to do it :slightly_smiling_face:

[Kiarokh]

I think you guys can decide :) I'm OK if you want to remove them. But on a philosophical level, I think it wouldn't hurt if the library could offer tools that are good and useful for the showcased examples.

[adrianschmidt]

If the examples themselves rely on Kompendium (which they will do if they start using components from it), it will be harder to move the documentation to another tool in the future if that need arises.

I think that's a very good point 👍

I think they can live as copies in elements and building-blocks for now, and if we ever add enough style to them to warrant DRY-ing them up, we can create a new repo for them…

[Kiarokh]

can't we have them as @private components in Lime Elements so that we can reuse them in Building Blocks with ease instead? That repo has a dependency on Elements already. right?

[jgroth]

can't we have them as @private components in Lime Elements so that we can reuse them in Building Blocks with ease instead? That repo has a dependency on Elements already. right?

Yeah that would also work

[adrianschmidt]

can't we have them as @private components in Lime Elements so that we can reuse them in Building Blocks with ease instead? That repo has a dependency on Elements already. right?

Yeah that would also work

We don't want to bundle too much non-production stuff with the production package, but since they're so small, it probably wouldn't make much of a difference. What's a little problematic with that approach is that the more advanced they become—the more styling and functionality we put into these components—the more reason we will have for not wanting to duplicate the code, but simultaneously, the more reason we will have for not wanting that code to be part of the production package…

On the other hand… albeit niche, perhaps they could be useful to certain consumers in certain cases, and we could include them as actual public components of Lime Elements…? 🤔

Let's start by including them in the production package, as private components 👍

[jgroth]

We don't want to bundle too much non-production stuff with the production package, but since they're so small, it probably wouldn't make much of a difference.

If you have performance concerns, all components are lazy loaded so they would not be loaded in a production environment unless they are used.

[Kiarokh]

we decided not to do this.