Great start - DataFromController and HMR

[trilonio]

Great start - DataFromController and HMR

[waynebrantley]

The one I linked is fairly complex to read and reason about due to all the plug-ins it uses.
However, it does have hot module reloading and that is a great development benefit.
It also creates output filenames for the scripts and such that are cache busting and this is a good feature.

Perhaps there is information to gather from that repo or you guys might merge.
Yours integrates the SPA services to get server side rendering so that is a great feature too.

Anyway, good work, just my initial thoughts!

[MarkPieszak]

Hey @waynebrantley thank you :)
I just took it public yesterday, there's definitely a few things I need to add in there, no doubt!

For example, vue-resource and server-side rendering don't work (as resource uses document,etc), so I'm going to be adding request and other vue & SSR capable alternatives so showcase making an XHR request to hit the Web API (that's why there's nothing accessing it yet).

This repo has HMR as well, is it not working for you?

[waynebrantley]

HMR? I looked through everything and did not see it. I did not try your repo, just reviewed it all.

[waynebrantley]

Crap...I keep hitting ctrl enter for a new line...(slack)
Anyway, I can try the HMR, glad to hear you have it.
We need a good solution....and I am not a webpack expert by any stretch!
What about AXIOS for the ajax? Using the prototype of vue, we add to $http as suggested by vue creator and it works nicely.

It is a great start. Few questions:

• Some of the other SPAs in the official repo have a vendor separation so the webpack need not watch and rebuild that all the time. Is that in your plans?
• Interested in the 'best way' to get data from my controller rendered into the vue data model initially. What is the best way for this?
• We are unable to build a 'vue' application - because we cannot start over. However, that does not mean we cannot have some 'new functionality' or a rebuild of a feature that is vue. Additionally, there might be a section of an existing page that has dynamic pieces and we might redo that one thing if we have to work on it in vue. So, keep in mind the 'entire application' might not be vue and I think that is a great way for things that are not 'file new' to get started.
• One of the really nice things about the official angular seeds is they are setup such that if the seed changes (gets updated with better way of doing this or that) you can just pull in the latest seed over the top of your existing project and get all the updates. The current asp.net official templates do not appear to be quite this update-able, but I think this is really nice. This is achieved by making most modifications that are necessary separate js files, etc. This is really different than a 'file new' template that has controllers, etc. If you did the seed right, you can make a template with examples in it based off the seed! Just some thoughts. :-)

I will clone your repo and give it an actual whirl. What are the npm run`' commands for doing everything? is it npm run dev`` etc?

One day of live...didn't notice that...really nice start!

[MarkPieszak]

Thanks, I put it together last night fairly quickly :)
Plenty more updates to come!

As for playing with initial (currently minimal) repo, just fork & clone, open in VSCode, and download those .NET Core dependencies (when the banner pops up), or manually do them in command line.

dotnet restore && yarn install && webpack

Then just hit F5 in VSCode, and it should start it up :)

• Yes, vendor will be split up in an upcoming release, this was just an initial build to try and get everything up & running, I'm going to mirror somewhat similarly after how Steve's templates are, just for consistency.

• There are many different ways, but I'll try to showcase some best practices (or at least a few alternatives for it) when I update the templates

• This scaffolding (like the ones in JavaScriptServices) are more-so for an entire App being written in a given framework, but if you wanted some specific Vue components "sprinkled" in your application, you'd most likely have to go the route of injecting the vue script tag in certain pages, and going that entire route. This would also mean, you'd probably not be using webpack, so no HMR, and other "nifty" features. It'd feel more like the way you do things with jQuery for example.

• Well the Angular-CLI for example is amazing at that, but that's an extremely large undertaking to make. I can turn this into at least a yeoman generator for example, that way when some major updates happen (let's say to the underlying scaffolding), that someone could just pull down the latest generator, create a new Vue app, and move their personal "Client" folder over, while everything else gets updated for them (let's say build things, webpack things, etc). That might be the best way to handle that.

[waynebrantley]

Thanks for the info. I am still in the full visual studio and non .net core application. We will attempt to move to asp.net core (targeting full framework) when the tooling is finally done so kind of in a holding pattern for a few months on that. Given that, I am a bit at a loss for how to have the iis express launch for my 'website' for testing, have the webpack server launch to handle the HMR and have the scripts point to that webpack server. Any pointers?

and going that entire route. This would also mean, you'd probably not be using webpack, so no HMR, and other "nifty" features.

Not sure why that would be the case...if I have a feature that is vuejs, I simply would need a webpack entry for that 'app' that generates the script. That would be hooked up no differently than the 'one big one' you hook up....I just might have 'several apps'. Same is true if it was just 'sprinkled' into a page...although when sprinkling that would more likely be some small inline vuejs. Mostly it is either redo the whole page or not. Then once there are multiple pages with vuejs you could combine those into a shared app - each opening the correct section based on routing....keep going..and one day you have everything! File|New is just not an option for us (and most teams I would think), so I think a progressive way to adopt is important. As an example, we have MVC and webforms in the same app at the same time inter operating with one another. Again, could not File|New....we are 3 webforms away from ditching that...(big YEAH).

Those are my thoughts...if I am way off...I am listening. :-)

[MarkPieszak]

In order to have HMR, you must be using webpack-dev-server, which in the case of this repo, is tied into .NET Core itself (you can see it in the Startup.cs file). So when the project starts, it's proxying those dev-server requets automatically for you into the same localhost. You can thank Steve for that magic :)

If you were using it within an existing .NET framework application, you'd have to spin up the webpack-dev-server simultaneously as your application starts, and the "bundle" file, wouldn't be located on the same localhost port, it'd be on the webpack-dev-server one. You'll run into a whole mess of difficulties & problems when doing all of that.

You'll want to just use regular Vue with es5, include the <script src="vue.js">, and do things that way for an older application. I'm sure there's some crazy ways & loopholes to get everything else to work, but I wouldn't waste your time. I tried years back with Angular1 and an old .NET project, ended up just doing it the es5 & <script> way as well.

Things with .NET Core definitely need some more time to mature, so there's nothing wrong with waiting! Gives you more time to play with Vue itself, or whatever framework you like :)

[waynebrantley]

Ah...makes sense on the middleware piece. So, I would have to remap where those scripts are served from in development....but sounds like might be a whole mess there...but in theory should work.

[MarkPieszak]

Yeah in theory it could work, but it'd be tough.
A lot of times for an existing older application you kind of just want to sprinkle in the <script> files you need, especially with older webforms/mvc .NET projects. If/when you make a big transition you can just as easily clean all that up and webpack, etc. (later on)

[waynebrantley]

Dang it! Ctrl+Enter again. Anyway, perhaps until I am on .net core, cannot effectively do HMR? Will experiment, because that is a great feature. For an older application, including vue.js as a script works until you want to take your first dependency on vue-router, which needs an import...or commonjs or blah...then hole bigger mess.

[MarkPieszak]

With an existing older .NET project, it's pretty difficult to wire it all up. It ends up being more painful than it should be, but maybe you could find some resources on that online (I never really could). It's much easier with .NET Core now, much much easier!