{"action":"created","issue":{"url":"https://api.github.com/repos/redux-loop/redux-loop/issues/173","repository_url":"https://api.github.com/repos/redux-loop/redux-loop","labels_url":"https://api.github.com/repos/redux-loop/redux-loop/issues/173/labels{/name}","comments_url":"https://api.github.com/repos/redux-loop/redux-loop/issues/173/comments","events_url":"https://api.github.com/repos/redux-loop/redux-loop/issues/173/events","html_url":"https://github.com/redux-loop/redux-loop/issues/173","id":292319997,"number":173,"title":"execute reduxLoop.Cmd.action synchronously without notifying subscribers?","user":{"login":"arnauorriols","id":4871949,"avatar_url":"https://avatars2.githubusercontent.com/u/4871949?v=4","gravatar_id":"","url":"https://api.github.com/users/arnauorriols","html_url":"https://github.com/arnauorriols","followers_url":"https://api.github.com/users/arnauorriols/followers","following_url":"https://api.github.com/users/arnauorriols/following{/other_user}","gists_url":"https://api.github.com/users/arnauorriols/gists{/gist_id}","starred_url":"https://api.github.com/users/arnauorriols/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/arnauorriols/subscriptions","organizations_url":"https://api.github.com/users/arnauorriols/orgs","repos_url":"https://api.github.com/users/arnauorriols/repos","events_url":"https://api.github.com/users/arnauorriols/events{/privacy}","received_events_url":"https://api.github.com/users/arnauorriols/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2018-01-29T08:25:50Z","updated_at":"2018-02-01T01:18:32Z","closed_at":null,"author_association":"NONE","body":"I'm currently using `reduxLoop.Cmd.action` to trigger new actions right after the current action being processed in the reducer. Although it's fairly reasonable, I wasn't expecting that before any new action is processed by the reducer, the subscribers are notified (ie, the react views are rerendered). Right after the subscribers are notified, the new action is processed, and the subscribers notified again. \r\n\r\nMy views are stateless, and this makes the intermediate notification to the subscribers redundant and costly from a performance point of view (in my real case, I have a chain of up to 3 chained actions). I'm currently debouncing these redundant notifications using `react-batched-subscribers` with `request-animation-frame`. However, this introduces some unnecessary complexity to my code, and I wonder if this could already be solved by redux-loop? I'm thinking of an option to `reduxLoop.Cmd.action` to process the actions synchronously, and only notify the subscribers until all the actions are processed. \r\n\r\nI haven't tested it empirically (I plan on testing it later during the day), but as far as I can see, [elm-update-extra](https://github.com/ccapndave/elm-update-extra/blob/3.0.0/src/Update/Extra.elm#L48) behaves synchronously. \r\n\r\nWhat are your thoughts about this?"},"comment":{"url":"https://api.github.com/repos/redux-loop/redux-loop/issues/comments/362126460","html_url":"https://github.com/redux-loop/redux-loop/issues/173#issuecomment-362126460","issue_url":"https://api.github.com/repos/redux-loop/redux-loop/issues/173","id":362126460,"user":{"login":"bdwain","id":3982094,"avatar_url":"https://avatars1.githubusercontent.com/u/3982094?v=4","gravatar_id":"","url":"https://api.github.com/users/bdwain","html_url":"https://github.com/bdwain","followers_url":"https://api.github.com/users/bdwain/followers","following_url":"https://api.github.com/users/bdwain/following{/other_user}","gists_url":"https://api.github.com/users/bdwain/gists{/gist_id}","starred_url":"https://api.github.com/users/bdwain/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bdwain/subscriptions","organizations_url":"https://api.github.com/users/bdwain/orgs","repos_url":"https://api.github.com/users/bdwain/repos","events_url":"https://api.github.com/users/bdwain/events{/privacy}","received_events_url":"https://api.github.com/users/bdwain/received_events","type":"User","site_admin":false},"created_at":"2018-02-01T01:18:32Z","updated_at":"2018-02-01T01:18:32Z","author_association":"OWNER","body":"Yup. So in your example, my suggestion would be to put all of that logic in the handler for SELECT MARKER. \r\n\r\n```js\r\nswitch(action.type) {\r\n    case \"SELECT MARKER\":\r\n        return {\r\n            ...state,\r\n            selectedMarker: maybe.just(action.marker),\r\n            bounds: centerMap(action.marker) \r\n        };\r\n     default:\r\n        return state;;\r\n}\r\n```\r\n\r\nnow let's say you could change the map bounds another way (let's say when FOO is dispatched, where FOO is some arbitrary thing that can happen), and wanted to share the logic so that you didn't have to repeat it. You could do something like this\r\n\r\n```js\r\nfunction updateBounds(state, bounds){\r\n  return {\r\n     ...state,\r\n     bounds\r\n  };\r\n}\r\n\r\nswitch(action.type) {\r\n    case \"SELECT MARKER\":\r\n        return updateBounds({\r\n            ...state,\r\n            selectedMarker: maybe.just(action.marker)\r\n        }, centerMap(action.marker));\r\n\r\n    case \"FOO\":\r\n       return centerMap(state, action.bounds);\r\n\r\n   case \r\n     default:\r\n        return state;;\r\n}\r\n```\r\n\r\nthis scenario is pretty simple so not sharing the logic would probably be the easiest thing to do for it, but if the logic in updateBounds was not trivial, then that pattern could help."}}
{"actor":{"display_login":"bdwain"}}