Again, we need basic documentation for the new SpaServices packages.

[empz]

It's been asked before, but you guys just seem to close the issue without providing anything useful. I think it's not that hard to add a section with, at least, some basic usage examples.

We need docs for:
Microsoft.AspNetCore.SpaServices
Microsoft.AspNetCore.SpaServices.Extensions

Thank you

@Rick-Anderson edit 3.7K PV

Additional related issue: Obselete Functions #17338 by @ibrahimuludag

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: c771657b-a681-8e8a-52ed-3d974520f528
• Version Independent ID: 318e32fc-62f2-c0e5-4658-5729aad48c91
• Content: Use JavaScript Services to Create Single Page Applications in ASP.NET Core
• Content Source: aspnetcore/client-side/spa-services.md
• Product: aspnet-core
• Technology: aspnetcore-clientside
• GitHub Login: @scottaddie
• Microsoft Alias: scaddie

[guardrex]

@scottaddie ... My remarks on the other issue were ...

#17902 (comment)

[jgullickson]

The following talk contains some very basic instructions for setting up SpaServices.Extensions with a Vue.js SPA. In lieu of real documentation, perhaps this will help folks get started: https://youtu.be/DH2yUVQDB0I?t=1975

[MaximDelyukin]

@guardrex Any news on where is the documentation for Microsoft.AspNetCore.SpaServices.Extensions ?

[guardrex]

I haven't heard anything. @scottaddie may know more.

[shawty]

Another call for doc's please folks.... anything?

[guardrex]

No new information that I'm aware of, but I found a companion product unit issue for this request 👉 dotnet/aspnetcore#19098. The last remark there from management is that a member of the community would need to volunteer to write docs on this part of the API outside of the minimal API docs ...

https://docs.microsoft.com/dotnet/api/microsoft.aspnetcore.spaservices

... and let's cross-link the source ...

https://github.com/dotnet/aspnetcore/tree/master/src/Middleware/SpaServices.Extensions/src

[shawty]

So with all due respect, what the management team are saying is:

"Now we have blazor and other MS approved/sanctioned ways of creating UI, preferably using C#, bugger those who are still using silly JS frameworks."

While I agree, that Blazor is a superior tech to any of the JS frameworks out there, and all new projects I'm doing, use Blazor and wasm, the fact remains that I do still have older apps that are built (In my case) using an Aurellia JS based UI.

Deprecating the old API, and removing it at core 3.1 essentially means that these older apps, will never get upgraded to .NET5 because there is no support for them to integrate building the UI at the same time as building the main code base, and we all know what I.T dept budgets are like, in most cases if the UI works, then your not going to get a budget to re-write it from scratch.

This is going to lead to more and more security holes appearing in the UI layer in many of these apps, and I know right now where most users are going to point the fingers when their app gets hacked.

While I would quite happily volunteer to write the doc's, there are 2 things preventing me from doing so.

1. Time commitments, that is I have little spare as it is with my work and existing .NET community commitments

2. I have no idea of the intent and work load these API's where designed for. For reference, I was pretty much exclusively an AurelliaJS user, I have no idea on React and Angular stuff, NPM I can just handle, but that's it.

It's all very well folks commenting "read the source code", and while we can all do that, we all as professional developers also know that unless we have a view inside the mindset of the original developer of the feature, where not going to get very far, so at absolute minimum, a bunch of samples showing the features being used would at least provide a platform for those interested in writing something that will help, to study and make some notes from.

I do however have a more sane suggestion.

It's quite apparent that MS is no longer interested in providing the SPA/JS features and even looking in the "non deprecated" API pages linked to above, there are a number of instances of "added in : 2.1" "deprecated in: 3.0", which leads me to believe that even this up to date replacement won't last longer than is wanted.

That in turn leads me to question, if it's even worth writing any docs, if I was to decide to do so.

So how about, we do something different instead?

We already have a working API, we know it works, and it works fine, why don't we just say "Let's NOT deprecate it" and move that as is into a separate assembly, that continues to work with future .NET versions.

We don't have to add anything new to it, it does the job it needs to, and it does it well... so freeze the code, but remove the deprecation warnings.

Anyone who needs to use it can do so by including the NuGet, and we all ready have docs for the older version, so the doc problem is solved also.

My particular use case is quite simple, making sure that the front end build is run, and generates it's output when my app is run in dev. The API's will never get run in prod or stage, as that part of the build process is handled by the CI/CD system.

