Open HR opened 11 years ago
Great idea, I was just thinking about that same issue. I just read this article about half an hour ago.
:+1:
I've just also created firetext.user namespace and a further nested firetext.user.log namespace for user change log that has its own properties
Another option is to use an AMD library like requirejs.
yup, we could
updated issue
We have solve all the errors so that further development (especially in Ui) is possible. And I think that one of the problem is really in the structure of some of our modules (need to always return object in every module so it can be used in others). And I think that we should move requirejs (all component) to the js folder ad it is a core component and set the baseURL to us folder where all core scripts/modules are. The examples even point to setting it up in the script folder (in example it is set to baseUrl: "js/lib")
Returning an object for modules also means that the firetext.js module there should be just the firetext object in which the method will be all the functions. In the API docs it is stated that "A module is different from a traditional script file in that it defines a well-scoped object that avoids polluting the global namespace" // Means returning object
And also the sequential execution should happen in main.js I believe
One of the biggest problems I've come across implementing this is that we have a lot of circular dependencies. For example, the firetext module depends on the io module, but the io module depends on some variables and functions declared in firetext. I'm trying to separate some of the firetext.js code into separate modules, so they can be used in both io.js and firetext.js.
You're right but we should have a proper namespace structure too sort out functionality and this would start from the firetext object. E.g in a case of client I'd generation method it would be firetext.user.ClientID.gen() , in case of an io operation there could be a sub io object in a open doc method like this firetext.io.openDoc(). What this mainly gives us manageability and accessibility of method and properties required thrift modules. And each sub module will be in separate js file.
firetext.SUBOBJECT.METHOD/PROPERTY
RequireJS is creating a ton of errors, and has slowed development to a crawl. Also, I don't really see how it is benefiting the project at all. Maybe we should re-think this.
Modularity is good, and we should keep the above namespacing system, but RequireJS is not necessary for that. Is it okay for me to get rid of RequireJS?
I think that we aren't implementing it rightfully. Take a look at the FxOS reference app's source codes that use requirejs
All available at: https://marketplace.firefox.com/developers/docs/reference_apps
The fact is that they are using much more JS libraries and frameworks than us and are still managing to build fully working apps.
We should implement it similarly to them
I got it =)
Opening because this may be something to reconsider. If we need to look at an example, paulrouget/firefox.html implements requireJS.
Update we have decided to solve this issue by using an ADM library in particular requirejs (requirejs.org) for encapsulation and to make the app more manageable (with modules).