Boundaries between Clients and Reducers/Features

[lightandshadow68]

Are their any general guidelines for determining what functionality should be implemented in a client vs a reducer / feature?

For example, in the case of a User list, one strategy is to have a long running async stream that emits UserGroupState and UserRowState structs specific to the list UI. Filtering, sorting and search happens in the client, which has endpoints for setting the search text, filter settings, etc.

On the other end of the spectrum, the client could just emit a stream of available User structs, which gets turned into the same row states after being sorted, filtered and grouped in the reducer.

Seems to me, the answer is "It depends".

For example, putting more of that functionality in the reducer makes it more flexible and testable. On the other hand, a live implementation that connects to a database could group and sort users significantly faster and with less memory usage via a database query, etc. And there is the challenge of updating the queries for the long running async stream when they change.

IOW, is it usually preferable to implement sorting, filtering, grouping, etc. in the reducer, unless there is some implementation specific reason to do otherwise?

[Alex293]

I’d say the more you put into the reducer the more you get easy test coverage. Thing is you will want to have the sort condition in the state too if you want to change / display it in the view. In addition a recent proposal on the swift forum is proposing native predicates that would be convenient to store in state and pass to a database.