I suspect that other use cases for npm/react/angular are all the same or at least very similar, and was something that the old library did, and did very, very well (That's why we started using it)

Of course this is just my thoughts on the subject, and there may be large chunks of the picture I'm missing, so I'm ready to stand corrected if that's the case, IMHO however, it's not a difficult thing to provide, and it's essentially just automation, and as an automation/tooling thing, then if these API's do indeed have no future as I suspect, then perhaps we need to think about adding some form of npm runner assistance to the dotnet core cli.

[guardrex]

@shawty ... Since there's an open product unit issue, you'll probably get management to comment on your remarks on their issue.

Normally, a doc issue would only exist on this repo, but they keep some doc issues open over there because the product unit would need to write the initial content for us or at least provide specific guidance over here first. Mostly, they plan and execute their work from their repo, not this one. Once they write the initial content or provide specific guidance, then they would close their issue. We then work any raw content that they supply into the docs over here on our issue.

Anyway ... my recommendation is to just copy-'n-paste your last comment into a new comment on their issue (dotnet/aspnetcore#19098). There's no guarantee that they'll respond, but you have a better shot of getting their attention over there.

Note that everyone is still out on vacation 🏖️ for the most part. Even after everyone gets back, there's a large backlog of new issues that came in over the holidays. It might take days ... weeks ... or a month ❗ for them to dig out ⛰️⛏️ and get to your remark. Initially, it might seem like they're ignoring you, but they might just be just crazy busy on return 🏃😅. If you don't get a response in January, you can always ping them again there in early February.

[shawty]

@guardrex Yea, I get that Luke (The whole still on vacation thing) :-) I don't mean to sound negative about all this, but it gets a bit frustrating sometimes. :-)

I'll wait a week or so, then copy my note over :-)

Right now I need to finish of developing a method of running my own NPM stuff so I can finish off this upgrade, or at least test the process.

If it works, I'll most likely even just release it as an OSS thing :-)

Thanks for your input though.

Shawty

[brookton]

I'm in need of documentation as well. Deprecating Webpack in favor of .extensions with nothing to explain how to implement it, really not great.

[brookton]

The docs still instruct you to use a deprecated practice. https://docs.microsoft.com/en-us/aspnet/core/client-side/spa-services?view=aspnetcore-5.0#webpack-dev-middleware

No explanation on how to implement it properly now.

[shawty]

@brookton - Frustrating as hell to be fair.. BUT with some relief I ended up doing it this way:

1. Install the NPM Task Runner extension into VS (I'm using 2019 and it works fine)

2. In your package.json file add a "scripts" section, containing the scripts you want to make available EG:

3. Open the "Task Runner Explorer" in VS (click the circular refresh icon if nothing shows when you open it), then right click on the script actions showing in the task runner and assign them to the correct stages in you build process:

OR if you want to do it the long way, use the visual studio recognised "package.json" extension tags, to configure your build direct in the package file:

NOTE
If there are any errors or corruption in your "package.json" file then task runner explorer will show nothing, and it won't refresh, I found this out the hard way :-)

After this (And this was where I was relieved), I was actually now able to remove the webpack code from my startup class, and that FINALLY meant I could upgrade the aging netcoreapp2.0 code base to netcoreapp3.1 and beyond :-)

[timrobinson33]

FYI you can use the Visual Studio template to create a React project and it generates a call to UseReactDevelopmentServer() from the namespace Microsoft.AspNetCore.SpaServices.ReactDevelopmentServer which is part of Microsoft.AspNetCore.SpaServices.Extensions DLL.

That all still works under .Net 5 (though the documentation for that method stops at asp.net core 3.0), so anyone using React should find it quite easy to upgrade.

[shawty]

@timrobinson33 Same with the Aurellia & Webpack stuff (But that comes with a hefty warning saying 'It may be removed' not 'it will')

I actually found the best thing to do is to just go with the Task Runner Explorer approach, then where not dicing with API's that may go away at a moments notice when MS feels they no longer have value.

Personally, I would like to see "Deprecated" and "Unloved" API's put in their own NuGet package, and handed over to the community, that way the community can pick up where MS left off, I fully understand the whole not wanting to keep things around and support them longer than they have to, but right now ALL of this JS support stuff is in Limbo.

Something NEEDS to be done, some decisive action needs to be taken, so that those of use who do want to use it KNOW where we stand.

Task Runner works for me right now, and I KNOW where I stand with it being available in future.

It's not a question of being able to still use the feature, it's about knowing if we do use it, will it still be there in 1/2 years time? and if it's going to be, can we have at lest some basics that the rest of us can then take and move forward for the benefit of everyone else.

I have actually thought about gutting the API's out of the runtime myself and making a new package that works with everything higher, but I just don't have time on top of everything else I do.

[fdrobidoux]

I'm also very confused as to the validity of SpaServices packages in a new dotnet project.

My company doesn't want us to use Blazor for a single-page application because it's "too bleeding-edge", but was fine with us using ASP.NET Core 3.1 with VueJS.

However, with what I'm reading right now, it's not much better to be using tech that's (being) deprecated from later .NET versions.

I'm starting to wonder if I should push for Blazor instead...

[shawty]

@fdrobidoux if it's any help, I'm currently working on a huge project re-write for a client, and we're having fantastic success using Blazor Server side along with open source Radzen Blazor UI controls.

The docs are a bit lacking for the controls, but all the source is available on github, and if you have a company (Like my client) who wants to pay for support, Radzen do a really good paid for enterprise service along with a no-code editor (That produces apps, which can once created be loaded into normal VS tools)

