{"action":"created","issue":{"url":"https://api.github.com/repos/otobus/event_bus/issues/70","repository_url":"https://api.github.com/repos/otobus/event_bus","labels_url":"https://api.github.com/repos/otobus/event_bus/issues/70/labels{/name}","comments_url":"https://api.github.com/repos/otobus/event_bus/issues/70/comments","events_url":"https://api.github.com/repos/otobus/event_bus/issues/70/events","html_url":"https://github.com/otobus/event_bus/pull/70","id":365795608,"node_id":"MDExOlB1bGxSZXF1ZXN0MjE5NjI1Njgz","number":70,"title":"do not use case but functions to handle yield result.","user":{"login":"xadhoom","id":197981,"node_id":"MDQ6VXNlcjE5Nzk4MQ==","avatar_url":"https://avatars1.githubusercontent.com/u/197981?v=4","gravatar_id":"","url":"https://api.github.com/users/xadhoom","html_url":"https://github.com/xadhoom","followers_url":"https://api.github.com/users/xadhoom/followers","following_url":"https://api.github.com/users/xadhoom/following{/other_user}","gists_url":"https://api.github.com/users/xadhoom/gists{/gist_id}","starred_url":"https://api.github.com/users/xadhoom/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/xadhoom/subscriptions","organizations_url":"https://api.github.com/users/xadhoom/orgs","repos_url":"https://api.github.com/users/xadhoom/repos","events_url":"https://api.github.com/users/xadhoom/events{/privacy}","received_events_url":"https://api.github.com/users/xadhoom/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":4,"created_at":"2018-10-02T08:41:01Z","updated_at":"2018-10-12T03:33:12Z","closed_at":null,"author_association":"NONE","pull_request":{"url":"https://api.github.com/repos/otobus/event_bus/pulls/70","html_url":"https://github.com/otobus/event_bus/pull/70","diff_url":"https://github.com/otobus/event_bus/pull/70.diff","patch_url":"https://github.com/otobus/event_bus/pull/70.patch"},"body":"In this way is possible to handle setups where notify/build function never returns an error, which result into dialyzer warnings, as discussed in #69 \r\n\r\n//cc @otobus @mustafaturan \r\n\r\n### Description\r\nOn some usage scenarios (for example building up a map from other variables in the yield block) errors cannot simply happen, but the current implementation forces the user to always have the success and error paths in the yield block. \r\nBasically, during the macro expansion, the user provided yield block is always case-matched with two conditions, but if the block does not a path to error, dialyzer will warn about that.\r\n\r\n### Changes\r\n\r\n- [x] Delegate the `{topic, data}` building to separate functions in order to avoid case-matching dead paths\r\n\r\n### Is it ready?\r\n\r\n- [x] Created an issue and defined what the problem is\r\n- [x] Fixed the defined issue\r\n- [x] The changes have only one commit \r\n- [x] The changes don't break current functionality\r\n- [x] All tests are covered and passing travis\r\n- [x] Used Elixir formatter for only modified file and fixed any of them breaks current consistency. \r\n- [x] Didn't bump the version\r\n\r\n### References\r\n\r\n- Issue #69 \r\n"},"comment":{"url":"https://api.github.com/repos/otobus/event_bus/issues/comments/429193405","html_url":"https://github.com/otobus/event_bus/pull/70#issuecomment-429193405","issue_url":"https://api.github.com/repos/otobus/event_bus/issues/70","id":429193405,"node_id":"MDEyOklzc3VlQ29tbWVudDQyOTE5MzQwNQ==","user":{"login":"mustafaturan","id":637021,"node_id":"MDQ6VXNlcjYzNzAyMQ==","avatar_url":"https://avatars3.githubusercontent.com/u/637021?v=4","gravatar_id":"","url":"https://api.github.com/users/mustafaturan","html_url":"https://github.com/mustafaturan","followers_url":"https://api.github.com/users/mustafaturan/followers","following_url":"https://api.github.com/users/mustafaturan/following{/other_user}","gists_url":"https://api.github.com/users/mustafaturan/gists{/gist_id}","starred_url":"https://api.github.com/users/mustafaturan/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mustafaturan/subscriptions","organizations_url":"https://api.github.com/users/mustafaturan/orgs","repos_url":"https://api.github.com/users/mustafaturan/repos","events_url":"https://api.github.com/users/mustafaturan/events{/privacy}","received_events_url":"https://api.github.com/users/mustafaturan/received_events","type":"User","site_admin":false},"created_at":"2018-10-12T03:33:12Z","updated_at":"2018-10-12T03:33:12Z","author_association":"COLLABORATOR","body":"Hi @ShaneWilton \r\n\r\nThanks for commenting and sharing how you use the `EventSource` module helper. I like the way you aggregate the events separately. (That encourages me for the idea of event schemas and event schema versioning, which I want to introduce in version >= 2.0)\r\n\r\nBut it might be better to use `EventBus.notify/1` in your case instead of `EventSource.nofity`. To learn more and provide a better solution: may I ask why did you prefer to `EventSource.notify` helper instead of `EventBus.nofitfy/1` directly? \r\n\r\nIn your samples, `EventSource` sets `initailized_at` value which doesn't really provide the event start time exactly for those agregated use cases. `EventSource.build` and `EventSource.notify` helpers help to measure the exact times when an event started and ended at. And put some additional information to event structure like `id, transaction_id, source` values if you don't specify them in the params.\r\n\r\nThanks again"}}
{"actor":{"display_login":"mustafaturan"}}