I'm creating an Angular 6 application that will serve two types of users.
A buyer and a seller. I want each one of them to have their own GUI. How would you structure your application? taking into account that both theses GUIs have many components that they can share.
I was thinking something like creating 3 modules /buyer , /seller and /shared
I will also be using an auth guard so when authenticating the buyer can only access their GUI , etc ...
I'm new to Angular so any help will be appreciated!
thank you.
Yes, a buyer module containing all the components for the buyer,
a seller module containing all the components for the seller
and a shared module containing all components/services/models used in both buyer & seller module.
This is only the first layer, depending on how big your application is you will need more levels of modules.
The offcial Angular styleguide is a good point to start, you can find it here.
For more about application structure you can look here in the styleguide.
Create 3 separate module with main module and put common things in main module or create one shared module and import where you want to access.
also use SCSS for styling and create one separate folder for sass and write all the basic files and things in scss
You can also create separate folder in asstes for mock-data
Your project structure would be something like that:
app/
core/
shared/
assets/
mock-data/
sass/
Related
I'm working on a multi-page site using AngularJS, and I want to write a utility that can be included in more than one page. I've looked at services and providers, and all the examples I find are single-page examples. I'm not sure how to generalize this to multiple apps used on different pages.
This is what I want to have for my two different pages/apps.
in app1.js:
var app1 = angular.module('app1',['myUtil'])
app1.controller('ctrl1',function ctrl1($scope,myUtil){...})
in app2.js:
var app2 = angular.module('app2',['myUtil'])
app2.controller('ctrl2',function ctrl2($scope,myUtil){...})
in myUtil.js:
??? Provider? Service? Module?
All the examples I have found for providers and services show them as being attached to a single app. Is this possible with AngularJS? If so, what am I missing?
The answer from zero298 is a nice answer as it's a great way of organising and reusing the utility module you create.
If you want a less broad and more "codey" answer, then one way of doing it would be to have some kind of utility module that houses whatever services you want to put in it, and then you can pass that in as a dependency for all apps that use it. This will all depend on your build process as to how you import/organise the files, but as a very basic example you could have a "utilsmodule" module with a "utils" service:
myUtils.js:
angular.module('utilsmodule', []);
// Service could be in another file
angular.module('utilsmodule').service('myutil', function() {
return {
myUtilFunction : function() {
return "This is from myutil";
}
};
});
Then in your app files you can pass in the module by name, which will give the app access to the 'myutil' service.
app1.js:
var app1 = angular.module('app1',['utilsmodule'])
app1.controller('ctrl1',function ctrl1($scope,myutil){...})
Then you would import the myUtils.js file before the app1.js file so that the "utilsmodule" module is registered with angular before your app is created. You do the same with app2 and the utility module should be available to both.
Example Plunker
This may be a bit too broad. However, what I would suggest you do is create a library module dedicated to the feature/utility that you want to make available to your projects.
I would suggest using npm to organize all of this. Give this feature module it's own package.json and add whatever code you need to make it run. In your consumer projects, add the library module as a dependency.
A good method to get this working locally (as well as quickly since you don't have to constantly push to the npm registry) is to use the npm link utility.
If your consumer projects are already npm oriented, the workflow would be as follows:
Create a new directory to contain your utility library module lets call it my-utility
cd to the new directory
npm init to create a package.json in this library
npm link to make the library available locally
cd to any of the consumer projects
npm link my-utility so that the consumer projects create a symlink to the local folder that contains your utility module
After that is setup, depending on how your consumer projects build or use dependencies, you can use your new utility library in your top level projects.
I have an Angular project in which I've developed many UI components that I'd like to use in different Angular projects and share them in the npm community.
All of those components are gathered in a shared module that I've made.
What would be the best and easiest way to compile that module for publishing on npm for example?
Example file tree:
myAngularProject/
├──package.json
├──src/
└──app/
└──app.module.ts
└──app.component.ts
└──app.routing.ts
└──...
└──myComponentLibrary/
└──myComponentLibrary.module.ts // <- this
└──datepicker
└──button
└──...
In Angular terms, this is called a "library" ... so that is the best term to use to find more information.
Here is a link to an article that may help: https://medium.com/#ngl817/building-an-angular-4-component-library-with-the-angular-cli-and-ng-packagr-53b2ade0701e
I have an application in development that is in Angular2 using AngularCli, and I want to use it as a "Layout" (like a MasterPage) to another project. Like a big "SPA System".
For example, in the menu we will have the following:
Framework
Page A
Xpto
Page B
The Framework is running in http://localhost:90 and XPTO is running in http://localhost:91. Both of them is running on AngularCli.
I want to create a structure that when I click on Page A or Page B, the browser doesn't reload and it will give an "app" style to the user, loading the page as a SPA ACROSS the sites.
The main reason is to reuse the Javascripts, CSS and many other files from de "Framework" project to other 20 projects. I don't want to replicate all the components, files and etc across those projects.
Today we use MVC3 and the RazorGenerator to create .cshtml as a DLL to reuse the .cshtml from Framework to other modules.
But we want go AngularCli. Is there any way to do that ? If it isn't, is there some way to create a template in AngularCli that can be reused the components and the other files ?
Thank you !
You can put shared Angular components and modules into a separate npm package and use this package as a dependency for other projects.
In order to reference your npm package (I assume it's not hosted at npmjs.com) you can specify a git repository or local path.
Here is an example of package.json
{
"name": "foo",
"version": "0.0.0",
"dependencies": {
"my_git_package": "git+ssh://user#hostname/project.git#commit-ish",
"my_local_package": "file:../foo/bar"
}
}
Take a look at dependencies section here https://docs.npmjs.com/files/package.json
I have a javascript project consisting of two js-files
component.js
component.angular.js
component.js contains the actual logic exported to globals, amd or whatever. It can be used as-is if you are not using angular.
component.angular.js wraps the the logic in an angular directive, but requires the logic from component.js.
I would like to register/publish both a non-angular (only need component.js) and a angular (need both component.js and component.angular.js) version of this component in Bower.
Overall question: How to do that?
Questions that might help you figure out why I am confused:
Can you even state that two js-files needs to be used in a bower.json?
I guess registering the repository where the code lives in Bower, it will look for a bower.json file. But I guess I cannot state in a bower.json that you will need both files in case of angular and only one of them in case of non-angular.
Can I have two different bower.json files in the same repository? And register them under two different names in Bower - e.g. under "mycomponent" and "mycomponent-angular".
Do I need two repositories?
Well, I ended up having two repostories. One for sharing the raw component (on bower, npm and meteor) and one for sharing the angular wrapping depending on the raw component (also on bower, npm and meteor).
Raw component: https://github.com/TeletronicsDotAe/infinite-gallery
Angular wrapper: https://github.com/TeletronicsDotAe/infinite-gallery-angular
Do not know if that is the best way, but it works for me.
I'm currently working on a big JavaScript project for which we want to define our own API. I'm using RequireJS as my dependency loader and it suits me just fine, allowing me to define modules in their respective file. I do not make use of my own namespace, a module returns an instance, which can be used in other modules, i.e.:
define(
['imported_module'],
function(module){
module.doSomething();
}
)
However as the number of files grows, I'd like to decide how to structure these files in folders. Currently I use the following scheme to name my files:
[projectname].[packagename].[ModuleName]
An example could be stackoverflow.util.HashMap.js. I would like to introduce a project folder, a folder per package and rename the files to the module name, like:
stackoverflow/util/HashMap.js
This structures my code quite neatly into folders, however the filename reflects only the module now. I'd like to define some kind of routing to be able to define how RequireJS should look for files. Example:
The file
stackoverflow/util/stackoverflow.util.HashMap.js
Should be importable by the statement
define(['stackoverflow.util.HashMap'],function(HashMap){});
Has anyone experience with structuring large JavaScript projects and if so, could you share your approach?
You shouldn't specify the routing info on your js file names, those are the namespace and folder paths' jobs. So stackoverflow/util/HashMap.js is just fine. And you can use define("stackoverflow/util/HashMap", ....) to tell the dependency.
If you need to put your modules in a different folders, you can config paths for your loader, see this manual from RequireJS API.
There's no best way for structure your js files. But put the root namespace in a src folder is always a good practice. You can see the dojo source code and YUI source code and use similar ways for your project. They both are large scale Javascript projects.
actually it's better to get js lib routing to load all js using standard interface: "js.yoursite.com/lib-0.2.js" there should be a router (php or other, and able to cache queries). So there you could determine and control whole pathes that you use. Because common jquery plugin should stay at one dir, with jquery, and your own custom plugins not.
And there you control each project by it's own rules:
jquery/
plugins/
jquery.prettyPhoto.js
jquery.min.js
mySuperJS/
stable.0/ -- there your production version for 1.0 branch
module.js
0.1/
module.js
0.2/
module.js
0.3/
module.js
myOtherlib/
stable.0/ -- production version for all 0.* versions
stable.1/ -- production version for all 1.0 versions
0.1/
0.2/
0.3/
0.4/
0.4.1/
0.4.1.18/
We're using such structure around a year and it's the best for us. But sometimes we use more complex solution and separate all modules for libs, plugins, tools, components and apps.