I am thrilled to announce that a custom dotnet template is now available to quickly build real-time, cross-platform, React SPA on .NET Core 2.0 back-end, communicating via WebSocket (SignalR)!
The template is available from NuGet (or this github site). You’ll need to install Node.js and .NET Core 2.0 SDK first, then use this command to install the template locally:
dotnet new -i DotNetify.React.Template
Use the template to create a new project with the name ‘MyApp’:
dotnet new dotnetify -o MyApp cd MyApp npm i dotnet run
There are standard dotnet templates for React SPA available from Microsoft, but it’s my hope that this template will bring you more value in terms of simplicity, feature richness, and a whole new way to web development.
I am a fan of keeping things simple (but not simpler!) and the template reflects this by having the programming model lean and keeping external library usage to the minimum, while offering feature parity to the standard templates, and then goes beyond that.
Routing with deep links (can be dynamically configured on the back-end).
Webpack hot module replacement + dotnet watch (automatically compile changes to the C# code.)
The template is powered by my open source library, dotnetify, which provides server-side MVVM abstraction for web applications. The pattern is an improvement over the MVC pattern for the following reasons:
It allows for better separation of concerns. Server-side controllers often have too much responsibilities, since it needs to ensure requests are routed correctly and to provide all the necessary data for the view engine to render the responses.
It simplifies development. When the orchestration logic belongs exclusively to the view models, the controllers then become very thin and simple, even collapsed into just a single end-point whose only job is to route requests and responses, and another part of the middleware that requires no custom programming.
It provides greater testability. View models are not coupled with the mechanics of data transport or view rendering, and therefore can be much more easily tested in isolation.
It makes the client-side view thin. A view model abstracts its view and drives every data-driven operation so the logic in the view is minimized, to the point that it only handles platform-dependent user interaction.
A crucial part of MVVM is the facilitation of two-way data binding that allows the view models to be thoroughly decoupled from the views. DotNetify uses SignalR, which implements RPC over WebSocket (can degrade to HTTP long polling when WebSocket is not available), to provide this capability.
Ever since my first announcement of dotNetify-React earlier this year, I’ve been lucky enough to have people expressing interests, appreciations, using it in production, and contributing ideas for the roadmap. There are cool things planned for the future. I am excited for you to give it a try and get your feedback!