Using Angular 2 components on existing ASP.NET web pages - asp.net

I am trying to move the front-end part of a website to Angular 2.
Currently I have really big ASP.NET 4.5 website.
I would like to create a separated Angular 2 project as it will be growing with time (and hopefully replace the asp.net)
For now I would like to create this project in Visual Studio (2015) and use some angular components or modules in the actual ASP.NET website.
Does the angular AppModule as to be in the ASP website?
I made some research but could not find answers or examples.
Am I gonna be able to do this relying on npm and system.js ? I saw that a lot of people are using gulp for copying file.
Is there a "right" way of doing this?
Any help would be highly appreciated

This question is not specific to Visual Studio, but yes, you can certainly accomplish this.
As you have suggested you can and should maintain the Angular application as a separate project.
The only additions that you need to make to your .aspx page are
including SystemJS and its configuration via script tags in that page or in its Master Page (You can also do this dynamically for CMS pages and using all sorts of other strategies). For example
<script src="loction-of-systemjs.js"></script>
<script src="loction-of-systemjs.config.js"></script>
Adding a markup tag with the selector corresponding to the app's root element, say 'my-embeddedable-widget', to your .aspx markup. For example
<my-embeddedable-widget>Loading...</my-embeddedable-widget>
Importing your application via SystemJS.import from a script tag embedded in the page containing the component selector above. For example
<script>
SystemJS.import('my-embeddedable-widget')
.catch (function(e) {
console.error(e);
}); // not using .bind or => here since aspx tends to imply older browser support
</script>
Note that this presupposes two things
that the 'my-embeddedable-widget' is set up in your SystemJS configuration. For example
SystemJS.config({
packages: {
'my-embeddedable-widget': {
main: 'main.ts' // just an example, could be main.js or anything really
}
}
});
If it is not you can add the config entry above as appropriate for your app (strongly recommended) or just import it directly from the path to the app's entry point such as e.g. my-embeddedable-widget/main.ts or my-embeddedable-widget/main.js.
That the entry point of your widget declares all of its platform level dependencies, such as zone.js and likely various polyfills. For example
my-embeddedable-widget/main.ts
import 'zone.js';
import 'core-js';
// ...
import {platformBrowserDynamic} from '#angular/platform-browser-dynamic';
// ....
This means that SystemJS will automatically load them when your widget is requested. While you could bring them in via separate script tags as we do with the loader itself, making them explicit dependencies of our widget by using ES Modules improves maintainability and allows us to defer loading them until they are required. Furthermore it helps further decouple the widget from the .aspx page. However, if other JavaScript on the page requires these polyfills, you may need to adjust this approach (especially with respect to zone.js because it monkey patches window.Promise)

Related

How to add INSPINIA bootstrap to Ember application

