Angular js structure in .Net MVC 5 - javascript

I have been new to angular js.
My structure of Angular JS in MVC5 is in the picture below
I need to create a simple application that has CRUD for a single entity.
So far, I have created only single controller in Angular folder.
I have put all the directives, filters and functions in the Website.js file.
I need to create different pages like add/edit/details.
The CRUD operations are not only simple, but i have to put some extra logics in them. I need some process where either deletion, addition or updating in model
do changes everywhere on the page.
Question
Should i place all the directives, functions to the same controller? Or i should create seperate files for each CRUD operation? Please guide me to the structure of this application.

You should create seperate files for directives, filters, services and controllers like this:
app(folder inside scripts)
----- controllers/(folder inside app)
---------- userController.js
---------- itemController.js
----- directives/(folder inside app)
---------- mainDirective.js
---------- otherDirective.js
----- services/(folder inside app where all the services will go)
---------- userService.js
---------- itemService.js
----- app.js(main file where you will declare angular module and other application configurations which are common)
Create module wise controllers and service like for user module i have created one service named userService and one controller userController now in this user controller i will implement all business logic related to user and all CRUD operations. It is good practice to specify all $http requests for CRUD in a service and call that service from controller.

Related

How to inject Models, Services in all Controllers by default while creating a node js app with express

I have a little experience with Sails and I really like the way it automatically injects all the models and services inside controllers so we save ourself from requiring all those at the beginning of the script, but the framework is very bulky.
So, I am making a project using express framework and want to implement this feature where I do not need to require Services and Models in each and every Controller script.
Thanks.
you can create a index file for exporting all services and models. Then just include it into your controllers
in service.js
exports = {
auth : require('./auth'),
user : require('./user'),
and many more
}
in controller
var service = require('service')
use services as service.auth, service.user
Thanks

How to connect views to default api urls in Sails.js

I have created a new api using sails sails generate api tasks, using the default configuration of sails 0.12.
With Sails awesome blueprints, I can access localhost:1337/tasks and see the list of tasks or localhost:1337/tasks/create?text=yo to create a new one.
But what I want it to connect these endpoints to an .ejs view.
I tried creating a new folder tasks and placing show.ejs or index.ejs files in it but it's still returning the Json.
Is there a default way to render .ejs files through the default blueprint urls, without creating new routes and controller methods?
Well it took me a while to find the answer, so for anyone looking to use sails.js development speed, here is the way to do it:
After generating the api, create a folder inside your views folder (named after your controller). The files in it should be:
+ tasks (the folder with the same name as your controller)
- find.ejs (list of all items)
- findOne.ejs (view a specific item)
- create.ejs (after a successful creation)
- update.ejs (after a successful update)
- destroy.ejs (after a successful deletion)
These files are connected by default to the different api endpoints. So, when you access the url localhost:1337/tasks sails will automatically render tasks/find.ejs. Same for the other endpoints.
Another point is that each view will have a global variable named data that will include the result of the api request (i.e. the records that were fetched / modified).
You can see a small example here: https://github.com/web-development-course/Bootstrap (look at the 'things' api)
I hope it will help you guys

What is the proper way of using client-side routing?

