One time imports

[chriseppstein]

We need a way to import library files just a single time. The @import statement is basically like ruby's load directive, but I think we need an import with ruby's require semantics (does nothing if it's been imported already).

What do you think about @depend?

[MarioRicalde]

This would be for performance, right?

I can think of this being useful on big packages that have one file that does lots of includes.

[chriseppstein]

Yes. performance is a big part, it allows each module to be used in isolation without a performance penalty. It also makes it easier to override mixins because they won't be re-parsed later if you define the override after the first time it's loaded.

[MarioRicalde]

I like that last part.. making overriding easier would be great.

[anthonyshort]

Definitely. This is something I've been seeing a need for lately as well. It would be super handy.

[chriseppstein]

Marked #156 as a duplicate of this issue.

[seanofw]

Copying my proposal from the other thread: I propose adding an @import-once directive that can be dropped into the imported file, as the first statement in that file. It takes no parameters:

@import-once;

This is a safer directive than the @import-vs-@require solution, since it ensures that the imported file can't be accidentally imported wrong; if it was designed to be imported only once, it can assert that itself, and a caller need not know its behavior to be able to use it correctly.

[seanofw]

Oh, the other thing in the other thread: If anybody needs it, I have a cute workaround involving adding a @function and an @if statement in the right places; it produces results that are very much like @import-once would produce. It's not perfect, but it does work. You can find my solution here: #156

[chriseppstein]

@seanofw Can you please provide the use case of a file that is "designed to be imported only once"?

[ZeeAgency]

+1 for @depend

[seanofw]

@chriseppstein: The best example I can give is a diamond-style dependency pattern, which occurs in larger software.

So let's say you have these four files in a big system that's been well-factored into small units:

• _DropDownMenu.scss
• _CarModelPicker.scss: @import "DropDownMenu";
• _ColorPicker.scss: @import "DropDownMenu";
• FindACarPage.scss: @import "CarModelPicker"; @import "ColorPicker";

So "DropDownMenu" has the stylings for general, shared dropdown menus that appear when somebody clicks a dropdown button. "CarModelPicker" is the layout for a frequently-reused blob of markup that, say, lets a user choose a car by its year and make and model, and that markup contains dropdown menus. "ColorPicker" is the layout for a frequently-reused blob of markup that lets a user choose a color, and that markup also contains dropdown menus. Finally, the "FindACar" page displays both a model-picker and a color-picker to let a user find a car.

See the problem? On the "FindACar" page, if you don't design "DropDownMenu" to be imported only once, you'll get the same dropdown-menu CSS generated twice --- two different places in the same resulting FindACar.css file. You don't need to use @Mixins or anything fancier than @import to demonstrate the problem.

In a large system where the CSS has been heavily sliced-and-diced like this --- like our flagship application with 1.2 million lines of code in it --- the @imports of a single page can end up both broad and deep. It's possible for the same page to unknowingly import, say, "_Links.scss" twenty times, because from the page's perspective, it's listing out its dependencies, and each of those dependencies are listing theirs, and so on until you get to a few base styles that nearly everybody needs.

For a small application, this isn't an issue anyone would notice; but for a big application like ours, avoiding redundant imports is absolutely critical.

[chriseppstein]

@seanofw I totally understand this pattern and complex structure. My own site is quite complex. but I don't understand why _DropDownMenu.scss should be the one to declare it's importing behavior instead of the caller.

[seanofw]

@chriseppstein: The answer is because of the potential for misuse. I work in a large software shop, and believe me, even among really smart, capable coders, if somebody can do it wrong, they will do it wrong.

By making _DropDownMenu.scss the one to declare "You can only import me once," you don't give anybody the option of screwing it up and importing it six times; you can't do it wrong even if you want to. But if _CarModelPicker.scss and _ColorPicker.scss are the ones that are responsible for saying, "Only import DropDownMenu once," that provides two points for failure instead of one: It's two different places where somebody can --- and will --- screw it up. And in a large system, two points for failure quickly become twenty, and those twenty quickly become two hundred.

Putting it inside _DropDownMenu.scss is a form of encapsulation, to use an OO term; _DropDownMenu.scss is then guarding itself against misuse.

Another thing to consider: Is there ever a scenario when it makes sense for a single .scss file to be able to both be imported many times by some callers and only once by others? Is there any scenario where that's sane, desirable behavior? If the answer is no (and I think it's no), then the system should guard against it, because that then must be an accident --- undesirable behavior --- if it happens.

[jacobrask]

Is depend used in any other language? Using require or import-once would make it familiar to developers from other languages, the latter being the most obvious and very unlikely for anyone to use by mistake.

[verekia]

This feature seems fundamental for having clean re-usable code in an architecture with inheritance. I wish I had it even for this very simple use case.

Plus, I agree with @jacobrask, and think require and import-once are particularly clear and intuitive.