Last 12 weeks · 0 commits
1 of 6 standards met
Hi, this is more of a question than issue but can anyone explain why you might want to create errorNotice as a private variable in the first version of this module versus as a property on the instance in the second version? It seems in the first version you have to clean up the private variable whereas in the second version it will be removed when the instance is destroyed. Thanks!
More of a question than a concern as I've been trying to learn more about JavaScript from your example. In app.core the define function creates a var called 'temp' and runs the constructor. I don't understand why app.f.define is passed in as a parameter when the following check will work without it. temp = constructor(); if (temp.init && app.utils.typeEqual(temp.init, 'function') && temp.destroy && app.utils.typeEqual(temp.destroy, 'function')) { // Works just the same. } Perhaps I am not understanding the bigger picture here. Is this simply a matter of good practice? Any help appreciated!
I want to mention some things related application structure because I tend to disagree on some topics. First of all I try to figure out what I'm missing here... is there any reason why you placed facade under sandbox path? I believe the right way should be to have 2nd facade under sandbox and main facade outside of sandbox the reason behind this is when the application is in production it will load the facade outside of sandbox when the application is in development/testing/integration env it will load the facade inside sandbox which will extend/override the facade outside sandbox. Sandbox facade will work as a temporary container for testing/development purposes once it is tested then the code could move to main facade. Regarding libs, I believe libs folder should host application's libraries like facade, mediator etc jquery and dojo are 3rd party libs more like vendors and I believe they should be placed in vendors path instead of libs application_core is a bit missleading, I don't really understand from first glance what exacly is the "core" there that it is "more core" than libs for example or utils, core gives higher priority on that path which is something that I believe shouldn't happen in this case. The files inside that path are more like invokers or wrappers if you want... I believe they should be part of the libs folder, same exist for utils, this too should be part of the libs folder. currently the structure look like this: The above structure really gives me the feel of "what is where, wha tis the purpose of everything here?". I would propose the following structure as more clean in my personal opinion.
Repository: addyosmani/largescale-demo. Description: Scalable JS architecture demo for #jqcon Stars: 137, Forks: 23. Primary language: JavaScript. Languages: JavaScript (59.8%), CSS (40.2%). Open PRs: 0, open issues: 3. Last activity: 11y ago. Community health: 28%. Top contributors: addyosmani, AdrianHastro.