How to tell when less is done processing ?

[agersant]

Hi.

I'm working with jQuery and I'm used to running javascript code as soon as the DOM is ready. The funny bit is that my js is performing operations which involve reading some DOM elements' css attributes. However, it turns out the js may or may not run after Less has done his job.
The consequence is that oftentimes, my js will read values before they are set - thus leading to unexpected behaviors.

My question is simple : is there a way (event, flag...anything) to tell when the less processing is complete and execute JS code after ?

[ttfkam]

Sounds like a good idea.

[harobed]

Good idea !

[rulatir]

Upvoted!

[rulatir]

This is really, really, really BADLY needed in order to be able to avoid FOUC!

[lukeapage]

it is not recommended to run less.js in the browser in production.

for development set a timeout for x milliseconds.. wouldnt that be good enough?

[rulatir]

it is not recommended to run less.js in the browser in production.

Why not, and what is recommended instead if one does rely on
javascript()? Also, isn't the unavailability of processing completion
notification one of the reasons why it is not recommended,
circular-logically?

Szczepan Hołyszewski

[lukeapage]

Its not recommended because its bad for performance and only runs correctly on a small set of (modern) browsers. You are right that there are also several bugs that make it more difficult.

Instead, compile the less before hand in node - This support javascript - unless you are accessing variables on the page? In which case it depends on your serverside setup and what variables you use, but it might be better to try and move that serverside.

There are cases where it makes sense to use less.js browser side - for instance in a theme editor where a admin user is editing things on the fly.. but then for more generic users it would be better to compile and cache serverside.

So it does depend on your situation and I'm not saying this feature request will never get added, just that it is low priority.

[velosipedist]

Why not to just add stylesheet node DOM event firing& It is very easy to implement and will not hit the performance.

But it wil allow to catch stylesheet refreshing (especially important in watch mode) for any purposes.

For example, i'm writing ajax-based Less stylesheets updater, cause im'not able to install Node.js on hosting.
Just want to have ability to update stylesheet changes without any offline compilers, right with latest less.js version.

[roelvanduijnhoven]

My use-case IS an theme editor, and so I would find this highly useful!

[lukeapage]

@roelvanduijnhoven happy to accept pull requests

[roelvanduijnhoven]

Maybe I will look into this.

The way I fix this at the moment is to poll every few miliseconds until a specific css style has been loaded on a DOM element. Although this works in practise this is 1) a nasty hack and 2) can break in theory because not all styles could have been loaded at that moment in time.

[cphill02]

It would be very nice and pretty standard to have a callback function for after LESS is done processing.

[lukeapage]

I agree. That is why it is labeled ReadyForImplementation and has a milestone of the next release.. it is just waiting for someone to implement..

[akashivskyy]

👍

[levithomason]

I'd like to jump in on this. Is any one working on this yet? I've browsed the PRs and didn't see it. I also didn't see it on the 2.0.0 release checklist #1902.

@lukeapage do you know if there is somewhere I can contribute to this feature or if I need to start it from scratch? Thanks!

[lukeapage]

Hi,

Good news, thanks. 1. Branch from the v2 branch. 2. Consider we want to
make the browser code more flexible and not just add stuff in. That being
said, this needs a new less thing.

How about a promise on the less object which is resolved after the initial
scan?
Look in less-browser/index.js
We use a promise polyfill already in v2... See render.js or file manager.

Long term (not necessary for your pull request) we can make refresh return
a promise and just set less.xxx to be that promise for the first scan..

Open to discuss alternatives, am sketching this out from a mobile phone...

[levithomason]

Awesome. Being there is room for jumping in I'm gonna branch v2, grokk the issue and your comments better, and come back with some ideas. Looks like there have been a few changes since I last perused the source 1.7.0 ;)

That being said, this needs a new less thing.

Not sure what is meant by 'thing' here though.

[lukeapage]

That being said, this needs a new less thing.
Not sure what is meant by 'thing' here though.

Sorry I know it wasn't clear - I mean that its easy to keep adding events and options to less - I'd rather refactor what we have to make it able to be used in a more flexible way than to keep adding options.

And I'm saying that exposing an extra field (the thing :)) on the less object is necessary for this and not too bad if we consider further improvements.

[levithomason]

Moving conversation on solutions to PR #2226.

[lukeapage]

released in v2 beta 2