\r\nimport React from 'react';\r\nimport store from '.\/store';\r\nimport { Fetch } from '.\/rootReducer';\r\n\r\nfunction App() {\r\n\r\n function handleDoFetch() {\r\n store.dispatch({type: Fetch});\r\n }\r\n\r\n return (\r\n <div className="App">\r\n <button onClick={handleDoFetch}>Do Fetch<\/button>\r\n <\/div>\r\n );\r\n}\r\n\r\nexport default App;\r\n<\/pre>\nSo this will simply dispatch an action which will ultimately be handled by our observable. Before this happens let’s create a redux store and set up the redux observable middleware, here’s my store.js file<\/p>\n
\r\nimport { createStore, applyMiddleware, combineReducers } from "redux";\r\nimport { createEpicMiddleware } from 'redux-observable';\r\nimport rootReducer from ".\/rootReducer";\r\nimport rootEpic from ".\/rootEpic";\r\n\r\nexport const epicMiddleware = createEpicMiddleware();\r\n\r\nconst store = applyMiddleware(epicMiddleware)(createStore)(\r\n combineReducers({\r\n rootReducer,\r\n })\r\n);\r\n\r\nepicMiddleware.run(rootEpic);\r\n\r\nexport default store;\r\n<\/pre>\nWe don’t need to combineReducers as there’s only one, but it’s there for an example of setting up multiple reducers. Let’s now create a very basic reducer named rootReducer.js<\/p>\n
\r\nexport const Fetch = "FETCH";\r\nexport const FetchEnded = "FETCH_ENDED";\r\n\r\nexport default (state = {}, action) => {\r\n switch (action.type) {\r\n case FetchEnded:\r\n console.log("Fetch Ended");\r\n return {\r\n ...state,\r\n data: "Fetch Ended"\r\n }\r\n default:\r\n break;\r\n } \r\n return state;\r\n}\r\n<\/pre>\nNotice we’ve got two actions exported, Fetch<\/em> and FetchEnded<\/em> but there’s nothing handling Fetch<\/em> in this case. This is because redux middleware will in essence pass this through to the redux-observable we’re about to create. We could also handle Fetch<\/em> here and still handle it also within the epic, the point being the epic (via the observable and ofType) is going to handle this action when it see’s it.<\/p>\nNow we’ve got everything in place, let’s put the final piece in place, the epic will be stored in rootEpic.js and here it is<\/p>\n
\r\nimport { Fetch, FetchEnded } from ".\/rootReducer";\r\nimport { Observable } from "rxjs\/internal\/Observable";\r\nimport { mergeMap } from "rxjs\/operators";\r\nimport { ofType } from "redux-observable";\r\n\r\nfunction rootEpic(\r\n action$,\r\n _state$,\r\n _dependencies) {\r\n \r\n return action$.pipe(\r\n ofType(Fetch),\r\n mergeMap(action => { \r\n return Observable.create(o => {\r\n console.log("fetchData")\r\n o.next({ type: FetchEnded }); \r\n })\r\n }));\r\n}\r\n\r\nexport default rootEpic;\r\n<\/pre>\nNotice that the rootEpic<\/em> function returns an Observable via Observable.create<\/em> and it uses next<\/em> to inform any subscribers (in this case the middleware) to changes of state. Obviously this example is stupidly simple in that it just dispatches FetchEnded<\/em> to the subscriber(s).<\/p>\nIt might be the observable calls next<\/em> many time for different values but in this example we’ve kept things simple. Running the application will display a button and using the browser’s dev tools, when the button is pressed the Fetch<\/em> action is detected by the epic and the returned pipe<\/em>, which itself uses the observable which then dispatches a FetchEnded<\/em> action, which is handled by the reducer.<\/p>\nAs stated, our example is very simple but in a real world scenario this function could be acting as a websocket client and for every value returned would placed into the next function until cancelled or maybe an error occurred.<\/p>\n
Another thing to be aware of is that whilst the rootEpic pipe will be created once (in our case when added to the middleware for example) the pip is called for each action through redux and hence we must<\/em> filter the actions we want to handle using ofType<\/em> and even actions dispatched via the observable will come through this epic.<\/p>\n","protected":false},"excerpt":{"rendered":"In the previous post we looked at one way to handle application side effects, such as asynchronous loading of data using Redux sagas. There’s absolutely nothing wrong with redux saga’s but there’s a few alternatives. The alternative we’re going to look at is redux-observable. So what’s the big difference between redux-sagas and redux-observables? I’ve not […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[252,275],"tags":[],"class_list":["post-7657","post","type-post","status-publish","format-standard","hentry","category-redux","category-redux-observable"],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/posts\/7657","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/comments?post=7657"}],"version-history":[{"count":5,"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/posts\/7657\/revisions"}],"predecessor-version":[{"id":7699,"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/posts\/7657\/revisions\/7699"}],"wp:attachment":[{"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/media?parent=7657"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/categories?post=7657"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/tags?post=7657"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}