Serverside Blazor IS in my opinion what I think WebForms could have been, you have a mix of SPA like functionality, but you can should you wish easily break out into razor pages with a very familiar code behind model where needed (I have a sample on my github doing this where I use razor pages to wire up cookie auth) , everything runs on the server so if you have good server hardware, you get a really nice responsive app, without any code having to make it to the browser as happens with many of the JavaScript toolkits.

If you want pure execution on the device itself inside the browser, then you do want to be using Blazor Web-assembly, I have to confess I've not done much with WA in Blazor yet, but there's plenty of us who have in the Blazor/Gitter chat room, you just need to pop in and ask.

If you DO still want to use VueJS, then take a look at my previous reply, using an NPM script to launch the VueJS (or any JS) build tools, is perfectly feasible using the NPM task runner, it replaces all the cruddy JS API MS had in and are fiddling with, but still let's you call things like your JS build only when needed, just as the built in C# API's did, but gives you more flexibility.

So far I've used the NPM method to run WebPack, Parcel and a whole host of others with no issues.

[sethidden]

Man, why is NodeScriptRunner internal? I just want people's devserver to start when they run Startup.cs - ie

if(env.IsDevelopment) 
{  
[run npm run whatever-i-want on port 8085],
 app.UseProxyToSpaDevelopmentServer('https://localhost:8080' 
}

I just want to run an arbitrary npm script - I know what port it'll start on. Right now it's only encapsulated in ReactDevelopmentServerMiddleware and AngularCliBuilder.

What if you use Vue (with vue-cli, or with the new vite), what if you use some http-server package from npm? Seems like right now you can only run an "arbitrary" script if that script starts react dev server or angular dev server

Is creating an npm runner from scratch is the only option? Like people did here:

• https://khalidabuhakmeh.com/running-npm-scripts-from-a-dotnet-core-process#the-npmscript-class
• https://github.com/EEParker/aspnetcore-vueclimiddleware/blob/65b23b9afb648a1afb2659efbbd6c61a17471cb7/src/VueCliMiddleware/Util/ScriptRunner.cs#L19

[shawty]

@sethidden as I keep saying... look at my replies above. :-) Get rid of the calls to the JS stuff MS have now pulled from .NET/(core) and use the NPM task runner

Go back 5 comments to my January one....

See:

https://codepunk.io/using-task-runner-and-npm-tasks-in-an-asp-net-core-project-in-visual-studio-2019/

and

https://www.danylkoweb.com/Blog/advanced-basics-using-task-runner-in-visual-studio-2019-RJ

for more info....

As much as I would LOVE for MS to put this functionality back into .NET it's not going to happen, the task runner however allows you to do a whole lot more than the JS helper API's ever did.

[gcjuan]

is the expectation from consumers of this package that they will have to implement their own Server side rendering now that ISpaPrerenderer from .NET 3.1 is deprecated and SpaServices.Extensions only has a builder ISpaPrerendererBuilder?

[anderejd]

This documentation is what helped me:
https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.spaservices.spaoptions?view=aspnetcore-6.0

The code that seems to work for me is:

app.UseSpaStaticFiles(new StaticFileOptions
{
	FileProvider = new PhysicalFileProvider(mainGuiPath),
	RequestPath = "/some-extra-directory"
});
app.UseSpa((builder) =>
{
	builder.Options.DefaultPage = "/some-extra-directory/index.html";
	builder.Options.DefaultPageStaticFileOptions = new StaticFileOptions
	{
		FileProvider = new PhysicalFileProvider(mainGuiPath),
		RequestPath = "/some-extra-directory"
	};
});

For my case it was important to set DefaultPageStaticFileOptions.

[Rick-Anderson]

@empz @shawty @jgullickson @MaximDelyukin @brookton @timrobinson33 @fdrobidoux @sethidden @gcjuan @anderejd does dotnet/aspnetcore#44600 help?

[shawty]

@Rick-Anderson potentially, but don't have time to read now, will have a look at earliest opportunity. Been a long time since this issue was raised anyway and have been using NPM approach detailed above for a while now.

[gcjuan]

@Rick-Anderson is the suggestion from the link you posted only available in .Net 8?
Also, is Microsoft.AspNetCore.SpaServices.Extensions now also deprecated in favor of Microsoft.AspNetCore.SpaProxy ?

[Rick-Anderson]

@Rick-Anderson is the suggestion from the link you posted only available in .Net 8? Also, is Microsoft.AspNetCore.SpaServices.Extensions now also deprecated in favor of Microsoft.AspNetCore.SpaProxy ?

.NET 6+ AFAIK

[peabnuts123]

I can't even find what functionality Microsoft.AspNetCore.SpaServices.Extensions offers, or even what classes are contained within it. The post announcing the deprecation of the old namespaces just says that it should be used instead. What does it do? How are people figuring out how to use it … ?

[shawty]

@peabnuts123 figuring out how to use it? ... THIS ... is an invaluable tool

[mkArtakMSFT]

Closing as some of this functionality has been deprecated and we don't have plans for expansion in this area.