ASP.Net Core MVC with Angular 2

Post Reply New Topic

I know you guys aren't Stackoverflow or anything, I just wondered if any of you have had this pitched at you recently.

I've been at my position maybe a month and I've got a project, not officially ordered yet and due in a few weeks, where they want me to combine ASP.Net Core MVC with Angular 2. Best I can gather is they want to do the POCO's and possibly Identification/log-ins through .Net Core and use Angular 2 for all of the web components. Downside - Pluralsight has nothing on this combination (yet) and I've found maybe one tutorial so far on Youtube (Sergey something-or-other) who had a video showing how he made the connection between the two systems through _Layout.cshtml but that was about all I got to see.

If any of you have seen a good tutorial or know of a good finished sample-project I can probe let me know. I'm quite new with .Net Core, brand new within the week with Angular, and while it doesn't look impossible it does look like getting at the information I need might be tricky.

In the meantime if I have better luck in my search over the next few days I'll post a link.


Thanks!

Just took another look on his webpage, he had a link it just wasn't well marked:

http://www.dotnetspeak.com/angular/talk-at-ggmug-2/

Wish me luck!

You may not find a lot of info about this as people don't tend to focus on "combos" of this nature. MVC is a server-side technology that builds html to send to the client. It doesn't care what is on that html. Angular is a client-side javascript framework for manipulating the html\DOM in the browser. It doesn't care how that html got there. Most MVC tutorials will focus on MVC and Angular ones on Angular. If you understand both you'll naturally understand how to put the two together, you have to appreciate there isn't really a "link". People tend to focus on the tech in isolation rather than how you can use two completely separate bits of tech together.

