How often should DataPortalTextController be hit when saving a BO in Blazor Wasm? #2823
Answered
by
mtavares628
mtavares628
asked this question in
Questions
-
|
Using Csla 5.5.2 I've created a form to edit an existing business object. I'm binding that object to an injected ViewModel and triggering a SaveAsync on the ViewModel when the form is submitted. The form takes a little while to save and return. At first it was a second or two, but as I kept adding more controls to my form that save keeps taking longer and longer. When I look at the DevTools console, it seems to be hitting the PostAsync method of my DataPortalTextController a bunch of times when the save is initiated, and that amount increases the more controls I add to the page. As a bare bones test, I removed all controls from the form except for the save button to submit the form and I see the following in the Console Log when the button is clicked: So my question is is this normal? Should the ViewModel trigger so many calls to the DataPortal controller? I would have assumed it would only be making one call. |
Beta Was this translation helpful? Give feedback.
Answered by
mtavares628
Mar 10, 2022
Replies: 2 comments 8 replies
-
|
I'm following back up with this. I was going down the wrong path with the calls to the DataPortalTextController. All of those calls are legitimate based on my validation rules hitting the database. I've pinpointed my issue having to do with calling StateHasChanged in the ModelPropertyChanged Event Hander for the ViewModel. When I write the changed property name out to the DevTools console it looks like a bunch of meta properties are being changed after the call to the DataPortalTextController, and before the OnModelSaved handler is invoked. Now my business object has 5 child collection objects on it, so that may have something to do with all those calls, but is that normal to keep changing the meta properties on the ViewModel for all child objects after the save? And is there a suggested way / best practice to ignore these properties during the save so that StateHasChanged isn't being called all of those times? Here's what my console looks like: |
Beta Was this translation helpful? Give feedback.
8 replies
-
|
HI Rocky, thanks for getting back to me. I have started down that path similar to how you suggested, but I am also filtering out all of the meta properties from being changed. So I have something like this in the event handler: private async void OnModelPropertyChanged(object? sender, PropertyChangedEventArgs e)
{
if (!vm.Model.IsMetaProperty(e.PropertyName))
{
await InvokeAsync(() => StateHasChanged());
}
}I had created an IsMetaProperty function in my BO to check whether the property is one of those in the meta properties list, and if so, don't call StateHasChanged. This greatly sped things up. The only drawback that I've seen so far was that my save button would no longer disable when the button is clicked, so I just added a boolean field that I set before the save to true and after the save to false. and check it on the button: private async Task OnSave()
{
SavingViewModel = true;
await vm.SaveAsync();
SavingViewModel = false;
}<div class="mb-3">
<button class="btn btn-primary" type="submit" disabled="@(!vm.Model.IsSavable || SavingViewModel)">Save</button>
<button class="btn btn-secondary" type="button" @onclick="NavigateToReturnUrl">Cancel</button>
</div>This seemed to handle things for me, since individual property changes on the regular properties would still trigger StateHasChanged and update the button based on the IsSavable property. Then the other hurdle was that child properties aren't triggering OnModelPropertyChanged, so I trapped OnChildChanged on my BO, and triggered OnPropertyChanged manually for the child collection. This seems to be working. All that being said, do you see any other drawbacks to me excluding the meta properties from triggering StateHasChanged? |
Beta Was this translation helpful? Give feedback.
-
|
If you are in the mood to experiment, you could set the Windows Forms would become very slow if property changed events were raised for every property being changed. XAML UIs, on the other hand, don't work unless an event is raised for every property being changed. This is the origin of the So the default is to raise the event for every property that changes. I'm thinking that maybe changing to the Windows Forms behavior might be better? In that case CSLA tries to minimize |
Beta Was this translation helpful? Give feedback.
-
|
I tried switching to the Windows PropertyChangedMode, and it seems to be working well. It still raises the regular BO properties with their names, and the meta properties don't appear to be triggering at all. This will save me from having to filter out those meta properties for each form, so thanks for the suggestion! |
Beta Was this translation helpful? Give feedback.
-
|
Can you please put the unrelated question in its own thread? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, sorry. I should know better. I'll take care of that now. |
Beta Was this translation helpful? Give feedback.
Answer selected by
mtavares628
-
|
Also now an issue: #2833 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm following back up with this. I was going down the wrong path with the calls to the DataPortalTextController. All of those calls are legitimate based on my validation rules hitting the database.
I've pinpointed my issue having to do with calling StateHasChanged in the ModelPropertyChanged Event Hander for the ViewModel. When I write the changed property name out to the DevTools console it looks like a bunch of meta properties are being changed after the call to the DataPortalTextController, and before the OnModelSaved handler is invoked. Now my business object has 5 child collection objects on it, so that may have something to do with all those calls, but is that normal to keep changin…