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:
a) get a json encoded result and prepare the html in the javascript success callback
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?