100% this. The moment you allowed the .NET devs to bring their mindset into a fundamentally different space you were going in the wrong direction.
Personally, I think if you want a deep understanding of React you need to first get in a few cycles of working with DOM, JS, CSS, etc. directly. Maybe throw in a functional programming language too. Then try to pick up React.
.NET wakes up every morning to have OOP pancakes OOP eggs and OOP coffee and it can't possibly allow even a hint of that beatnik functional style near it.
I agree for the most part. More specifically you're not going to write functional code in C# and feel particularly good about what comes out. F# is a different story.
Speaking from experience a .NET (C#) backend and a React frontend is perfectly viable. The key is to keep the paradigms in their respective lanes, and if you're going to write code for both, get used to switching your mindset instead of converging the tools.
Is this actually advantageous though over class components? The creator of React said he thought moving to functional components would make it harder for people to learn.
I've found that sometimes hooks can make things less flexible, more verbose, more error prone, and harder to reason about. Sometimes a class might have made things easier to understand.
I loved the fact that `useEffect` could modularize code that was otherwise split between `componentDidMount/Unmount/Update`...but couldn't a new class API also have solved this.
Maybe I just need to read the docs again to remind me. I'm all in for hooks, but it's rare that I think about what life could have been like if we kept class components.
“Advantageous” does not necessarily mean “easier to learn.” I’d say that for people coming from OOP, FP style is certainly unfamiliar and takes more getting used to. But for a front-end program that must always receive/send data to hand wave some other systems in order to do anything useful, it makes things much, much simpler. A whole class of problems disappears. The closer it gets to (state) => UI the easier it is to reason about and debug.
I still think that Reagent, the Clojurescript wrapper for React, is the best version of React available. All of the state management is handled by CLJS itself, and the language design prevents accidental mutation. You can still mutate things where appropriate, but it is always an intentional choice. A framework like re-frame takes this even further, with similar ideas as Redux but with better language support for and enforcement of the paradigm.
> Is this actually advantageous though over class components? The creator of React said he thought moving to functional components would make it harder for people to learn.
At the end of the day you just end up thinking of the chunks of JSX and how they map to parts of the DOM, and who cares if those chunks of JSX are wrapped into a function or a class...
Now when you hire someone new you're going to be looking for React experience but then having to re-train them to think in .NET, or looking for .NET experience but training them to write React... and any time you have dependency upgrades, you're gonna be fighting more impedance mismatches.
Most tech debt that slows down feature development has more to do with the code structure than with the language or framework, so if you're intent on preserving the structure and style I don't know that you should be doing a rewrite at all!