So my advice is to just learn Angular, and learn MVC, and you should then get how the two "fit". The only things you need to know in MVC are where to put the script file includes (as you're mentioned, these will likely go on the layout), then if your Angular is using ajax calls you'll need to know how to provide methods that can be used with Ajax but again that's just part of MVC\Web API.

So stop thinking about them as a single problem....think about it as two things you need to learn, and when you've learned them both you should just "get" what you need to do. If you keep googling or looking on more MS-centric sites you'll defo find examples of the two being used together. This for example...

https://www.codeproject.com/Articles/80 ... ET-MVC-Par

Apart from setting up the project initially and including the correct script references you'll see there's almost nothing about MVC itself in that tutorial as Angular is client-side, it doesn't know or care about MVC.

Good thoughts and yes - I do plan to learn both, I don't know that I'd even want to call the languages necessarily, maybe frameworks or libraries all depending? I agree as well that there are some great Angular 2 tutorials on Pluralsight, there was something like a 9 hour beginners tutorial by a couple guys dealing with just setting up an Angular 2 site - it was very informative in terms of how the calls work and how all of the modules are supposed to reference each other. In a better world I probably wouldn't be tasked with such a fools errand as trying to make a project like this out of languages I don't know yet but such is the way of things these days.

As far as the join I found this which I built a start for my first project on:
https://medium.com/@levifuller/building ... b163830eaa

There was another piece somewhere that recommended installing spa templates, it made the combined project really easy to compose (within seconds) but I also noticed that the end result was a .csproj that isn't wrapped in a .sln file. I'm that green with these languages at this point that I'm not even sure whether that makes the later option unfeasible for end deployment. I'm being asked to, in a way, not only think of what I can make work but also what would be sane file structure. That said I get the impression that what I do here will by and large influence the starting structure of future projects.

The only thing I might want to ask you about further here is maybe initial project structure. Is there anything I'd want to keep in mind regarding containment and structure for the sake of keeping both the mvc and angular crisp and legible from the programming side? I notice my coworkers for example already had the MVC in multiple class libraries within the project and I see where having two libraries, one for angular and one for the MVC maybe, would be helpful for keeping like with like. I've also seen that people can have very different Angular 2 file structures - I really liked what they were doing in the tutorial I watched where the critical files like the Angular 2 bootstrapper, main app.module, etc. are at the top either in the app folder or maybe, at worst, in an app/assets folder. The rest flowed down pretty logically. I ask that because none of the pre-packaged stuff I've seen, particularly the startup project on Medium that I linked, look like they were put together with top-down legibility in mind.

In terms of project (csproj) and solutions (sln), a solution is just a collection of projects. The project has everything needed for that project to work, the solution just has the list of projects and if there is a compile order etc. If you have a project without a solution then Visual Studio will load it and simply create a solution for you (even if there is only one project, you still have the solution) and when you "save all" it'll ask to save the sln file it created for you as well.

For project structure, again angular is just a javascript framework so it kinda doesn't technically matter. You can structure the files any way you want, you could even put everything in a single js file if you want. However the angular site does give recommendations about how the files should be structured and it's best to follow that structure. For your MVC stuff you might end up with multiple projects, people tend to keep all the "web" stuff in one project, then if you have a bunch of service\repositories\business logic etc then people tend to keep related things in their own project. But your angular stuff will probably end up in the main web project with your MVC views etc. It's part of the web front end so should be in that project.

I haven't dealt with anything ASP since a decade ago, but I've been playing with Angular since version 1 (~late 2012). First off, is your team using Angular server-side rendering or client-side rendering? (server side makes for smaller download chunks thus less bandwidth for a user, but with higher CPU cost on the server). If you're doing server-side I recommend having ASP parse the vast majority of data and just use Angular as a template engine, since ASP is going to be quicker on a server than Angular for rendering purposes (javascript V8, the underlying processing tech, does great at async tasks like serving multiple pages, but performs poorly at linear tasks such as rendering). If your team goes the other route with client-side rendering I'd recommend writing the entire application in Angular, and use ASP merely as an api interface to exchange JSON data from Angular to the server database (this is how Angular was originally intended to be used, hence most just settle on Node for a server language, since it's simple, easy to use, and only needs to act as a file server). Also note there are major changes between version 1/1.5 and 2/4 of Angular, if you're getting resources online make sure you're getting info for Angular 2+.

As for project structure, I recommend not using the Angular CLI, it creates folder navigation hell: almost every generated file is put it in it's own folder, if it's a component that folder is going to have an .html file, a .css/.scss file, and the typescript component file (.component.ts). To me that's just too many files for one component, one of the best parts of web programming to me is that it's not C++ with a zillion files for one program, and the Angular CLI makes Typescript/Javascript feel like C++. My preference is to manually create the component file and put the html and css inline in the component file (I use scss, so I'm forced to make that it's own file, since only css can be rendered inline). I also like putting lots of component files in one folder and having them share a .css/.scss file (I always just name it styles.scss, so it's easy to find in any folder, and easy to link in the component files). Below is a screenshot of my current project, complete with open folders so you can see my file structure:
https://goo.gl/photos/9tKydH3iHRMdd7u56

Also of note: Angular 2/4 has some compiling issues. C++ compiling is quick compared to how slow Angular2/4 compile. Because of this I highly recommend making a 'watch' command in your package.json file so the Angular CLI is not constantly compiling the entire app, just the modules you're working on. Put this in your package.json:
"scripts": {
"build": "ng build",
"production": "ng build --prod --aot",
"watch": "ng build --watch"
},

If you're working on multiple modules watch will break because it will probably only update one module, not all of them, that's when you stop watch and manually run build since it will re-compile the entire project. 9/10 times my css changes don't take effect until I've manually re-compiled.

One last tip: I recommend using base javascript for most functions, and only use typescript on JSON objects pulled from the server that are going to be immediately converted to javascript objects. My recommendation for this is purely speed: adding all the type information in every variable is a waste of time since your compiler will alert you to type errors before it even hits production. The reason I do it on JSON objects is because they're not testable during compiling and they didn't originate in the application (they've been exported at some point possibly converted a few times, and then sent back): typecasting helps find errors in this situation, and makes it very clear exactly what the incoming object should look like.

If you have an questions about Angular, Typescript, Javascript or the like feel free to PM me, although it could take some time for me to reply.

TY. I'll probably keep the structure as-is for now then, ie. leave the angular in with the main MVC components. There really aren't that many anyway in this case.



I'm pretty sure we're going to have it almost exclusively use Angular 2 and keep the MVC for the POCO's and ASP.Net Identification.


Actually I'm really glad at this point that those files just show up in dependencies, that way it really doesn't flood my project/solution view.


TY - I'll have to see if that's already there. From what you're saying it sounds like an async tool. Very good to know!


I did notice that when I was working through all of the Angular 2 tutorials any typescript file would also create a .js and .js.map. Would that be about the same as just deleting the typescript file at deployment?

Everyone has different work styles, including what they want their IDE showing/not showing. To each his or her own, my only point is that folder structure is highly configurable with Angular, there's no need to do exactly what the CLI gives you, or what the Angular team recommends (let's put it this way, if they change how files are linked they're changing the core at which point all files will need changed if you followed their guidelines or not). Make a file structure that works for you. The only caveat with file linking is that if you're using LESS or SASS for stylesheets you can't use the import statements if the classes are inline, so consult the designer on that one. That's literally the only restriction from doing whatever you want (aside from trying to pull a file outside the project root of course). Also of note, the only real negative I have with Angular is how it does module routing, that can be tricky and frustrating to bug check. That's not on point but it is a related point, and one I would recommend reading up on first because about the time you get two components you'll want to bundle them to a module and module building/routing in Angular can be tricky (at least it was for me when I moved to Angular 2, your mileage may vary).


I'm not exactly sure how the CLI operates, never looked, but I deduce it looks only for the last changed file, not all changed files, thus if I have 2-3 modules open in the IDE make some changes to all, then save all + compile, the compiler only finds the last module saved and updates that module (not all three new ones). That's the behavior at least, and really just a heads up-- I've wasted a few hours of frustration redoing code that I know should work only to see it never make a change when I refresh my browser, only to recompile the entire project manually and see all my changes magically work. My new rule is: when in doubt manually recompile with a simple --build flag.


I should have clarified Angular 2 comes in two flavors: Typescript (.ts) and Javascript (.js). You're using the JS flavor so ignore that paragraph. TS is exactly like JS except that you can make the resulting JS function like a strongly-typed language (C++), for most purposes, especially client-side, there's no need for strict typing. Regardless of which version you use it's all compiled down into native Javascript. Google created Angular 1.5 (v1 was a personal project of a Google employee), Microsoft created Typescript. Now Angular is a multi-teamed project, but the two groups at the helm are Google of course, and now Microsoft. That tells me as a user down-stream that eventually Angular will move to a TS only version eventually, so you may want to get used to it now. All valid JS will work in TS, all TS does is allow you to set type. Example-
JS:
var makeURL = (text)=>{
return 'http://somesite.com/' + text;
};

TS:
private makeURL(text:string){
return 'http://somesite.com/' + text;
}

The only difference is that the 'private' command ensures no other components can interact with that function (just like C++), and the :string in the function parameters makes it so that only string types will be accepted into the function. You can also create custom types out of JS objects for the same purpose.

On a side note, the .map files are just for ease-of-use when debugging in the console, they'll disappear when you build with the --prod flag. Also of note, Angular 2 has JIT (just in time) and AOT (ahead of time) compiling of code. For large applications AOT is the way to go, for small projects it's actually a larger file output. *Another downside of Angular: getting the initial bundle package under half a megabyte is virtually impossible, so your users will have a substantial download when they first reach the site. Also, since from what I understand you're using Angular the way it was meant to be used (the workhorse), get very familiar with Angular navigation, there are multiple ways to include content and they all work differently. A few keywords to Google: content projection, feature module routing, shared module routing, lazy load modules. Those are all ways to put content into a component, and they all work differently.

Anyhow good luck.

Just an update - I did have some luck getting a line of text from a controller that I'd placed in a get/set statement through to an Angular component. I was running into quite a bit of frustration because while I had the right idea with everything else this portion of my C# is a bit shaky - I was trying to push this into an IActionResult when it really needed to be 'public classname actionname():

Quick update on merging ASP.Net Core and Angular 2 - .Net Core is on 2.0 right now and I'm working with that. Since 1.0, really since the new VS2017 preview, ASP.Net has included a spa template for Angular. It still needs a fair amount of the npm packets which is understandable but it seems like there's a stable layout and folder path to go through to lay out your components, services, etc.. What's still a little weird to me is that area is maybe four or five folders deep but oh well.

The other good news - there's been an explosion of Pluralsight tutorials in the past month or two dedicated to ASP.Net Core and Angular 2 merger. They're also dealing with all of the ways one can put together a working Rest/CRUD which is something I was able to figure out maybe a few weeks ago.

I think the biggest surprise for me with these languages though is partially how frigid the structure of the projects are, how many zones within the project don't permit one type of process or another (I think that's probably C# and JavaScript in general) but in particular something like trying to convert a JSON date to a JavaScript date, ie. 'new date (yyyy, mm,dd)', is next to impossible and I'm in a position where that needs to happen either in the http.get statement, in an export interface, etc.. to take its conversion either within custom mapping I have in the get statement or shortly after - but somewhere prior to a particular UI grid we're using. I can't tell which it is at this point - whether people just consider date conversion something their not willing to do, or whether this is like the accounting field where there's a bit of a knowledge keep-away game for the sake of people keeping full employment; I tend to think the later, mainly that such a procedure seems like it would be routine and if people simply gave up on counterintuitive or inconvenient stretches of processing they could barely do a thing with these languages.

So at the end of the day I'll be right back to beating myself in a head with a brick (metaphorically), and looking all over Google for micro-clues. I could be doing that for the next few weeks at this rate. Wish me luck!

Handing dates is always a nightmare. You should always specify what format you want dates to be in and using date pickers on the client side can make that easier.