Web Components/Redux with .NET Core MVC viable?

Question

I'm currenty building several new themes using NopCommerce, a .NET e-commerce platform using the MVC architecture.

NopCommerce exposes a lot of services to you for communicating with the db, and is itself built with the Entity Framework code first approach.

Overall, I think NopCommerce is pretty well-rounded, the platform is pretty extensive and very easy to get up and running, decent developer experience and whatnot. The only thing I am missing from the platform is a built-in way of creating asynchronous views.

The NopCommerce team currently uses a lot of jQuery for updating some certain DOM-elements, such as a cart drawer, cart quantity indicator, toasters and some other things. I would prefer to exclude jQuery from the project completely, as I don't feel new developers at work should have to learn jQuery in 2021.

We have discussed using some sort of front end framework for asynchronous UI components for some time now, but are hesitant to include React or Angular due to 1) the bundle size and 2) the need for our developers to also learn these frameworks. Preact was an option but painpoint 2 was still being hit. We also don't want to do everything "vanilla", but if we would, one concern was how long time it would take to craft such an implementation compared to the benefits it would give.

We came across Web Components and noticed that the support is pretty good now, and there is an official polyfill for the V1 spec. It also results in pretty neat looking DOM-structure, and is very lightweight (<0.5kb), and also has the webcomponent-redux npm package available for dead-simple redux-bindings!

Initially, it looks promising, but again, questions are raised.. Is the time to make this work worth it? It probably wouldn't take very long to make one async components in this manner, but since you can make web components in so many ways (https://webcomponents.dev/blog/all-the-ways-to-make-a-web-component/), I'm very unsure what a good approach would be for our specific case.

As an example: Basically, we are going to take the existing (synchronous) "GetProductsByFilters" endpoint, and rewrite it to return JSON instead, which our Web Component would then request when filters are changed by a customer, then rendering the new product grid asynchronously instead of rerendering the page.

If anyone has any experience with .NET Core and Web Components, and with redux in particular (or a self-built implementation?), I would appreciate any input you have!

Bonus: Also interested in thoughts about a monorepo for said Web Components!

All the best

Answer 1

Here are some of the questions you should ask yourself. Answers to these questions would go a long way towards helping you make up your mind.

Is NopCommerce primarily server-side rendering or client-side rendering?

There are two ways to work with ASP.NET MVC. The first is to use it as a JSON data source and run the entire application in the browser, which is what Vue, React and Angular do. While you can render a "skeleton" of a page on the server and populate it with a frontend framework, this requires coordination between the server and the frontend which doesn't appear to be present in NOPCommerce.

The second way is to create your pages on the ASP.NET MVC server and push them to the browser, directly, which is probably what NOPServer is doing. That's probably why jQuery is being used; it has a different use case than Vue, React or Angular. Neither way is necessarily better than the other; they just have different advantages.

Do you really need an asynchronous component?

Maybe you do, maybe you don't. You have to balance the need for what NOPCommerce already has with what you'll need to build, and there might be several ways to get that asynchronous functionality. Using a full-scale frontend framework just to get asynchronous functionality seems like overkill, but 150K to 500K to load React or Angular doesn't. Are you primarily running on mobile devices? Are you having performance problems? Maybe these performance problems can be solved another way.

[Web Components] looks promising, but again, questions are raised ...

There's an easy, reliable and comprehensive way to answer those questions: stand up a small prototype and see how well it holds up.