-
Notifications
You must be signed in to change notification settings - Fork 25.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Confirm/update private access modifier in RC topics+samples #11010
Comments
Don't tell Steve that! He won't think that he's part of the engineering team. 😄 lol Here's an example from the template (and the Most of the docs are now leaning toward |
ping @NTaylorMullen ... can you help? TL;DR ... are we using the @functions {
private WeatherForecast[] forecasts;
protected override async Task OnInitAsync()
{
forecasts = await Http.GetJsonAsync<WeatherForecast[]>("sample-data/weather.json");
}
private class WeatherForecast
{
...
}
} ... or as the templates have it ... @functions {
WeatherForecast[] forecasts;
protected override async Task OnInitAsync()
{
forecasts = await Http.GetJsonAsync<WeatherForecast[]>("sample-data/weather.json");
}
class WeatherForecast
{
...
}
} |
Yes, should try and avoid using implicit access modifiers in the functions block. ASP.NET engineering guidelines aside, my biggest reason is that using implicit accessor modifiers can unintentionally give the impression that code in the i.e. these mean two very different things @{
WeatherForecast[] forecasts;
}
@functions {
WeatherForecast[] forecasts;
} Being explicit with access modifiers makes it much more clear: @{
WeatherForecast[] forecasts;
}
@functions {
private WeatherForecast[] forecasts;
} |
Thanks @NTaylorMullen. @danroth27 If you/Steve provide final approval, I'll use this issue to track the work for a sweep in the RC/Blazor docs. Most of our stuff is 👍 ... just a couple of spots to touch. If we proceed with the access modifier, the RC/Blazor templates require the update. Let me know if you want me to open an issue/send a PR for those. We should look broadly, too, at aspnet/Docs. There aren't many examples of |
BTW how we write the product code certainly doesn't need to match what templates or docs do. They have two completely different audiences and different purposes. Template code is often "simpler" whereas for the framework code itself we set some more rigid guidelines that help us maintain this codebase, sometimes at the cost of verbosity. |
My current guidance from APEX is to follow engineering guidelines for docs and doc samples. I won't make a move on this until I receive guidance from @danroth27 and @SteveSandersonMS. |
BTW for example the default console app template in VS has this Program.cs file: using System;
namespace ConsoleApp1
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Hello World!");
}
}
} No modifiers on anything. That's totally fine for many cases in template code. I would imagine for many cases in docs that's fine as well. Ultimately the question is which is better in each case for the consumer to understand. I think in many docs the modifiers are often noise, unless they carry a significant meaning, such as explaining that public methods on MVC controllers are publicly accessible, and non-public ones are not. |
@NTaylorMullen has a reason in this scenario for them, but @SteveSandersonMS doesn't embrace the modifier AFAIK, so he might be leaning that way. We're in no giant rush. We have time to iron these bits out. I wasn't going to work this until after our pass on Razor Components Topic Reviews #10717 for Preview 2 is complete. |
I'm totally happy with the inclusion of |
I'm a little late to the bikeshed party (and not sure my opinion matters), but I'm updating my VS Code snippets for Blazor, because it is a few previews behind (my bad). I wanted to match the conventions on the Docs, and I was pretty surprised to see the [Parameter]
private string Title { get; set; } This seems weird to me. I feel like the access modifier convention for
<h1>@Title</h1>
@code {
[Parameter]
private string Title { get; set; }
} It seems odd that I can do this from a ParentComponent.razor file: <ChildComponent Title="Some title I can change" /> Because my mental model in my head says Those are the two main reasons why I feel like they should be |
Side note - I feel strong enough about this that I'd happily take the time to send the docs PR to switch all these if there's agreement on this. 😄 /cc @guardrex |
@scottsauber Engineering reversed their earlier approach and guidance. They're already reversed to |
@guardrex - Whoops - sorry I missed that thread... my bad.... nothing to see here. 😄 |
There's at least one ... and probably a few more lurking in the code examples+sample apps. This happened because it was the case in the old Blazor engineering repo, examples, samples, etc.
@danroth27 to confirm that we need to always provide the
private
access modifier where currently in a handful of spots its defaulting toprivate
.Notes to self: Check Razor syntax topic. Confirm attribute location on same line or different line.
Note to self: Engineering PR with this.
The text was updated successfully, but these errors were encountered: