Initial feedback about blazorscaffolding HOT 2 OPEN

Thanks @SteveSandersonMS for all this feedback!

The only opportunity for that here is perhaps combining the Data, Models, and Migrations folders into a single top-level folder

The location of the model type isn't determined by the scaffolder - it's user defined. The existing tutorials instruct the user to put the model type in the Models folder, but it could just as easily go anywhere else. The DbContext is generated by the scaffolder in the Data folder (which oddly doesn't appear to be configurable). The migrations are also user generated by manually running the EF Core tooling after running the scaffolder. The EF Core tools will by default add migrations to the Migrations folder, but the user can customize this using command-line options.

Is the = new() useful here? I thought it would get overwritten with null

If I don't have this, then I get an exception when loading the Create page: "InvalidOperationException: EditForm requires either a Model parameter, or an EditContext parameter". I have verified that it does work with RC2. Wasn't this enabled by the work you did to support using the from form parameter as the form model? Let me know if I need to initialize in OnInitialized instead.

BlazorScaffoldingContext is an odd name

The default DbContext name generated by the existing scaffolders is based on the project name. I'm trying to stay consistent with the existing scaffolders as much as possible. The user can always choose whatever name they want when running the scaffolder.

In all URLs, make sure to use base-relative paths and not root-relative ones

Fixed: 3394f60

My guess is that the HTTP status code can easily be set to 404 this way, but perhaps the wider issue is you then have to put in some UI logic

Right. Adding UI logic to each page seems clunky. As a short-term solution, what do you think about using NavigationManager.NavigateTo("notfound") to force a 404 response?

Do you think it's worth enabling pagination? Otherwise if people wire this up to a DB table with a large number rows, the page will appear to be broken, or at least will have very poor perf since it will actually retrieve all the rows from the DB.

Seems like a reasonable idea, so I added it: 3d2b5bb. But pagination currently requires interactivity. Are we ok with requiring that? One potential issue is that now I think we might now be hitting the database twice (once during prerendering and once for the interactive render). Normally you mitigate that by persisting component state, but I'm not sure how to do that with QuickGrid doing the DB query. Alternatively, should we consider updating QuickGrid pagination to not require interactivity?

Do you know for sure that id values will always be numeric/GUIDs? If it's possible for them to be other strings, you'd need to URL-encode the ID parameter in URLs

Nice catch! It looks like EF Core supports any primitive type as the key. I updated the link generation to do URL encoding by adding static link generation methods on each page: a4607ad. Let me know if the Url method name would pass an API review 😄.

I notice there's no streaming rendering in here. That's totally fine and I wouldn't necessarily suggest introducing that unless you can observe a UX benefit.

I tried out enabling streaming rendering and it seems to be working as expected: I see the table render initially with no rows and then fill in with data. In the page source I also see the streamed batches. Seems like a good addition but let me know if you foresee issues with it.

from blazorscaffolding.

If I don't have this, then I get an exception when loading the Create page: "InvalidOperationException: EditForm requires either a Model parameter, or an EditContext parameter

Understood. The team discussed this yesterday and ideally we'd like to change this so that even on GET requests, [SupplyParameterFromForm] would null out any nonmatching parameters. But I don't know if that work is actually scheduled and tracked. cc @mkArtakMSFT

Right. Adding UI logic to each page seems clunky. As a short-term solution, what do you think about using NavigationManager.NavigateTo("notfound") to force a 404 response?

Very reasonable.

But pagination currently requires interactivity

It shouldn't require that. It may be necessary to implement a custom pagination UI that emits the required querystring params so it works in non-interactive mode. Is that something you tried? TBH longer term we should update QuickGrid to do that automatically.

Alternatively, should we consider updating QuickGrid pagination to not require interactivity?

Yes but I suspect that would have to be post-.NET 8

Let me know if the Url method name would pass an API review 😄.

It would definitely pass my API review, but then I tend to prefer things that are aesthetically good, with less emphasis on arbitrary rules. This is aesthetically good. Let's say it passes review.

I tried out enabling streaming rendering and it seems to be working as expected

Sounds like a good thing then!

from blazorscaffolding.