I have a structure of over 20 modules that will have their components shared with each other.
Will I have to import all these components into the shared module? Is there a better structural organization?
Attention I know the concept of shared module. I would like to separate my components into modules and make them talk to each other.
Changed image for better understanding
You can have either one shared module or as many shared modules as you want depending on how much shared code you want to separate and how you want to split it.
Let's say you have two lazy modules that share one simple function in two lines. It's useless to create separated chunk for this function because it's better to load it in one single bundle once than having additional request.
On the other hand, if you thing that your initial startup bundle is too big and you know a big amount of code that can be moved to separated chunk, then just do it. Create another shared module that you will import only in two lazy modules which require it.
There is a great article on this top that will help you understand what it's going under the hood in Angular CLI code-splitting
Code-splitting in Angular or how to share components between lazy modules
Yes, it is a best practice to create a shared module for dependencies that are shared across all modules or you can create logically separated submodules and import them based on concrete needs.
https://github.com/fknop/angular-pipes?files=1 is a go to for me on making individual modules and combining many individual modules into a larger module. It handles pipes. But it is similar for components.
Customers and Users would be individual modules. And you would make a parent component that consumes both into CustomerUserComponent and facilitates communication between these subcomponents.
NGRX is a really good library built upon rx.js which helps handle communication in a queued fashion. Which becomes powerful when you combine async.
Related
This question is about possible higher-level approaches that one could take to applying version control to React components. Specifically, these components should be more on the "atomic" end of the spectrum, i.e. doing one thing powerfully in a variety of contexts.
Specifically, I'd like your thoughts on versioning such components at scale, whilst addressing issues such as:
Cross-project usability (i.e. <Button /> component in both of my React apps);
Theming (how themes and styles can be shared across these components); and
Dependencies (e.g. version 1.0.5 of <StackedButton /> depends on version 2.1.0 of <Button />)
I've been looking into Bitsrc.io as a possible tool to help me manage this. I've been largely addressing these issues by having quite a few (~10) Git repositories, each managing a loosely coupled set of components, e.g. text-components, layout-components, table-components, but I feel like I'm at a point, where with the number of components and the dependencies they have, further maintainability may be sacrificed if I make the wrong decision.
I've had some success using lerna; I think it might fit your needs pretty well. You basically would combine all 10 of your repositories in a single one, with each one now being a package within the repository.
Lot of advantages to this approach. Mainly, it lets you still have separate published packages, giving consuming apps flexibility on what they want/don't want to pull in, but it removes a lot of the overhead of having a lot of packages. It becomes much easier to make sweeping changes, and it's impossible for your packages to get out of sync, since they're always updated together. If you make a breaking change in one package that another package relies on, you would fix the package in the same PR as the breaking change.
Angular 4 uses some RxJS types in its public API as well as depends on RxJS internally.
Thinking further on this, it might be good to know if Angular uses other packages for parts of its run-time functionality, so we could use them as well. It might prevent us from introducing extra dependencies for the app by re-using them from Angular.
But looking into node_modules, every Angular 4 app contains a massive amount of packages. Obviously, most of them doesn't get included in the run-time app bundle. At the same time, some of them (like lodash) could be very desirable to use in your Angular app as well.
So, is Angular based on any other packages except RxJS and which of them could be used in our own code similar to RxJS?
Angular is pretty buffed up, meaning it already comes with predefined strategy on how you should accomplish things. I believe it's built on RxJS so you won't be able to get rid of it.
But you don't really have to use it. When you pack your app for production it will not include all of the node_modules packages, only the ones that were used.
If you want to use a JS library that's a lot less heavyweight, and comes less structured, look into react.js and vue.js
Although RxJS is certainly a big player in Angular's dependency pool, it's certainly not the only one, and not even the only one you'll need to depend on to use Angular.
Zone.js, for instance, is another key component in Angular's architecture that you'll need to depend on to use it. Although both libraries are used extensively in Angular, you are by no means mandated to use them – that being said, you'll get a lot more out of the framework if you understand Observables and Zones.
Other things you'll need to depend on are easily inspected in Angular-CLI's polyfills.js file; things like core.js that shim up Angular's ability to run on lower-common-denominator browsers (cough, IE). There's also multiple #angular/*-scoped modules you'll need for other pieces of the framework, such as forms and http.
My recommendation? Boot up a CLI project and see what ends up in the dependencies section of your package.json. RxJS and Zone.js are the big contenders, but you may be surprised by other names on the list.
I'm a familiar person with Angular Js, recently I've seen that in some projects multiple angular modules are created and assembled in main module.
The code looks like.
angular.module("main",['main.sub1','main.sub2','main.sub2'])
angular.module("main.sub1",[])
angular.module("main.sub2",[])
angular.module("main.sub3",[])
My questions are
When to approach such fashion of splitting modules ?
How it is useful ?
Does this affect routing[routeProvider/stateProvider] (since modules are defined differently can i place route provider or state provider for each separately)
If i inject a dependency in sub modules are they by default injected in main modules ?
I read few blogs but I'm not able to get a clear perception.
Can you please guide me through.
1.When to approach such fashion of splitting modules ?
Preferably, Always. But you don't really need to do it unless you have multiple apps that are using the exact same code, maybe the way you handle authentication in a few apps is identical, it would make sense to put the common code into a service and have that service as its own module. This offers code reuse, and we all know that code reuse is good.
2.How it is useful ?
Again, reusability is the key word here. You don't want to go around writing duplicate code. Code duplication is just plain wrong, and results in more expensive maintenance and more error prone code.
Another advantage is that modularising your applications explicitly outlines the dependencies of your application and separates the responsibilities of different parts of your app. Code reuse and separation of concerns are fundamental practices in writing maintainable code.
Another reason to separate your app into modules is performance. Right now I'm working on an app (web shop) which consists of 2 main sections: one section(app) for normal users/buyers/sellers, and another app for the admin. Now the users app needs some scripts/libraries the admin app doesn't, and vice versa. For example the admin app uses a kendo grid which requires a kendo.all.min.js script which when minified is 1.7MB! Now would it make sense to force all visitors to the site to download the heavy 1.7 MB script?
3.Does this affect routing[routeProvider/stateProvider] (since modules are defined differently can i place route provider or state provider
for each separately)
Yes. Ideally your applications will have different route/state configurations, so each app would have their own app.config(), this means you could define separate routes for each app using the shared modules. To my experience the main things you want to move into their own modules are services and directives, not applications routings.
4.If i inject a dependency in sub modules are they by default injected in main modules ?
Yes. If you inject a dependency X into a module A, and module A will be used by another module B then B will also inherit the dependency X.
A module is the kernel of functionality for Angular apps. Modules contain all of the code that we
write for our specific app and, thus, tend to grow huge in a monolithic way. Although this tendency
isn’t bad (modules are a great way to reduce global scope noise), we can divide our modules.
There are several differing opinions about when to create a module and when to nest functionality
in a global module. Both of the following methods are valid ways to break up our functionality by
modules:
1. When to approach such fashion of splitting modules ?
When you want to sepereate your app logic by functionality or by routes, is needed because as your code separated on modules, it easy to understand, to tests and etc. angular module system implementation of Module Pattern.
Modules are an integral piece of any robust application's architecture and typically help in keeping the units of code for a project both cleanly separated and organized.
2.How it is useful ?
For starters, it's a lot cleaner for developers coming from an object-oriented background than the idea of true encapsulation, at least from a JavaScript perspective.
Your significant other is the new developer on the team who's been asked to fix a bug on one of the many screens in your app.
The developer sifts through the directory structure and sees all the controllers, models and services neatly organized. Unfortunately it tells him/her nothing about which objects are related or have dependencies on one another.
If at some point the developer wants to reuse some of the code, they need to collect files from a bunch of different folders and will invariably forget code from another folder somewhere else.
3.Does this affect routing[routeProvider/stateProvider] (since modules are defined differently can i place route provider or state provider for each separately)
Another method we can use to break up our app is to divide our modules by route. This breakdown
allows us to write isolated tests that focus on the functionality per route. Modularizing by route can
make more sense, depending upon the project; it allows us to divide our functionality efficiently
when we’re dealing with a lot of independent routes.
For instance:
angular.module('myApp.home', []);
angular.module('myApp.login', []);
angular.module('myApp.account', []);
angular.module('myApp', [
'myApp.home',
'myApp.login',
'myApp.account'
]);
This modularization makes sense specifically when we’re dealing with large numbers of routes
and/or when we don’t have too much cross-over between routes
4.If i inject a dependency in sub modules are they by default injected in main modules ?
shortly: yes. :)
Could anyone explain me what is the pourpuse of create new modules in angularjs application, I have already read the documentation, but we are not quite sure about when is appropiate to create a new module or use our own application module when you create a new service, directive, etc..
I would like to add some thoughts after reading a bit more about the subject:
JAndy, you are right in the general concept, but to be more specific in when do you have to use angularjs modules I think I got a clear answer in this post
Basically we have 3 ways of structuring our angularjs projects:
angular-seed
Yeoman
Structure the project in Modules
Depending of how big is your project you can take one aproach or another.
Basically writing new modules in angularjs helps you to pack functionalities that are related, one of the advantages of this approach is if a new developer comes into your team he can get a general overview and find things easier than if you only have one module, another one is to reuse functionality accross other projects.
I'd like to answer this question in a more general style than being specific.
Why was the ISS not build as one gigantic station instead of multiple independent modules ? The reason behind modules is to separate responsibilities, decouple a construction, etc. In terms of programming it means to have logic, spread over multiple small modules. That way, you not only know exactly where to look if anything goes wrong or you need to extend some functionality, it'll also guarantee that your whole ISS( your application ) will not entirely fail if one of your modules fails. This of course, also requires certain aspects of
programming styles, most important in this context, to hold module interaction and communication loosely coupled (which I just assume).
So whenever you want to implement new stuff, which does not fit in any other existent code or module, you should create a new, independent module, which is specialized to fulfill a certain task.
Even if I'm not using AngularJS on regular bases, I'm sure the same idea of modularization will fit in there.
The JavaScript in my web application has grown into one huge file. I want to break it up into modules so it's easier to manage.
I don't know if there are any established best practices for anatomizing the codebase of a web application, or if it just varies too much from project to project?
In particular:
should each module be responsible for an app-wide concept, such as "layout", or "clientside storage", etc?
or should modules be for concepts specific to the app being built (like "comments" or "calendar"), and each module be responsible for managing its own layout, its own clientside storage, etc?
or a mixture of both?
If you take Separation of Concerns and Single Responsibility into account then each module/component etc. should be responsible for doing what it does and nothing else. Break down your modules by re factoring into small, easy to manage chunks that do it's job and nothing else.
In terms of your JS application you could take a look at some client side MVC frameworks (such as knockout, sproutcore, spine etc. to name but a few) these frameworks help to logically separate out views and layouts to controllers and models. You might also be interested in using something like require.js to load your modules as and when they are needed.
There is a very good book by Alex McCaw which is worth a read.
MVC is just one pattern, but it is a very popular pattern and addresses some of the concerns you have.
Best of luck.
All things being equal, you are better to create your modules around concepts specific to the app. This is more object oriented, and tends to group together code that is more likely to change together. This in turn makes your code easier to understand, more tolerant of change, easier to develop and extend (the benefits of "modularity").