I use the application component segmentation logic when creating my angular application, which is to say I have the following folder structure:
app.module.js
app.config.js
components
---- core
-------- core.module.js
-------- etc...
---- component1
-------- component1.module.js
-------- etc...
---- component2
-------- component2.module.js
-------- etc...
---- etc...
shared
---- sharedComponent1
-------- etc...
---- etc...
assets
Now, I group all my components into my app.module.js file and that's pretty much all that file is there for. My component1.module.js will list dependencies that module requires and so on. Now, I realize that it sort of doesn't matter where I define module dependencies and that I can put all my dependant module, regardless of component in the app.module.js file, but that's simply not clean nor does it offer good modularity.
That being said, I'm not sure what to do with modules that are used in every, or almost every other module, like modules for localization for example. The real problem here isn't that the whole app uses that module, it's that that universal module needs to be configured, so I was thinking about putting that dependency, and the required configuration, in the core.module.js and core.config.js file, respectively.
I've read a lot about angular best practices, but I wasn't able to find something concerning module dependency organization which, I suppose, is because angular puts all the modules in a "big box" anyway.
Another approach would be to create a shared component that focuses on incorporating that particular dependency, or group of dependencies into angular, and then have my other components depend on that component, but I'm not sure if this is too much.
I structure my modules as follows. The only real difference between my structure and yours is that all core/shared are basically the same thing. I have a component folder for each individual module of the application. Anything that isn't part of an individual component goes in core. The things that almost every single component use go in core too, as they are then a core piece of your application.
In my opinion, as long as you are breaking the application into components/angular.modules, keeping core code separate, and the organization is clear and easy to understand, its perfectly acceptable
core
----app
--------app.module.js
--------app.config.js
----util
--------util.module.js
components
----comp1
--------comp1.module.js
--------comp1.etc
----comp2
--------comp2.module.js
Related
How should I structure my Vue CLI project? I am unable to find any proper documentation regarding this.
Basically I have around 10 modules and each module has a js file associated with it.
Currently, I am putting all the pages written in my router.js in views directory and all the components in the components directory. I want to know where should I keep mine js files?
All the js api calls associated with every module
JS files containing all the constants related to every module??
Q1: Usually API calls are stored under a respective store if you are using Vuex. If not you can use define them as mixins and use where necessary. The mixins are the parts of the javascript code that are reused in different components. In a mixin you can put any component’s methods from Vue.js they will be merged with the ones of the component that uses it.
Q2: This can definitely go under mixins.
You can also have a util folder (optional) where it contains the functions that you use in components, such as regex value testing, constants, or filters.
Refer to this boilerplate if your project is mid-scale or large-scale.
create a service folder,create service.js -api call goes here(now all you need is to call it when ever you need it)
you have a store folder with store.js(index.js) inside store folder create modules folder
with you modules. inside store.js create modules:[user,event...]
basically that's it. edit your modules files event.js user.js.
you can add getters,mutations,state,actions. just dont forget export const namespaced = true so it`ll go to the global namespace
When I run ng build project1 --prod the build fails with the error message
ERROR in : Cannot determine the module for class MyComponent in .../project2/app/my.component.ts! Add MyComponent to the NgModule to fix it..
This seems pretty straight forward, BUT the mentioned Component is not part of the current Angular project. I defined two projects inside my angular.json and they are not dependent of each other (project1 & project2). I've got a separate shared module which both projects import and use.
The error appeared when I moved a component from project2 to my shared module. My project2 builds fine and the moved components also work fine. ng serve project1 works without problems. But for some reason, my first project now depends on most components from my second project for no reason. I already searched all my imports for the file without success. Maybe it's related to the fact that the components from project2 extend a component from the shared module?
So is there any way to see where angular thinks it needs this? For example, I see the main chuck was build before - what is angular building when it fails?
Can I exclude this somehow (tsconfig.app.json exclude didn't work)?
I found an unused import which itself imported most of the other projects components.
But if anyone still knows a way to see which file caused this kind of error I would still appreciate it and accept it as the final answer. I had to look into every single file to find the wrong import.
Lets imagine an ng2 app which handles following platforms: web, mobile-web and mobile-native.
Owing to the fact there are many shared files (redux stuff like action creators, reducers..., services, common components),
everything could be in one repository. In most cases there are differences between web, mobile-web and mobile-native view login in components and routing.
Everything is managed by webpack which builds all stuff using .mobile.ts and .desktop.ts extensions. Files with .base.ts extensions contains shared view logic between desktop and mobile components.
Current (simplified) file structure is as follows (desktop is web version, mobile is mobile-web):
assets/
app/
/common
actions/
enums/
models/
effects/
pipes/
reducers/
services/
components/
account-list/
account-item/
account-item.component.base.ts
account-item.component.desktop.ts
account-item.component.desktop.html
account-item.component.mobile.ts
account-item.component.mobile.html
index.ts
account-list.component.base.ts
account-list.component.desktop.ts
account-list.component.desktop.html
account-list.component.mobile.ts
account-list.component.mobile.html
index.ts
/modules
/desktop
/accounts
accounts.component.desktop.ts
accounts.component.desktop.html
accounts.routes.desktop.ts
index.ts
/mobile
/accounts
accounts.component.mobile.ts
accounts.component.mobile.html
accounts.routes.mobile.ts
index.ts
app.component.desktop.ts
app.component.mobile.ts
app.module.desktop.ts
app.module.mobile.ts
app.routes.desktop.ts
app.routes.mobile.ts
As you can see, number of files is growing so fast. I dread to think how it could look by adding another native platform. Unfortunatelly I can't find any interesting examples for my case.
The only one that I've found is:
Angular2 advanced seed link
But it seems preety weird and nonintuitive as well.
Do you have any advice how to make better structure for that case ? I'll be grateful for any help. Thanks in advice.
I would suggest that you create different projects and create a common angular package, like this:
common (include angular services and helpers)
web (component and web-specific services/views)
mobile-web (component and mobile web-specific services/views)
mobile-native (component and native-specific services/views)
Maybe you can join web and mobile-app together. But this setup worked for me in many projects
When I work with angular2 code I often need to see the implementation of a class, let's say the Router class.
If I click on the Router type in my IDE WebStorm, e. g. inside the constructor of another class
export class myClass {
constructor(private router: Router) {}
// ...
}
my IDE takes me to the TypeScript definition file router.d.ts inside my node_modules folder. What I want is it to take me to the original router.ts file with the implementation of the router class, not just its definition.
The original .ts file is not included in the node_modules folder structure when you get angular2 from github via the standard package.json suggested in the Angular2 Quickstart. Currently, I have to look up the original code in the official github repo.
Any ideas how to get the .ts files into my node_modules/#angular folder instead of the .d.ts files?
Sadly, it's not possible since no TS files exist. Even if you add them it still not possible since you import real angular paths which always point to the definition files. On top of that the file structure of the project does not correlate to the structure of the import string literals.
Some background and more information
The NPM package does not include .ts files, this is by design from the angular team. Up until some time ago the .ts files were indeed supplied with the NPM package.
The reasoning for removing them is to disable abuse from users accessing private classes and #internal and private APIs which is public methods/properties in the API that are not supposed to be public but must be so other angular internal classes can use them.
We used to see a lot of code samples out there doing things like import { PromiseCompleter } from 'angular2/src/facade/lang'; (before RC0) but this was changed when the project structure had a big structure refactor in RC0. This abuse was wide and it's bad, very bad... For users and for Angular PR.
The Angular project has a complex and robust build process where all of the API is moved from .ts files into d.ts files using an automated process that limits exposure. (public_api_guard)
The end result is d.ts files only.
It's also not possible to clone the git repo and use it since, again, the file structure is way way different so imports will have to change. Most importantly without the build Angular will, most likely, not work.
A solution using a different approach
However, if you debug your app you notice that you reach actual angular core .ts files in the source view of the console, this is because the NPM package comes with source map files that include the whole TS source code. Nice trick they did there.
This is what I use to dig deep into angular, it works quite great and I get a lot from it.
It's not as nice as Goto Declaration but it something...
IMO it's also easier to understand when you step through code...
I am building a web application based on Rails and, on the client-side Backbone.js. For structuring my Coffeescript-Code, I used RequireJS and requirejs-rails. Each of my Backbone classes lives in its own RequireJS module.
I recently refactored a lot of code into some base classes and want to package them somehow to be able to easily reuse them in other projects (Rails and/or Javascript/Coffeescript, possible even without RequireJS) and share it on GitHub as a separate project from my Rails application. I read the RequireJS documentation on packages, but it doesn't go into the details very much. So this is what I would like to do:
Move my shared code into its own package, so views/base_collection_view becomes commons/views/base_collection_views and so on
Include the package into my requirejs-rails setup in my rails applications, and provide a compiled my-commons.js file to use within non-requirejs setups (I guess the latter would be done using almond fairly easily once I figured out how to layout the package)
A full example of a reusable RequireJS-package would really help me a lot at this point, along with some ideas how this could be transfered to requirejs-rails.
Not sure about requirejs-rails, but with RequireJS it's pretty easy.
define(['dep1', 'dep2'] , function ($, otherLibrary) {
return function () {
// your module code
};
});
Where 'dep1' and 'dep2' are other RequireJS modules that your module depends on. You can depend on as few or as many as you like. The var names you pass to the actual function ($ and otherLibrary in this example) are the names that those libraries will be assigned to within your module.
Anyone using RequireJS will be able to require your module this way, based on how the file is named and the folders it's in.
For instance, if this file was called "my-super-lib.js" inside of the libs directory, another module could just pass libs/my-super-lib to its dependency array and everything will be set up.
Update: just remembered you mentioned coffeescript. Same idea, but to be clear:
define ['dep1', 'dep2'], ($, otherLibrary) ->
() ->
// your module code
If you're into that. ;)