I have a bit of a dilemma i’ve been stewing on for a while, which is how to best handle ajax responses in an MVC application.
If I just focus on multiple row results, like tabular data or an unordered list, I seem to go around in circles about how I update changes to an individual item.
Lets say for example, I have a list of to-do items:
- I click to edit an item
- An ajax request is fired and the entry is replaced with a form containing the entry data
- Changes are made, the form is submitted and replaced by the updated item
This is where I find it gets complicated. I could:
b) return html server side and update the item
c) refresh all rows in the data set
Keeping with MVC architecture, ideally I should have a view which contains the HTML response that I want, which would be one view for the data set, and another view for each row (so that I can retrieve just one row).
But if I split each row into its own view, firstly it is creating a potentially miniature view file, but secondly when I get the whole data set, I would need to load the row view for every item. This seems fine for a small application but I can imagine in a bigger application having such a level of view separation would be a pain to maintain.
I hope that makes sense… basically what is the best practice to return bite sized pieces of HTML in a MVC environment whilst eliminating code duplication and a bloated view folder?