Aspnetcore-angular-universal: Consider modifying solution structure

[ketrex2]

Please consider revamping the solution structure and move the project to an src folder and include a test folder. This would align with the structure of the ASP.NET Core libraries as well as the de facto structure for most development teams. It would be great to have unit testing projects exist right alongside the current project.

As an example, here is the MVC repo from the ASP.NET Core team: https://github.com/aspnet/Mvc

If interested, I'd be happy to submit a PR.

[MarkPieszak]

@Ketrex Thanks for the feedback!
Anything we can do to align things better would be a great idea!

Were you talking about having the solution files at the root level, and the project itself being in ~/src/ (with /src/Client/ /src/Server/ being inside of src?) This all might help the project not look as daunting at first glance as well :)

As for tests for the Server-side that'd be an excellent idea as well! There aren't any currently.

If you'd like to help of course! 👍
Help is always appreciated!

[ketrex2]

That is indeed my proposal. :)

I'll get started on a PR.

[MarkPieszak]

Excellent, I'll take a look when you're all set! 💯

[markwhitfeld]

I definitely agree with this restructure but I feel that it should go a bit further...
I would say that the .net core app and the Angular 2 SPA should live in separate folders. At the moment it feels like the "src/Angular2Spa" folder is a mash between the two projects.
I would split the .net core app into a "src/AspCoreServer" folder and have the only link between the two as the dist folders that are served up by webpack.
Is there something fundamental I am missing here? I think this should work.

I'm happy to submit a pull request if you think the change makes sense.

[AbrarJahin]

I also agree with @markwhitfeld

[MarkPieszak]

Definitely a good idea!
Well one thing we could definitely do is take out the WebAPI and such from within this project and into it's own Project, but we'll need to make sure all /api calls are proxied to this new address (for development, and production environments as well).

I'm currently moving away from the TagHelper asp-prerender in the 4.x re-work, and moving that logic into the HomeController. So @markwhitfeld if you wanted to take a crack at it, can you just make sure to leave the MVC Controller portion within the project? (We need it for the Universal SSR/server-side rendering).

So basically all we'd have left is StartUp.cs, Server/Controllers/ and the Views/, so very barebones .NET Core just to actually serve the project.

[markwhitfeld]

I have done the restructure and got the project compiling. The one last thing I am fighting with is the "dotnet publish" with the relative paths. I will submit the pull request shortly.
I haven't had a chance to look at separating the api bit.

[markwhitfeld]

I'm not quite sure how you were wanting the WebAPI to be split out, so please take it from here regarding that. Thanks for an awesome project!

[MarkPieszak]

Let me take a look at your PR soon, need to make sure everything is still working!
And thanks, glad you're enjoying it!

I'm hoping to finally have the time to spice up the styling and a few other clean-up things, but it's hard to find the time with work and all! :(

[markwhitfeld]

Just one last thought on the structure... In the angular app it is not clear how it would scale regarding adding multiple features. The recommended file tree structure in the Angular2 Style Guide talks about a folder per feature approach.

I can really see the containers and components folders devolving into everything being in the app module and not into separate modules for different features. Here are some ideas on project structure for Redux style apps:
https://marmelab.com/blog/2015/12/17/react-directory-structure.html
https://medium.com/front-end-hacking/structuring-react-and-redux-applications-255361d24f84#.c36i1jbj3

Do you think it would be worth adding this sort of structure to the sample app?

[markwhitfeld]

Hi there. I know that this issue is closed now, but I noticed that the folder structure is back at the old structure with the move to Angular 4. Was this intentional?

[MarkPieszak]

At least for the time being to get everything up and running, it keeps azure and other builds a little simpler as well. Could easily bring the different solution back in, need to get everything back up and ready first then we can figure it out.

Hope it didn't mess up your transition 😓

Also wanted to keep it simpler for those trying to upgrade from JSServices for now

[markwhitfeld]

Hi @MarkPieszak
I have made the necessary changes locally to update the new project to the improved solution (and folder) structure. I'm happy to create a pull request for this if it is something that you would still like to do in this project.
This would result in a folder structure of:

• src
  
  
  
  • AngularSpa
  
  
  • src
    
    
    
    
    
    • app
    
    
    
    • containers
    
    
    
    • ...
    
    
    
  
  
  • node_modules
  
  
  • ...
  
  
  • AspCoreServer
  
  
  • Client
  
  
  • wwwroot
  
  
  • ...
  
  

[markwhitfeld]

@MarkPieszak Please let me know soon if you would like me to create a pull request for this so that these changes stay relevant.

[MarkPieszak]

Will do, I'm meeting with Steve Sanderson this week to talk about overall direction and integration between aspnet and angular so hopefully I'll know more soon!

[markwhitfeld]

Hi @MarkPieszak
Hope your meeting with Steve Sanderson created a clearer picture for the project.
Do you have a verdict on the project structure?
My basic approach to the structure is to view Asp.Net Core as a host server which is used to serve up the app, and that the app stands separate to the server. I suspect that this might no align to the closer integration goals for Javascript services and Asp.Net Core. I'm interested to see what the approach is.

[MarkPieszak]

Hey @markwhitfeld sorry for not responding sooner!
Yes it went really well, and at the moment I'm just trying to come up with solutions to get AoT and fixing up any other prod build stuff into JavaScriptServices. As for project structure I think Steve wants to keep it the way it is for all of those projects as they're a little bit different than the traditional aspnet project repos. The JavaScriptServices repo will soon be on a more rigid aspnet schedule where releases will be only done quarterly I believe. So hopefully here is where we'll be able to experiment and improve on the platform, to get releases pushed up to there.

For this repo, my goal is to try to showcase and help people get the essential add-ons / extensions in this repo, and trying to keep this as close to JavaScriptServices as possible will make that easier for people. (Which luckily lately it's fairly similar, at least in structure).

Instead of both him and I maintaining two monster repos (that could have thousands of different issues), I think it'd be easiest to try to keep them closer together, at least that way we can tell where a bug/issue is coming from.

Anyway apologies for the delay, and thanks again for the great previous work!
Who knows maybe in the future the repos will all go back in that direction :)

[markwhitfeld]

Thanks for the feedback!
I suspected that the repo would be aligning a bit more with the 'dotnet new angular' template when I saw Steve's NDC Oslo talk. It looks like they are getting really close now.

PS. It might be worth adding a section to the readme file on the motivation to have this project as opposed to the 'dotnet new angular' (ie. is this supposed to be the place where you would get the features before the template, or a more stable project with battle hardened approaches, or more of a showcase of the Angulr aspects, etc.)