Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Variables for imports... #3142

Closed
FireyFly89 opened this issue Dec 13, 2017 · 5 comments
Closed

Variables for imports... #3142

FireyFly89 opened this issue Dec 13, 2017 · 5 comments

Comments

@FireyFly89
Copy link

FireyFly89 commented Dec 13, 2017

Hi there, yes I know this is an old subject, since I spent my last 2 days reading up on this... So... Dynamic importing... Yes I understand most of the concept why it isn't implemented in any way, however I cannot find a solution to my problem, could you perhaps find me an alternative, because dynamic importing does seem to be the only possible situation for this one...

Let me try and explain, the problem is the following:

We have a wordpress site, that has lots of microsites... Now all the microsites use one main file to import all the stuffs in that is absolutely needed, BUT might want to bash in an extra import to one of the import section.

Let's visually try to see this...

@import "variables";

// I'd like to overwrite some of my variables here, since I want them overwritten in components already, because they might use the variables (using file imports)

@import "components";

// I'd like to overwrite some of my components code here, since I want them used in layouts. (using file imports)

@import "layouts";

// I'd like to overwrite some of my layouts code here... etc etc. (using file imports)

@import "pages";

@import "general";

(for main site) My structure is the following: Shellscript -> base imports only
(for microsites) My structure is the following: Shellscript -> microsite less + base imports

In the less file of my microsite, I need to determine what files I'd like to import at what blocks, so I can overwrite anything when necessary.

I may have not been clear enough, please tell me if it is not understandable.

Could anyone help me find a solution to this please? This is completely killing me right now :D

UPDATE

Alright, one misunderstanding I had... Putting the mixins imports and all the stuff aside, even if I define a variable as the very last AFTER all the imports, that certain variable is overwritten even if I use the variable in the first imported file. Which is... okay I guess.. if it is "global" and not "scoped" as it is not in a mixin, it gets read before the imports I guess and if the var name is the same, it simply gets overwritten.

@seven-phases-max
Copy link
Member

seven-phases-max commented Dec 13, 2017

Less variables are lazy-evaluated. Thus you never have to define or overwrite variables before anything that can use them:

@import "anything";
@foo: bar; // will affect any @foo of the same scope in "anything" 

See links at #2442 (comment) for more details. I.e. rethink your approach from scratch as currently it's just wrong from the very beginning.

@FireyFly89
Copy link
Author

I did come up with another solution, however this only enables me to import one file per section. Of course this does not give me complete control over things (but I don't really need it anymore), but as an example:
(lets say this file's name is: base)

@helpers-import: 'dummy';
@bases-import: 'dummy';
@layouts-import: 'dummy';
@components-import: 'dummy';
@pages-import: 'dummy';
@overwriter-import: 'dummy';

@import "helpers/variables";

.importer() when not (@helpers-import = 'dummy') {
@import "@{helpers-import}";
}

@import "base/typography";

.importer() when not (@bases-import = 'dummy') {
@import "@{bases-import}";
}

@import "layout/header";

.importer() when not (@layouts-import = 'dummy') {
@import "@{layouts-import}";
}

@import "components/buttons";

.importer() when not (@components-import = 'dummy') {
@import "@{components-import}";
}

@import "pages/post";

.importer() when not (@pages-import = 'dummy') {
@import "@{pages-import}";
}

@import "base/general";

.importer() when not (@overwriter-import = 'dummy') {
@import "@{overwriter-import}";
}

.importer();

However this does not enable me to import multiple files when needed, but then after I've figured out I don't really need this load order, as you've said above, it's alright I guess...

By the way, how come the @import needs an existing file, even if the mixin guard doesn't evaluate to true? I cannot make the variables empty, or it'll say the file manager cant find the file '.less'. possible bug?

@FireyFly89
Copy link
Author

FireyFly89 commented Dec 13, 2017

Ooookay, so I've just realized... if I do this:

@overwriter-import: 'dummy';

.importer() when not (@overwriter-import = 'dummy') {
@import "@{overwriter-import}";
}

.importer();

@overwriter-import: 'somethingelse';

It will evaluate to somethingelse, thus importing the variable, however at the moment of import, the value is still "dummy"... but doesn't throw error on trying to improt an empty file, just simply not importing it? or am I missing something?

UPDATE

It doesn't throw an error, because the "dummy" what I used as default value is an existing file... but why does it evaluate the variable to not be dummy, but when importing it actually has that value?

@seven-phases-max
Copy link
Member

seven-phases-max commented Feb 23, 2018

Please use backticks to format your code.

For your last example, note that imports within mixins are resolved when you define the mixin - not when you invoke it... That is:

@overwriter-import: 'dummy';
.mixin() when (whatever) {
    @import "@{overwriter-import}";
}

is exact equivalent of:

.mixin() when (whatever) {
    <inject the contents of the "dummy" file here>
}

Hence the error when the "dummy" does not exist.
Guards are evaluated when you invoke the mixin (thus your .importer() has no effect since its guard results in false).


For the particular example you may put (optional) flag (so it will suppress the error for not existing "dummy"). But note that variables defined within mixin (inc. variables within files imported within that mixin) won't override any variables defined in the scope where you expose that mixin... I.e. if you go that way (doing imports via mixins) you're going to face even more tricky problems.

For more details see #2772 (also see comments after #1400 (comment) etc. - there's no universal recipe).

@seven-phases-max
Copy link
Member

seven-phases-max commented Feb 23, 2018

Closing as a question (and not an issue).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants