At this moment, I am getting confused day by day. VueJs 2x was fun, we could use it as a library like react (just plug in and get going, on any existing multi page site) by setting up build tool prior to coding... Assuming we're choosing the build tool route.
Has VueJs3 taken the Angular route of focusing more on building a framework more than a library?
I am asking this question, as I have been trying to research on how to set it(VueJs 3x) up on my existing multi-page app as a library. All tutorials seem to inform about setting up a "Vue app" with build tool (vite) using npm init vue#latest like one is building a complete SPA app.
My Multi-Page App is build on Asp.Net Core Razor pages, and all pages are Razor based .cshtml, And npm init vue#latest assumes one will load the app using the generated index.html which is not ideal for my case as pages are .cshtml.
Is there any Tutorials I can use to learn more about using VueJS 3.0 on an existing MPA like a php, django or any other MPA apps?
You are correct, they are moving towards a framework and you will have to have their CLI to use Vue 3x. You wouldn't be able to use Vue 3x unfortunately on asp.net but you can use Angular.js or Knockout.js (I prefer Angular.js when using asp.net razor pages)
Related
I'm trying to figure out the best way to integrate a front-end angular application with .net core back end API.
I've already seen two different methods and wondering why use one over the other?
Use the ASP.NET Core with Angular project template (within visual studio) + ASP.NET Core Web API project template.
Use a basic stand alone Angular application + ASP.NET Core Web API project template.
Any thoughts or information is much appreciated!
The Angular project template offers the convenience of managing the two apps (API backend and Angular frontend) as a single unit in one solution, and the project can be built and deployed as a single unit.
If you'd like to create and build the backend and Angular frontend apps separately, and host them on different server or sites, or you just want to create an Angular frontend to consume an existing API(s) backend, you can use Angular CLI to create a customized client app without using the Angular project template.
It's actually very good question, i used to create a stand alone both of front-end and backend parts and work with them separatly. It's makes me able to think only about that part or about only that feature i'm working on whatever it is.
I have created a server-side rendering react app using .net core (which is already given by .net core).
I want to have more than one react app inside .net core app.
I didn't get any related links to it.
Please help me with this.
Thanks
You can use webpack to make multiple react builds from different react projects. Then when you use SSR in your .net core controllers, you can set different views using multiple view layouts or just views, each targeting a different react app. - Of course you'll need to dig deeper since what you are asking is a lot of setup and coding but this is one possible solution.
Write your react apps / if you are using create-react-app, use the 'eject' feature to get the hidden files so you can expand on them.
Use one Webpack config to make separate builds
Make multiple controllers with SSR or one that selectively issues view pages based on your use case - SPA Services SSR is gone in .net core 5, you can still use core 3.1 or there are many libs in the works and require some reworking your startup setup and controller
Add View pages or Razor pages targeting the react app
This is not the only way but will get you going with the least amount of fuss.
Webpack is the key here, hope this helps you in the right direction.
In ASP.NET Core 2.2 it was rather straightforward to have an ASP.NET Core website with React front-end and working server-side rendering - since SSR was supported out-of-the-box in the ASP.NET Core+React template, which internally run the NodeServices to executed the javascript using node.
However with ASP.NET Core 3.1 things are not so easy anymore, mainly because the SpaServices and NodeServices classes are declared as obsolete and will be removed with .NET 5, according to this link. So no javascript execution with node from C# anymore.
Now, besides the information, that the server-side rendering suggested in ASP.NET Core 2.2 is now obsolete, the only suggestion how to go forward I found is from above article:
To enable features like server-side prerendering and hot module reload please refer to the documentation for the corresponding SPA frameworks.
But if I understand correctly, to have react-based server-side rendering, I need to have a node.js server which will perform the rendering on the server-side.
Does that mean, that if I want to have an ASP.NET Core 3.1 website with a React front-end with SSR - I should have one ASP.NET Core project for the WebAPI, and another separate Node.JS project for the front-end with SSR?
And then deploy them on two separate Azure AppServices?
Is that the recommended architecture for ASP.NET Core + React projects?
I came across exactly the same problem. It took me a few weeks to create a new set up where frontend is separate from the backend.
I published the prepared boilerplate on GitHub and wrote a blog posts that explains how to enable server-side rendering with ASP.NET Core and React in details. The solution is a combination of CRA (Create React App), Storybook for CRA and a standard ASP.NET Core MVC template.
To make a long story short I built my custom asp-prerender-module and asp-prerender-data attributes. They communicate with an Express server based on Node.js to get the rendered HTML. Thereafter the HTML served to the browser gets "hydrated" with actions.
After spending some time researching, that are the current options:
Live on .NET Core 3.1 with the NodeServices with an obsolete flag
Create separate projects for back-end (asp.net) and front-end (node.js)
Fork/copy NodeServices and maintain by myself
Hope that a there will be a community driven fork of the NodeServices in the comming months before .NET 5 release were it will be removed eventually
You can use a new library to invoke JS from .net which is
https://github.com/JeringTech/Javascript.NodeJS
You can use SSR on .net with the above library Razzle described here:
https://dev.to/pruttned/integrating-react-into-asp-net-core-using-razzle-with-all-the-goodies-like-ssr-routing-code-splitting-and-hmr-part-1-2-34g8
BUT at the time of writing I find that there is no information on how to deploy such an application.
Reactjs is working on the Server component to stream partially rendered UI in the form of JSON data to clientside. https://github.com/reactjs/rfcs/blob/2b3ab544f46f74b9035d7768c143dc2efbacedb6/text/0000-server-components.md
I think for future integration of Server component, it needs a native NodeJS process to handle server rendering.
I'm working on a big project. I'm using asp.net core 2, web api and angular 5 (spa).
The project is somewhat modular but not in front-end part.
What I need is that: There is a container that is main page and include some basics like nav-menu and etc.
whenever I put my extension dll(another core project) in sub folder it will load with all things including angular modules.
For instance I have a project, include Contact Module, core project has no dependency on it. Contact Module will load its apis and its UI as well(add some menu in nav-menu, sub menu and etc).
There might be a way that I'll be able to inject Angular module from another project to main project.
Current folder structure is like this:
I'm looking for best solution, Any ideas are welcome and thanks in advance.
I am trying to build an Enterprise System that will evolve over time with features being added as time progresses.
I am planing to go with ASP.Net Core microservices architecture with Angular for the UI. I am unable to find a sample that shows how we can introduce new modules without changing any existing angular code.
I was able to do this in the traditional winforms applications using technology like MEF and dropping the dll in to a folder that shell watches and loads.
Looks like there is no such example using the Angular framework. So I was curious if its even possible to achieve an architecture as shown below?
Module are the asp.net core services that serve the angular files that the shell can render and Service are the logic services that are used by the applications themselves.
I did see this post, that is close to what I want to do, but I am not sure if this is even the right solution being discussed.
Any pointers appreciated.
I tried to implement a plugin architecture making use of ABP, Angular and ASP.NET Core: https://github.com/chanjunweimy/abp_plugin_with_ui
Basically, I developed angular plugins using different angular application, then I dynamically add them together.
More Information on how I achieve it:
I have 2 angular-cli application, 1 is the main angular cli application, and another is the plugin angular cli application. The problem we are facing in Angular-cli plugin architecture approach is how we integrate them.
Right now, what I did was, I run ng-build on both of the applications, and put them into a "wwwroot" folder, which then hosted in a ASP.NET core 2.0 server.
abp_plugin_with_ui is a repository which works on developing a plugin which contains both the backend and Angular cli. For the backend, I made use of the aspnetboilerplate framework, which the frontend is developed using multiple angular-cli application.
To have the main application integrated with the plugin application, we have to run "ng-build" on both of the application (note that we have to change to href of the plugin application as well), then we move the built contents of plugin angular cli application, to the main application "wwwroot" folder. After achieving all this, we can then run "dotnet run" to serve the ASP.NET Core 2.0 Web Application to host the static files generated by "ng build". In this approach, plugin Angular UI applications are independent from the main Angular UI application: they are connected using IFrame.
Recently, I realized that we could create components on the fly, which means that maybe it is better to download the "NgModule" and create that module dynamically instead. This option is better because plugins UI would directly integrated into the main application UI. I am still trying out this method.
Another option suggested by #bruno was to develop the UI in SOA instead. This means that, we could choose not to separate the UI into plugins, but separate them into modules as independent service instead. You need to have a so-called "IT/Ops Client" that could help you manage what view to show in the UI, and the main UI is just a frame/template that will show what "IT/Ops Client" want to show. Using this way, we could register these services, and chose what service to be used. This is the microservice architecture and might be closed to what you want. The microservice expert Udi Dahan has a post blogged about this (link: http://udidahan.com/2014/07/30/service-oriented-composition-with-video/)