There usually isn't a need to refresh the data beneath a modal window while it is open. If real-time updates are needed (e.g. moving sliders to see a varying result), a different paradigm may be more useful.
However, changes should be reflected in the source list as soon as the modal window is closed.
A student(s) is selected and the "Manage subjects"-dialog is opened. A
subject checkbox is set and the attach button is pressed. The dialog
is closed and the state/page is reloaded!
The ui state of the selected students is gone.
That's the problem. The UI should update, but existing state (such as search/sort/selection) should be preserved.
Without delving into implementation details, I'd suggest merging the changes into the list instead of reloading the whole thing. If you must perform a full reload, then you need to consider restoring the state of the UI.
What is the benefit of giving the user direct ui feedback by
refreshing the data beneath the modal dialog?
The user shouldn't have to wonder if the change happened (or worse, interact with stale data).
A quick scenario to illustrate these points. Let's say I need to update several students in a class.
- I start by applying a filter.
- I open each record and ensure that change ABC is made.
- I close the modal dialog.
- The associated item in the list updates, perhaps briefly changing color to indicate that it has changed (small, instant changes are easy to miss).
- I can now easily see which item I need to edit next, rather than relying on memory to keep my place.
In this scenario, seeing the update is useful and losing state would be counterproductive. I should not have to reapply my filter(s) after every update and (possibly) scroll back to my previous location within the list.