As we go along with features export, its being a mess. What I have been doing so far is every module with have another module that contains the feature exports. Let say their is module 'test' and it has some variable settings and I exported it via features. I will have another module name 'test_features_export' or something like that which contains the component associated with that module. But in some cases, the component can be too generic like 'role' which can be associated with multiple modules. Then its issue to bind to any specific features where it is meaningful.
So my question is , is there any better way to organize the features exports modules ??
Store completed feature in feature-module but not only settings or only variables or only permissions.
Use dependencies in feature-module to build more complex features.
Take a look at https://drupal.org/project/apps. It's an upper level to features.
Related
So I have encountered a practice where people will create a module for each component that has service dependencies. that way, when someone wants to use a given component, they dont have to read through the code to see what providers to add to the given module. is this an antipattern? will it cause performance issues or something?
Is there some recommended guidelines on lower/upper limits on how many components/directives/providers/etc should be in a given module? has there been testing of the angular/angularJs ecosystems with 100s of modules on a view? in comparison with if just regular components were all bundled in maybe like 20ish modules instead?
Generally, there are different module types in Angular and guidance as to what they should contain and what modules should import them:
Widget modules - Contains mostly UI components, but no services. Imported by Feature modules.
Features modules - Contains domain-specific private components. Imported by AppModule.
Service modules - Contains services exclusively. Imported by AppModule.
Routed modules - A specialized Feature module, that is the target of routing.
Routing modules - Contains navigation routes and resolver/guard services.
Modules can have dependencies on other modules. For example, a Widgets module could be expected to be used with a Services module, where AppModule imports the ServicesModule, and FeatureModule imports the WidgetsModule. The BrowserModule/CommonModule is an example of this pattern; so is RouterModule.forRoot()/RouterModule.forChild().
I would say its overkill to have one module per component. It would be hard to organize and group common functionality together and leverage services in any meaningful way. It could easily become unwieldy when your imports for a single module run into double-digits.
[Edit]
After re-reading this question, I would like to add a clarification because I think the one-component approach with NgModule encapsulation deserves more attention. I don’t believe in 1:1 module-to-component - that would be overkill. However, I am in full support of 1:many module-to-component where the module exports only one component, and all the other components are private to the module. This latter approach is known as NgModule encapsulation, and it is an excellent way to build your application in a way that loosely couples your top-level components.
If you have a relatively small app then bloating a single module is ok. Once your app starts to get relatively large then it makes sense to start lazy loading modules so your users don't have to download the entire build on app start. Grouping related functionality into modules makes things easier to maintain as well.
So for a smallish site, a single module will be fine but as your app grows it makes sense to start refactoring components and services into modules.
Practically, angular always prefer you to have basic module -
Features module, Shared module, Routing module, Core module,
But if application is big it is better to have lazy loading for modules, to have module for every component is best option, which increase app speed along with this browser load that component which is required.
I'm new to using Flow js, and find myself creating a lot of custom type aliases for the different API call responses and other functions. Currently I keep the type alias in the same file where I need it, and export it if I need it elsewhere in the program. But, I'm quickly finding this to become unwieldy / messy. Is there a certain recommended structure of how to organize all of the type aliases?
Thanks.
You can use flow-typed directory to define global types and modules like explained in documentation. Other way would be to make some index file on top of some folder structure where you would export all related to this directory types. In my project I have global redux types declared in flow-typed directory and other types exported from commons directory.
I'm trying to set up a large angular web app, with an architecture as described here
What I can't get my head around is how to make modules completely independent from other modules. All github boilerplate's or example projects which focus on modules all seem to have modules which heavily depend on common modules or functions/services. That would sort of defy the purpose of keeping everything separate doesn't it?
Take the following two example:
I have a utilities module which handles some basic functions (hashes etc.), and another module which handles all communication with an API. Imagine a User module which needs to make hashes and communicate with the API, how do I handle that? Directly injecting the Util and API modules as dependencies would break the in dependability, and putting them into the User module as well would mean a lot of double code (imagine multiple modules using the Util and API modules). Or should I use the mediator to mediate the communication?
User information which is stores in the User module is something that should be used almost application wide, and in the facade as well for example (the facade should handle security according to the article). How can I allow all of the application to access the information, without everything being dependent?
Thanks in advance :)
I answered a similar question here.
You are on the right track with separating behaviors into modules.
The idea is to embrace Dependency Injection as a means of collecting these behaviors into a rolled up module. With an IoC container at your disposal you can exercise discipline in your naming and other conventions to keep your app loosely coupled through configurable components.
We have a general app type module that simply registers the appropriate feature modules. That is in turn bootstrapped by a boot module that simply calls angular.bootstrap(['app']) somewhere (ours is in the page).
We can easily decorate or replace existing services/controllers/whatever with this setup and teams can work in isolation while features scale at different rates.
For example:
var myWidget = angular.module('myWidget',[])
myWidget.directive('myWidget',function(){...})
myWidget.factory('somethingImportant',function(){...})
var myDomainModel = angular.module('myDomain',[])
myDomainModel.factory('someModel',function(){...})
... //more models
var app = angular.module('app',['myWidget','myDomain'])
app.factory('applicationWidePolicyHere',function(){...})
//on index.html; das boot.
(function(){ angular.bootstrap(document,['app']) })()
I've been struggling trying to strike the right balance between reusability and complexity when it comes to organizing my Backbone objects into AMD's (for medium- to large-scale applications)
(A) Should every Backbone object (models, views, etc) be in their own module?
(B) Should related Backbone objects be in the same AMD module? (ie: PersonModel, PersonCollection, PersonView objects in the same module definition)
Option (A) seems to allow the most flexibility and reusability, but also the most complexity because of the (potentially) high number of files. While option (B) may make it easier to manage things, but less flexible and really difficult to unit test.
How is (or has) everyone else structured these things?
I good thing about requirejs is that it allow you to abstract the physical files into structured namespaces. You can take the approach (A) and create each backbone class in their own file, then create a "namespace" module to glue all the related classes together.
// Suppose you have PersonView.js, PersonCollectionjs, PersonModel.js as modules
// create a Person module to function as namespace
define(["PersonModel", "PersonCollection", "PersonView"], function(model, collection, view) {
return {
Model: model,
Collection: collection,
View: view
};
});
This keep the modules organized in their own files and gives you some flexibility to write one module per class without requiring you to expose this organization for the rest of the application (I really don't like to have to write require("PersonView", "PersonModel" ... ) every time I need to use the person's objects, it's easier and cleaner for consumers to declare a dependency on a "namespace" instead of independent classes).
For medium to large backbone projects I prefer to use requirejs with a separate module for every model, collection, and view. I also use the "Text" plugin for requirejs so I can load underscore templates just as I would any other module. This for me seems to be the sanest way to manage a large project and I have never really felt overwhelmed with the number of files I have.
+1 on using the requirejs optimizer when pushing your app to production. Works really well.
http://requirejs.org/docs/optimization.html
I just released an open source toolkit which will hopefully help others as much as it helps me. It is a composition of many open source tools which gives you a working requirejs backbone app out of the box.
It provides single commands to run: dev web server, jasmine single browser test runner, jasmine js-test-driver multi browser test runner, and concatenization/minification for JavaScript and CSS. It also outputs an unminified version of your app for production debugging, precompiles your handlebar templates, and supports internationalization.
No setup is required. It just works.
http://github.com/davidjnelson...
I have been working on C-based Native Client module for Google Chrome. Many of the module functions that are called by the NaCl system have a parameter of PP_Instance which uniquely identifies the module instance.
My question: Is there any way to associate user data with this instance handle?
The C API specifies that it is an opaque handle. It provides no functions for linking user data to the handle. Right now, I have to use a bunch of global variables within the module to share state among the functions. It doesn't feel like the right solution. I'm not sure if more than one instance will ever share the process space but I'm not making any assumptions here.
I suppose I could implement some sort of look up table to map instances to unique contexts that happen to live in the global scope. But that also seems like it should be unnecessary for a C-based API. The C++ API avoids this by virtue of its classes.
PP_Instance should be used as a key to lookup state / object associated with the plugin instance. More than one plugin instance may be instantiated in a module as per the API, when, for example, multiple embed tags are present in the containing frame. Currently the NaCl implementation of Pepper does not do this -- instead, multiple processes each containing a single module each instantiating a single pepper plugin instance is created. However, this is an implementation detail (or maybe bug?) that is subject to change, and it would be better to defensively program and be able to handle multiple DidCreate events.
Of course, if your NaCl module is guaranteed to never be used by anyone else and you know you won't ever have two embeds of the same module, then it might be okay to assume singleton instance and use global state, but doing things the "right" way isn't that hard, so why not?
See native-client-discuss thread for more discussion on this topic.