I have a question regarding AngularJS and Node.js.
I have a web application and I use client-side routing with routeProvider to navigate through the pages of my web application.
And I get the data through a RESTful API server-side. But all of logic is done in AngularJS, because with the client-side routing, all I do in Node.js is :
exports.partials = function(req, res, err) {
var name = req.params.name;
res.render(name);
};
So, I only use Node.js to render the template layout and the partial view, but all of the logic is in AngularJS.
Is it the proper way to use it?
Angular.js is a javascript framework to create a SPA or Single page application.
It creates its own navigation system using the hash(#) or hashbang(#!) in the url to represent the different states or pages of your application but all this happens in your home page. The browser never changes to another page because all application state will be lost in a page refresh (HTTP is a stateless protocol).
Usually you need 3 parts to create an Angular application each one with it's own routing system.
Your angular application: All the scripts and resources are loaded in the home page. The routing system is provided by $routeProvider and the hash(#). Eg: http://mywebsite/#/products or http://mywebsite/#/providers. All this is relative to your home page.
Your templates: This is retrieved using ajax and can be routed however you want, Eg: http://mywebsite/product.html or http://mywebsite/templates/product.html serving static html files or even http://mywebsite/templates/products using a restful approach and a server side routing mechanism. There is no general rule here because basically depends on the server technologies chosen and your own design.
Your data: Usually a Resful API to supply you application with business data stored in a database. Rest creates some basic rules you must follow like treat everything as a resource and manipulate it with verbs. Eg: GET http://mywebsite.com/api/products or POST http://mywebsite.com/api/providers
This is an example of an Angular route provider
.config(function($routeProvider, $locationProvider) {
$routeProvider
.when('/Book/:bookId/ch/:chapterId', {
templateUrl: 'chapter.html',
controller: 'ChapterController'
});
In this case angular will fetch your home page from http://mywebsite.com initially and the template from the content of your chapter.html file located in http://mywebsite.com/chapter.html and your data from whatever configuration you set to your $http service. As long as you set your routes in a way that don't conflict with each other you are safe. In your case you can use express.js to create a restful routing system for your templates or serve them directly from the public folder as html.

Code organization (node, js involving models, service, route and mocha tests)

I'm quite a beginner in the project architecturing / structuring side of things.
The overall project currently looks like:
route/home.js
service/appService.js
models/appModel.js
In the route file, I require appService.js.
appService.js takes care of some API calls to external services, such as getting an access_token from such API service.
When I receive the access token, a callback is made in appService which calls appModel (appService requires appModel.js), and in turn appModel stores the access token in the database. Then, another callback is called in appService which in turn does runs the callback that the route page provided, then I make a redirection.
I am using mocha for testing the service and model files.
My service file is requiring the model file, so when I create a mocha test for the service file, the model is called indirectly as well.
Should I require the model in my route file instead of the service file, and run the model function in the route, once I receive the access token response from the API in the service file? What do you suggest?
Normally you would have some kind of bootstrapper or service container which handles loading your files.
That way you avoid tight couplings between the different parts of your application and can exchange them out when testing (such as swapping the DB for fixtures).

Marionette building re-usable sub-apps and modules

I am currently building a complex marionette application and have been follow a great book as a reference. However, I am a sucker for reusable code and like to keep things flexible as possible.
My application has various screens and modules, one of which is a dashboard. The dashboard has its own set of responsibilities, so I made the conclusion that it should be a sub-app.
The dashboard is split 50/50 and there are two components inside. I have identified that each of these components (lets say compA and compB) each have their own set of responsibilities aswell and should be their own sub apps. However, I will have the use case where compA will be used in another area of the application.
My first thought with re-use in mind was to simply re-use the views and create a new module where ever this particular view was needed. However, the unique events and actions that come with this view are stored in the controller and API to interact with the module.
So I have ended up with the following structure:
application.js
apps
--dashboard
--compA
--compB
and I have implemented something like the following to reuse functionality from compA
Controller = {
getView: function () {
return new Show.MyView();
}
}
API = {
getMyView: function () {
return Controller.getView();
}
}
App.reqres.setHandler('compa:get:view', function () {
return API.getMyView();
});
Doing this allows me to request a new instance of the view to display and keep the same action logic. However, this means that there is no separation between each section (compA in the dashboard, and compa in another section of the app). So if I were to stop the compa module it would not have the desired results.
Is there a better approach to re-usable modules with minimal duplication of code?
My thought was to extract the Controller logic into a controller object that I can extend, and then creating a new 'sub app' when I would like to re-use the features.
application.js
apps
--dashboard
--compA-dashboard // new instance of Controller
--compA-somewhereelse // new instance of Controller
--compB
It seems as though I may be over-complicating my design pattern.
Allow me to rename your "component" as "widget" at first. In my opinion "component" is better for things more general than the widgets in your case.
I would arrange those widgets as following:
app.js
/app
/dashboard
/show
show_controller.js
dashboard_app.js
/other
/components
/widgets
/widgetA
widgetController.js
widgetView.js
/widgetB
Since widgetA is dependent from dashboard and is supposed to be use elsewhere, it should be fully decoupled from dashboard.
The 'show' View of Dashboard should have a Layout to define where to show widgetA and widgetB.
Then, in your DashBoardApp, set an appRoute to respond to some route, and then call the controller.
The controller will initialize the Layout.
The Layout will ask for show of RegionA and RegionB.
Listen to 'show' events of RegionA and RegionB, to ask for an App wide request
this.listenTo(regionA, 'show', function(){
App.request 'widget:a:show'
});
Then in Widget module, respond to the App events and deliver the view
App.reqres.setHandler('widget:a:show, function(){
API.getWidgetAView();
});
The later part of my answer is a bit vague with less code. The basic idea is, DashBoardApp should finish his job by sending App request. And then it's components job to deliver the view upon App request, which is fully decoupled.

Categories

Resources