New user to 3rd party bootstrap templates for Ember and need help.
I purchased the INSPINIA admin template from www.wrapbootstrap.com. The download comes with multiple pre-created projects with INSPINIA built in (e.g., Angular, Rails, etc.) but not for Ember. I reached out to the creator to see if they could include a project for Ember and they said no.
So, I am curious, does anyone know how to add INSPINIA to an Ember web application? Is it as simple as ember install bootstrap and then copy the *.css file? Note: the INSPINIA template comes with way more files than just a *.css, and I am using ASP.NET CORE 2.2 for the web API.
Any help is appreciated.
When I did the same thing a few years ago, I bought the theme just for the themed css. I used their less and integrated that into my existing ember build. Nowadays I'd use the scss but it's unimportant.
What is important is understanding that bootstrap js components will not simply work in the context of your ember application. If you want callbacks, events, binding, etc to exist in the context of ember (ie within ember's runloop and lifecycle), you will need to wrap each individual component. Luckily, ember-boostrap does exactly that for you. This addon provides the easiest way for you to pull in your bootstrap scss. This addon also does not use bootstrap's js, but rather is a full implementation of the bootstrap component's in a way that is ember-aware.
ember-bootstrap deliberately excludes bootstrap.js
because the jQuery and Ember ways of control flow and animation
sometimes don't play well together, causing unpredictable results.
This is the main motivation behind ember-bootstrap. It is possible to
import bootstrap.js from bower_components or the vendor folder. This
is NOT recommended or supported, and you will be on your own. You have
been warned!
Once you've gotten the scss preprocessing properly set up in your ember-cli-build.js file, you should be able to use their markup more or less directly. You will need to have some understanding, though, of when you're encountering bootstrap markup (stuff with data classes that will be handled by bootstrap's js). In moments like that, you simply use ember-bootstrap components instead

ASP.NET Core Angular Template: app.module.client vs. app.module.server

Microsoft provides a fantastic template for developing Angular (not AngularJS) in ASP.NET Core as outlined in their article "Building Single Page Applications on ASP.NET Core with JavaScriptServices".
While it's very straightforward, there is one portion of the template that caught me off guard: instead of there simply being an app.module.ts file, there are both an app.module.client.ts and an app.module.server.ts.
I failed to find anything that explains this on the web. Does anyone have any idea why there are these two separate files for the app module, what their specific uses are, how to use them, etc.?
If it helps at all, here is what the full template looks like:
I should note that ClientApp/app/models and ClientApp/app/services are two folders I added for my own purposes; they are not part of the template. Also, app.module.shared.ts is actually very straight-forward and just prevents having to write some code twice, so don't worry about it.
Here is what the two files look like:
Let me start by prefacing that I'm not 100% on the accuracy of this statement, but since nobody else seems to have answered, I'll give it a shot.
Microsoft SPA with Angular 2 utilized Angular Universal to do the AOT rendering. It has now been upgraded to use Angular 4, which doesn't use Angular Universal. My thought is that it instead broke up the app.module.ts into a client and server file to help with AOT rendering.
The app.module.shared.ts file is actually just a global constant that is used by app.module.client.ts and app.module.server.ts. Because it all gets rendered into a couple js files during publication, it doesn't really matter that they split up the app.module file.

In Magnolia CMS, how can each component declare its required javascript files?

I am using Magnolia CMS 5.3.4, the STK, and freemarker (FTL) template scripts.
Some components I have defined relies on specific javascript files. Right now, what I do is that I include these javascript files in the main.ftl template script. I am looking for a way to get them included only if the specific component is present on the page.
I tried to use the jsFiles property in Template Definitions, but it seems it works only for page template definition.
The jsFiles property indeed works only for pages not for components. This is because Magnolia wants to include those files in header already, rather than loading them in middle of the body when component gets rendered.
As a general practice I would anyway recommend combining your js files into one (look at for example plugin loader in resources on how this is done) and set longer time for caching such file so that browser downloads all the script just once for the whole site rather then page by page. The bigger js file you are sending over the more overhead you are cutting off from requesting separate files and better the compression of content for transport will work.
HTH,
Jan

ASP.Net MVC: Centralizing CSS and JS dependencies

I'm using jQuery plugins in an ASP.Net MVC site.
I've often to include CSS and JS files as required by the plugins I use in every page. So I want to centralize all those dependencies in a single place in my app. thus if a dependency for a given plug-in is changed or updated, I'll only have to modify a single place in my app.
I've thought in two possible solutions:
Extend the HTMLHelper with a partial method
like GetPlugin("jqgrid"); that
will print out all the script and
style tags needed.
Create a partial view for each
pluginlike jqGridDependencies.ascx
that will contain the script and
style tags needed.
Do you have any other idea? what do you think of both proposals?
Could http://combres.codeplex.com/ provide you with a framework for this.
My only personal objection to this method is that each individual pages will have a unique JavaScript/CSS file where as if you combined and compressed everything into one and simply used classes and events to trigger the JavaScript enhancements as and when needed your site would run a lot faster.

In an ASP.NET MVC site, where would the JQuery code go?

I'm just getting started with ASP.NET MVC. I'm going to be using JQuery on the website I'm making, but I'm not really sure about one thing: where would JQuery code be placed?
This concerns two things:
Where do I import the JQuery JavaScript file? (I've been thinking that the Master page would be a good place to do this; am I right, or do I have to import it in each view?)
Should all my JQuery code be referenced from the Master page (i.e., I store my code that uses JQuery in a separate .js file and reference it in a <script> tag)?
Thanks in advance.
Anything that you will use in every page put a import in your master. If its something that you will only use on a smaller scale, put the import in the view that will use it.
The key is to not load unnecessary bytes when they won't even be used. I have a universal js file that contains anything that will be used as more common functions across the board imported in my master. Then on a page by page basis, I have only the js imports that I need for that page.
If you put every js import in your master that means it will load that js on every page, when maybe half of them aren't even used for that particular page. That can have a big impact on page load times.
I suggest also using something that can compress the js to a minified version for production. Telerik has their Script Registrar and it's a really nice tool as well.
Add JQuery to the bottom of Site.Master just about the body tag. This means the page will load and not wait for the Javascript.
But the JQuery relevant to each view, but add on a View level.
You should import your JQuery library on the master page. Probably you'll use JQuery on most of the views so having the reference in only one place it's most welcome.
Normally it's a good practice to have all javascript code you can in separated files, as less inline javascript as you have the better. 2 reasons: more readable code and better performance since external javascript files are cached.
My jquery code is placed in the head of the masterpage since it's used on just about every view on the site. The only reason you wouldn't do this is if you're only using the jquery library on a few of your views, in which case there's no reason to load it up for every user.
You should let Google host jQuery for you.

Resources