Structuring a NodeJS app using Angular and NodeJS Tools for Visual Studio - angularjs

I would like to know how do you usually organize your application structure when building a NodeJS application using nvst. When I create my app it automatically build up this structure for me:
So, the first thing that came to my mind was, where should I put my controllers and how do I connect them with the routes and views?
Also, how can I organize my unit testing logic?

An NTVS angular app is still just an angular app. The advice in AngularJS application file structure applies.
Going further, General principle: You should be able to find what you're looking for without excessive drilling or scrolling.
Schemes:
for smaller apps, folder by type: controller; service; model
for larger apps, folder by function: user; cart; search; grid
I lean toward folder by function, as it keeps files that may need to be modified at the same time together.
As for unit tests, I have seen either myfile.test.js or myfile.spec.js sitting right beside myfile.js. If you do not include the test files in the index.js, then they won't be loaded and don't cause a problem.

Related

Adding vueJS into an existing angular application

I have an existing angular application and I want to start changing some of it to a vueJS application.
My application, in dev mode, loads all scripts in the main html file (in production mode its bundled into app.js but I want to start testing to dev mode).
I want to change on of the states to use vue, so I read it's possible in the following way: https://medium.lucaskatayama.com/migrating-from-angular-to-vuejs-71277cdc3dd9
However, I want to use a .vue files syntax and I don't know if that's possible without using webpack or any other bundler in dev mode.
So my question is - Is that possible? Can I use .vue files inside my ng app with the current configurations? Furthermore, is there a nice way to webpack only the vue files and components (even though I have to initialize them inside and angular controller as it seems).
If there are any good tutorials for adding vue into angular app, I would love to get them, as I failed finding good ones.
Thanks
ngVue member here :)
At Dawex (the company I'm working at), we're using Vue within a big AngularJS application, with ngVue. It's in production for several months now and it works very well. You can find more informations on this article I wrote before last summer: https://medium.com/dailyjs/how-to-migrate-from-angularjs-to-vue-4a1e9721bea8. Hope that helps!
That could be tough, because the build for the vue code will basically be a separate application.
One thing you could do is build them as completely different parallel apps, use two build steps, include two javscript files and then use window.postMessage to communicate between the two.
So for example your current application will come to a point where a particular div is to contain vue code instead of angular. You could then post a message from your angular code, telling the vue app to load into that div, e.g.:
window.postMessage({ app: 'vue', bind: '#vue-content' })
The vue app, instead of binding on DOMContentReady would listen to window events, and then bind to the element it receives. It would then communicate back to the host app by posting messages also. This would keep them fairly seperate and allow you to build them independently.

What is the optimal architecture combining Scala-Play and AngularJS?

I have recently worked in a pure Scala-Play application and later in a pure AngularJS application. I'm very impressed with both and I'm wondering what is the sweet spot of combining the two frameworks together. Since the two frameworks can be complementary but also overlapping in different areas e.g. MVC and page routing, as far as I know these are some of the possibilities:
Single Page design, use AngularJS MVC-only and use Scala-Play as "dull" service layer backend with no full page refreshes.
Allow page reloads and each page reload becomes a different AngularJS root application. This seems quite flexible e.g. the client side is not bloatted with so much data for larger applications but better partitioned for the different use-cases. The downside is that I'd need different AngularJS MVC applications and I'm not even sure how to organize it as a project. Are there examples of this?
Typical server side Web App, use Play MVC-only and AngularJS for handling UI models for each separate page.
My choice of IDE for these types of architecture would of course be WebStorm but unfortunately I can't have all client-side (AngularJS and JavaScripts) and sever-side (Scala-Play) codes in a single project.
I believe that there is no the ultimate optimal architecture for combining Play and Angular. It depends on the specificity of the project, team etc.
The decision to develop UI part with Angular and the server side back-end with Play is very reasonable. Technically it may be done as following:
Development:
Both parts are developed as detached projects with the preferable IDE.
The client should have some entry point HTML page. It is reasonable to name it index.html, but is may be any other name.
For client-server integration do on the Play side as following:
Select a sub-folder under the play application root, which will serve as the "home" for the client files. The default solution is to use the folder public, since all files under it are automatically deployed.
All client files should be copied under the public folder. The files may be organized in any structure.
Add a route for the default URL as a route to the index.html. The argument path in the route should be the full path of the index.html relatively to the application root.
If index.html is directly in the public folder, the route is like this:
GET /defaultUrl controllers.Assets.at(path="/public", file ="index.html")
Add routing to the client files:
GET /*file controllers.Assets.at(path="/public", file)
Now the distribution package will include all the client files.
Putting of the client files into the public folder should be done automatically, for example by organizing the client directory structure and appropriate configuration of the client IDE.
You can find more examples in this post.

Is putting an Angular frontend into a seperate source control repo considered good practice?

I am developing a web application with an API written with Node and an Angular frontend. My current deployment pipeline watches source control for changes and then pushes everything to a build server, where it is built and then deployed into production. Currently, my Node application is set to serve the Angular frontend, which is unnecessary and needs changed. My question is, would it be a good idea to place the front and backend applications into different repos? That way, I can control the deployment of each on individually. My Node app uses a lot of C++ libraries that take some time to compile, and I don't want to have to compile them every time I make a change to the frontend. Is it a good idea to separate them?
To avoid re-compiling back-end libraries when you change your front-end code, you don't need to separate repos.
Some rule in your gulp/grunt/whatever config should suffice...

Should I use Angular for a local only NW.js project?

I want to build a mid-size application using NodeJS and NW.js (formerly known as node-webkit). The application will grab some data from the internet but isn't talking with one special service which is under my control.
Is it a good idea to use AngularJS nevertheless or is the MVC approach of Angular oversized if there isn't neither a database nor a webservice on the controller layer?
I think Angular would be really fine for databinding and GUI handling, but I'm not sure if it's the right approach for this kind of application.
I see no reason not to use Angular in an nwjs project. I do it myself in the app I just finished building. It's a local-only deck tracking app for hearthstone that never communicates over the internet at runtime. It only ever monitors a log file that is generated by the Hearthstone game. Since the way I'm display information to the user is still technically a web page with a full DOM, Angular makes perfect sense since I'm already comfortable using it.

Angular App to AppGyver- Port to Mobile Solution

I'm beginner to appgyver steroids.
I have angular project. Now I need to make iOS application using AppGyver.
Instead of modify root view and point it to my angular app url (http://www.yourapp.com) can I add my angular app source / angular project build to AppGyver project make it iOS application.
Appreciate your comments
Gayan
You can run steroids create yourApp. This will walk you through the generation of a multi page or single page application. You can then move the structure of your angular application into the /app folder. Check out the example that the steroids create method generates and see the structure there.
You may notice some differences at first. It may take some testing to see what is failing if anything once you port things over. If you used $rootScope for anything it is not as reliable in my experience in an iOS or Android application. There are other methods for passing data between views and broadcasting (publish/subscribe) to other controllers.
You will want to use the iOS simulator or http://localhost:4567/app/moduleName/oneOfYourViewsYouAreTesting.html in your favorite browser while steroids connect is running to debug.
The version of Angular that is coming with this now is AngularJS v1.3.15 installed via bower. You may want to verify things are compatible with your current Angular version.
Ionic is used and Supersonic so you may see conflict with existing CSS or even javascript depending on what you've implemented.
There will be some tricks to learn about preloading views in the structure.coffee file and load times / rootView / initialView. There is lots of support if you come across any issues.
This forum has been really helpful in figuring out any issues I've come across. The Appgyver team is usually pretty responsive to questions directly as well.
They are updating the platform in a few days, and they say big changes are coming. They are hiring a lot of developers right now to take care of GitHub issues as well as build out the rest of their incomplete components.

Resources