clux / modul8

NO LONGER MAINTAINED - browserify is too similar and is better (see issues)
http://clux.github.com/modul8
MIT License
22 stars 4 forks source link

domloader explanation #13

Closed panosru closed 12 years ago

panosru commented 12 years ago

Hi, could you explain me a bit more the domloader setting? I'm not sure if I get it from what I read from docs so far.

For instance I understood that if I don't set domloader then the output code that produced by compiler will executed by the time it will loaded to the browser, but if I set domloader to use a method like $(document).ready so we will end up with this: .set('domloader', '$(document).ready') then the output code will be wrapped in order to be executed when our domloader function is triggered, so when $(document).ready is invoked then our compiled code will be executed.

I can't get the value of this, if you could provide me with couple of use cases I would greatly appreciate it.

Also to mention that what if we want part of our code to be immediately executed when file is loaded and other part of my script to be triggered on different events, some on window load others on document load etc, then would be considered as best practice to leave the domloader setting unset and instead call those event methods inside our code as we would do normally in any other case?

Thank you for your time :)

clux commented 12 years ago

If your app code relies on the DOM (i.e. wants to change anything on it), it needs to wait for the DOMContentLoaded event in a way that you prefer (say jQuery's $(document).ready). Otherwise your code with $('selector').click(function(){}); calls would fail.

If your app code is DOM agnostic, i.e. you wrap individual pieces of your app code yourself, or the code simply outputs stuff to console.log, then you don't have to nor should you set it. Leaving it blank simply means everything is wrapped inside (function(){ code }());

Any code from non-app domains don't get this safety wrapper.

If you want to wait for different events, you can choose to not use this option and wait manually for them in your scripts as you say. Alternatively, you could wait for only window event inside your code, and let the app wait for DOMContentLoaded using domloader()

Hope this answers your question.

panosru commented 12 years ago

@clux thanks for reply! :)

If your app is both dom agnostic and dom dependant then what do you suggest? What I'm currently doing is not set domloader and in my app I have something like this:

#some code here which does not relies on dom...

$(document).ready ->
    #some code here that relies on dom ready event

$(window).load ->
    #some code here that relies on window load event (which does not mean that the dom is ready...)
clux commented 12 years ago

@panosru Ah, you are here. Sorry I updated my reply a bit.

If parts of your code doesnt rely on the dom you should factor it into separate modules somehow. Make it an npm module or put it on a shared domain. It's good practice to try to avoid jQuery spaghetti code where everything is in one place. There's an .md on modularity in the docs. Might be worth a read if you haven't already : )

panosru commented 12 years ago

@clux yeah I'm always here :P

Thank you ;) your reply covers my question :)