Migration to Code Behind Approach ( *.razor to *.razor.cs )

[sbwalker]

Essentially this involves modifying all of the Razor components to move from the single file model Oqtane currently uses, to a model where the markup is in a *.razor file and business logic is in a separate *.razor.cs file.

I would like to get some feedback from the developer community on their preferred approach.

Microsoft's stance on the code behind approach is "Either component authoring style is fine. They’re mostly interchangeable. We prefer the inline style, so that’s what we use in our templates and samples. We disagree that this encourages bad coding practices any more so then if you had a code behind file. A .razor file represents a single component class so any UI logic is part of that component’s concern and makes sense to live in the same file. You shouldn’t mix business logic in your UI layer, but that can happen just as easily if you’re using a code-behind file. The Vue community uses the inline style and do just fine. But we also understand that ASP.NET devs have been taught for a long time to use a code-behind file and many prefer it, which is totally fine."

So its really a matter of developer preference. I think the bigger question we have to ask is which style will appeal more to the developer community who we expect to attract to Oqtane? The JavaScript developer community such as Vue is not really the target demographic for Oqtane. But if ASP.NET devs examine the Oqtane source code and have a negative reaction to the single file model based on their prior experience with WebForms, MVC, etc... it will hinder adoption of Oqtane.

The effort to migrate to a code behind model is not complicated or large - it is just repetitive. And since it touches a lot of code there is the potential to affect overall stability. Personally, I prefer to only modify working code if there is an actual business rationale or benefit. The business rationale or benefit for this item is not clear... so I am asking for broader feedback from the community to help make a decision.

[hishamco]

I prefer to use the code behind whenever it's possible to separate the logic from the UI, of course it will feasible if there's a lot of code in the component itself

Again separate the code from the view is nothing but a partial class the will be merge during the compilation time, we already follow this in Blazor WebForms Components which makes the code clean and clear

Thanks

[kevind2000]

Just had a look the Blazor Mobile Binding, which is using Xamarin Form (XAML) to declare UI elements in Blazor razor page to build mobile native apps with Blazor programming model. Right now, it's experimental product, it would be a product if not .NET 5, then highly likely .NET 6.

Not clear what would be the file structures by MS when Blazor supports both web app and mobile app. It might be razor.html for web UI component and razor.xaml for mobile UI component, and razor.cs for the shared code behind.

Based on my speculation, I see separating UI and code behind might be on the future proof path for Oqtane framework.

I vote for code behind.

[markdav-is]

I use the .razor files and not the code-behind. It feels more maintainable by newer devs. I don't know what is gained by using code-behind, but if there is an obvious benefit I'd love to know what it is.

[hishamco]

Code separation, especially if the code get bigger and bigger ...

[jimspillane]

From their response, it looks like Microsoft is steering development into a single .razor file. Plus, they are pouring a lot of effort into improving the editing experience New experimental Razor editor for Visual Studio

If a component is getting too large, I would consider refactoring code into separate components rather than a code behind approach. To me, this would seem to be the Blazor way. @sbwalker since you have been developing Oqtane, have you come across a situation that you said I wish this was done using code behind?

[PizzaConsole]

I always use code behind because it is cleaner for me.

[sbwalker]

@jimspillane to answer your question, I have never had an issue with the single file approach. But like I said earlier, its really an individual developer preference.

[markdav-is]

I hope I'm not being too daft, but... its all compiled right? so can't we mix and match?

[sbwalker]

@markdav-is Correct, you can mix and match the approach. However we will not mix and match the approach in the core framework itself, because one of the guiding principles is consistency. So we will either use the single file approach or code behind approach in the core framework and we will expect any contributions to be in the standard format.

[PizzaConsole]

So essentially the goal of this discussion is to gage what dev contributors would prefer to use when making contributions to the project. Technically there is no benefit from using one over the other in terms of application performance.

Given that, I vote we just leave it the way it is. I will be using the code behind method in my custom modules, but I do not really see any benefit to migrating this whole project to code behind, especially when Microsoft is going to great lengths to improve the inline editing. From the few contributions I have made, I did not find it any less comfortable working on the inline files versus the code behind files.

There just seems to be a lot more to lose than to gain making this change.

[PizzaConsole]

though I will say, that another reason I like the code behind approach, is that I like to look at the HTML and C# side by side in VS

[jimspillane]

In VS, using Window | New Window in a Vertical document group can give a side by side of the same file. Window | Split is another option for a horizontal split.

[PizzaConsole]

I realize that is an option, I am just not a fan of opening multiple windows of the same file.

[TonyValenti]

I prefer that the logic code and the UI code be separate.

[sbwalker]

I appreciate the feedback in this thread. It is clear that the community is fairly divided on this topic. But since developers can choose the approach they prefer when developing their own modules and themes, there are no restrictions. At this point I think the best option for the core framework is to continue using the single file methodology, as there is no clear benefit for migrating to code behind.

[hishamco]

I think there's no benefit if the code is not much, I have seen some components have a HUGE a mount of code which is not suitable for some, I'm still see there's a benefit for the components who have a lot of code

Thanks