❔ C# Database Query Optimization [Dapper & ReactJS]
I am currently working on a C# .NET app with React and I have a table of products in an overview page. I want the administrators to be able to just click and edit various entries in the table without being forced to re-use the Add Form. I want this to reduce the number of calls to the Database (because I'm obsessed with performance since I usually write C++). Now the problem with the table editing method is that I will require a State Pattern or a way to manage Session States, I've also just read that caching data is considered bad for web applications. How should I go about this?
28 Replies
explain the issue in more detail
you want to batch the calls?
sounds more like you want to "batch" the edits
and more or less apply a "patch" to the list, changing only the edited fields
this isnt very easy to do however
likely, its a lot more effective to just check what rows were modified and update those rows entirely
I want to remove the whole Form interaction. Currently the table contains an edit button next to every entry which needs to be clicked by the user that wants to edit the entries products. After the button is pressed a Form pops up and it gets pre-filled with the product data. After the user makes changes it can close or save the form. Saving will update the entries in the DB through an API call.
The idea that I came up with is having a DefaultState in which the table content is exactly as in the DB and when a user clicks the components in the table they should be editable (basically the table becomes a huge form that allows for batch updates). When the content in the table is different from the one in the database the state will change to EditState which will display the cancel and save buttons under the table. If the user presses save the entries will be mass updated without having to go through all of the forms.
remember, this is react, not serverside HTML
so you can send as many or few requests as you want
So in a way almost the same amount of calls as the form method except the fact that there is no need for the successive Read/Get calls that would be required when working with the form.
you're not limited to one
you COULD send a "updateRow" request for each individually edited row, or you wait until the user is done and clicks save to send all the edited rows
all in one go. both are valid options, it all depends on your wanted flow
tracking what rows are edited is a good idea, you don't want to send the entire list back and forth
Yeah, I am just unsure on how that could be done since I am not used to working in this style (I mainly write C++ with SFML and a bit of OpenGL)
well, it should be fairly easy
And form what I know the React standard moved away from OO to a more functional approach
correct
but thats not a problem here
And applying a State Pattern wouldn't be the same as when working in an OO manner
I'm not a frontend developer, but I'd wrap my row in some kind of... state wrapper
Hmm, I get what you mean. I'll try that when I have the chance
If any other problems arise I guess I can try opening a new thread. Thanks for the help!
well, you should still use a <form>
something like this
it doesn't have to be a visible form, or a modal
each input can be its own form
hitting enter submits by default
Well, a row can basically be a Form
correct
sure. and you intercept the submit to just update your internal state
And the Save just deals with updating the changed forms in batch
i mean, kind of risky to not query immediately
what if the browser crashes? user leaves? cpu crashes
you're saying capture the state and perform batch updates?
that sounds less efficient, depending
more error-prone
its not one or the other. its different
having a two step update process might not be optional
perhaps there even needs to be a "are you sure" modal
Bunta decribed wanting a cancel/save button at the bottom of the table, so thats what I've been going for
With this I agree. It is more error prone and could be quite a bit of a pain in the ass for the user (since anyone can make a typo), but I'm thinking of having everything be a dropdown box or at least of available entries, so the user can't add any bad entries.
that solves it pretty well
but the user can forget to click Save
so you'll need an exit intent check
etc
for sure
one of those "navigating away now will cancel all pending changes" things
UX is fun
if you're dealing with a definite set of options, then yeah
a combobox is a good compromise
It's usually just a set of entries which can appear in drop down menus (such as product categories) and some radio buttons for specific details, for example if a product is second hand or not. The product names can't be changed since they are prefilled with the proper names which would only leave interactive components for the user to deal with. And the suggestion with navigating away is a really nice addition that I did not think of
Was this issue resolved? If so, run
/close - otherwise I will mark this as stale and this post will be archived until there is new activity.