Tips and Tricks - library initialization pattern

[SomMeri]

How to create sort of objective oriented libraries by combining return variables and mixin sees caller thing. (issue is still under discussion) less/less.js#2767 (comment)

[seven-phases-max]

Ouch! This is actually quite narrow pattern trying to eat much wider name. Notice there're other forms of OO (infinity actually - the only limit here is "how we define Object"). So while it's nothing wrong of Matthew to use whatever names he want, we should not really assign such loud name to any particular snippet/design-pattern at "official" Less repos. Please :)

[matthew-dean]

Yeah... I'm not trying to be at the center of any controversy, and up to this point, I've posted all example code that related to other code by editing out the repo where it came from and using generic names, for the very reason that I want no one to infer that a Less library or Less-related project I'm working on is more legitimate than made by anyone else. The reason I did in that case is because there was a question of how such a pattern of inheriting vars and returning them into a scope via mixins could ever be valid, and this was essentially the central design element of the Granola library.

As far as "OOLESS", what I meant by that is that assets and properties are essentially assigned to Less mixins and detached rulesets, instead of CSS classes. In Granola, CSS class names are an abstraction away from the actual styles, which is different from most (if not all) other style libraries, which use a CSS class as the "base unit" of styles. Mostly that's because style authors think in terms of CSS, and think of Less as augmenting their hard-coded styles. An OOLESS pattern (as I've decided to name it, which is not an official endorsement by the Less org) instead organizes styles in a way that CSS cannot, inheriting size, shape, and color properties from different asset plugins, and then, as a last step, assigning that to a CSS class.

What that means is that an OOLESS pattern library can generate it's own class names, or it could generate class names that correspond to, say, Bootstrap, or maybe Pure or Compass or some other library. The style-to-css-class is not a one-to-one relationship.

Of course, all of this is rather experimental and still in the realm of theory, as Granola has been a WIP side project of mine for over a year. I do hope to use it as a case study to demonstrate that a CSS pre-processor can actually enable you to reason about styles in a different way than CSS (and that different Less libraries can actually reason about styles in very different ways), rather than just thinking of Less as "CSS with variables".

So, should any of that be in the docs? No. If/when I finish, I'll put a pull request to the Less library page like everybody else. If there are small gists I can put in Tips & Tricks, I'll see about doing that too.

[SomMeri]

I just wanted not to forget about the library initialization trick. I have seen similar tricks in issue tracker before, thought that it would be cool to put it somewhere into tips&tricks, did not wrote it down and then forgot.

[seven-phases-max]

👍

[matthew-dean]

@SomMeri Are you talking about the way I have it so that @import doesn't output anything, and .make() is what actually "runs" everything after you have it configured? That trick?

[SomMeri]

@matthew-dean I meant just this part:

& {
        // Import vars into an isolated scope (don't leak)
    #granola();
    #vars();
    #granola._make(@defaults, @all, @type, @layout, @forms, @nav, @buttons, @icons, @tables, @panels);
 }

(Note to self: and other variants later in discussion).

I haven't think of such initialization before. Overall goal is to collect small ideas like this and once there is enough of them create tips&trics page - so that each new user does not have to reinvent them.

[matthew-dean]

@SomMeri Oh, okay, that doesn't really have anything to do with (what I'm calling) OOLESS, so much as a hack to create namespaced vars.... Which probably is a good thing to highlight.