Is it recommended to fetch in effect or should it be imperative

In out team we encountered a explosive discussion on how we should handle the relationship of a fetch and its parameters, after searching in community I still find various solutions to this, I'd like to raise this discussion to find a best practive. ## Background Suppose we have a simple list view like: <img width="687" alt="Jietu20190402-130206@2x" src="https://user-images.githubusercontent.com/639549/55377435-87268b80-5547-11e9-97a8-313a5713ced3.png"> Whenever user types keyword in textbox and clicks "Search" button, or they change the page number, we should fetch a new list from remote and render it in table. We use redux to manage global state of this simple app, the store is structured as: ```js { filter: '', pageIndex: 0, results: [] } ``` We developed a total of 3 solutions to demonstrate how the change of `filter` and `pageIndex` should cause a fetch of `results`. ## Use effect and separation of view and logic This is the first demo: https://codesandbox.io/s/20x1m39w00 In this implementation we tried to: 1. Utilize `useEffect` to trigger a fetch when any parameter changes. 2. Do not pass any parameter as prop to `components/List` component. In my point of view, I like this solution best because: 1. It have a very clear separation of view and logic, `components/List` does not receive any redundant props such as `filter` or `pageIndex`. 2. It theoretically treat a callback prop as a normal one, make it a dependency of `useEffect`. 3. It works in a **reactive** way, which means "we trigger a fetch not because the action taken from user, only because the change of state". Still we have concerns about it: 1. It obviously triggers more render and updates because change of `filter` or `pageIndex` does not dispatch `FETCH_RESULTS` immediately, this cause a sync dispatch in effect which we previously avoided by `no-set-state-did-update` rule. 2. We create a state update from another state update, this "chaining" is not clear enough for developers and may …