\\n )\\n }\\n}\\n\\nfunction mapStateToProps(state) {\\n return {\\n images: state.images,\\n selectedImage: state.selectedImage\\n }\\n}\\n\\nexport default connect(mapStateToProps)(Gallery)\\n\")), mdx(\"p\", null, \"In the \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"Gallery\"), \", we will use the \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"dispatch\"), \" function in the component props by calling it \", mdx(\"em\", {\n parentName: \"p\"\n }, \"inside of the body\"), \" of the \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"onClick\"), \" handler function. For now we are just writing it inline for convenience, but once we make that change, we can now click a thumbnail, and it will update the selected image via the reducer!\"), mdx(\"p\", null, \"Using dispatch can be convenient way to quickly create generic actions, but soon we will want to make reusable actions that are well named. To do this, we will make use of \\\"action creators\\\".\"), mdx(\"h3\", null, \"Action Creators\"), mdx(\"p\", null, \"Action creators are functions that return configured action objects. We will add our first action creator to an new file called \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"actions.js\"), \".\"), mdx(\"h3\", null, \"actions.js\"), mdx(\"pre\", null, mdx(\"code\", {\n parentName: \"pre\",\n \"className\": \"language-javascript\"\n }, \"export const IMAGE_SELECTED = 'IMAGE_SELECTED';\\n\\nexport function selectImage(image) {\\n return {\\n type: IMAGE_SELECTED,\\n image,\\n };\\n}\\n\")), mdx(\"p\", null, \"This could now be imported directly into any file that needed to create a \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"selectImage\"), \" action! \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"selectImage\"), \" is a pure function that only returns data. It takes an image as an argument, and adds that to the action object it creates and returns.\"), mdx(\"blockquote\", null, mdx(\"p\", {\n parentName: \"blockquote\"\n }, mdx(\"strong\", {\n parentName: \"p\"\n }, \"note:\"), \" We are returning a plain JavaScript object, but the second property \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"image\"), \" might be weird if you haven't encountered this style before. Basically, in ES6, if you pass a property to an object like this it expands to \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"image: 'whatever value was held by image'\"), \" in the resulting object. Super handy.\")), mdx(\"pre\", null, mdx(\"code\", {\n parentName: \"pre\"\n }, \"import * as GalleryActions from './actions.js';\\n[...]\\nonClick={() => dispatch(GalleryActions.selectImage(image))}\\n\")), mdx(\"p\", null, \"This isn't much nicer than just using \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"dispatch\"), \" though.\"), mdx(\"p\", null, \"Luckily for us, this pattern is so common, Redux provides a much nicer way to do this with the \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"bindActionCreators\"), \" function.\"), mdx(\"pre\", null, mdx(\"code\", {\n parentName: \"pre\",\n \"className\": \"language-diff\"\n }, \"import React, {Component} from 'react'\\nimport {connect} from 'react-redux';\\n+ import {bindActionCreators} from 'redux';\\n\\n+ import * as GalleryActions from './actions.js';\\n\\nexport class Gallery extends Component {\\n constructor(props) {\\n super(props);\\n this.props.dispatch({type: 'TEST'});\\n console.log(props);\\n }\\n handleThumbClick(selectedImage) {\\n this.setState({\\n selectedImage\\n })\\n }\\n render() {\\n- const {images, selectedImage, dispatch} = this.props;\\n+ const {images, selectedImage, selectImage} = this.props;\\n return (\\n
\\n
\\n
\\n
\\n
\\n
\\n
\\n {images.map((image, index) => (\\n-
dispatch({type:'IMAGE_SELECTED', image})}>\\n+
selectImage(image)}>\\n
\\n
\\n ))}\\n
\\n
\\n )\\n }\\n}\\n\\nfunction mapStateToProps(state) {\\n return {\\n images: state.images,\\n selectedImage: state.selectedImage\\n }\\n}\\n\\n+function mapActionCreatorsToProps(dispatch) {\\n+ return bindActionCreators(GalleryActions, dispatch);\\n+}\\n\\n-export default connect(mapStateToProps)(Gallery)\\n+export default connect(mapStateToProps, mapActionCreatorsToProps)(Gallery)\\n\")), mdx(\"p\", null, \"We've added a \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"mapActionCreatorsToProps\"), \" function that takes the \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"dispatch\"), \" function as an argument. It returns the result of a call to \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"bindActionCreators\"), \" with our \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"GalleryActions\"), \" provided as an argument. Now if you log the props, you'll see that \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"Gallery\"), \" \", mdx(\"em\", {\n parentName: \"p\"\n }, \"no longer gets passed the \", mdx(\"inlineCode\", {\n parentName: \"em\"\n }, \"dispatch\"), \" function\"), \", and instead has a function called \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"selectImage\"), \" that we can use directly!\"), mdx(\"p\", null, \"To review, we've done several things:\"), mdx(\"ul\", null, mdx(\"li\", {\n parentName: \"ul\"\n }, \"created a reducer that contains the initial (default) state of our application and listens for actions\"), mdx(\"li\", {\n parentName: \"ul\"\n }, \"created a store that consumes the reducer and provides a dispatcher that we can use to dispatch actions\"), mdx(\"li\", {\n parentName: \"ul\"\n }, \"connected our Gallery component to the store\"), mdx(\"li\", {\n parentName: \"ul\"\n }, \"mapped the store's state to props that are passed to the Gallery\"), mdx(\"li\", {\n parentName: \"ul\"\n }, \"mapped an action creator function so that the Gallery can simply call \", mdx(\"inlineCode\", {\n parentName: \"li\"\n }, \"selectImage(image)\"), \" and the application state will update.\")), mdx(\"p\", null, \"How do we use these patterns and load data from the remote data source?\"), mdx(\"p\", null, \"This is where it gets interesting! {% emoji wink %}\"), mdx(\"h2\", null, \"Asyncronous activity?\"), mdx(\"p\", null, \"You may hear the term \\\"side effects\\\" used when discussing a functional style of programming. Side effects are things that occur outside the boundaries of the application. Within our cozy bubble, side effects aren't really a problem, but when we reach out to a remote service the bubble is pierced. We lose some control, and we have to accept that fact.\"), mdx(\"p\", null, \"In Redux, \", mdx(\"strong\", {\n parentName: \"p\"\n }, \"reducers don't have side effects\"), \". This means that \", mdx(\"strong\", {\n parentName: \"p\"\n }, \"reducers don't handle async activity in our application\"), \". We can't use them to load our remote data because \", mdx(\"strong\", {\n parentName: \"p\"\n }, \"reducers are pure functions with no side effects\"), \".\"), mdx(\"p\", null, \"Redux is wonderful, and if you don\\u2019t have and side-effects like asynchronous activity you could stop right here. If you\\u2019re creating more than the most trivial example, it is likely that you are loading data from a service, and this is of course async.\"), mdx(\"blockquote\", null, mdx(\"p\", {\n parentName: \"blockquote\"\n }, mdx(\"strong\", {\n parentName: \"p\"\n }, \"note:\"), \" one of the coolest aspects of Redux is how tiny it is. It does so very little! It is intended to solve a very limited problem scope. Most applications will need to solve \", mdx(\"strong\", {\n parentName: \"p\"\n }, \"lots\"), \" of problems! Luckily Redux provides the concept of \\\"middleware\\\", which are basically bits of code that sit in the midel of the action -> reducer -> store triangle and provide a mechanism for introducing side effects like async calls to remote servers\")), mdx(\"p\", null, \"One approach is to use \", mdx(\"strong\", {\n parentName: \"p\"\n }, mdx(\"a\", {\n parentName: \"strong\",\n \"href\": \"https://en.wikipedia.org/wiki/Thunk\"\n }, \"thunks\")), \" with the \", mdx(\"a\", {\n parentName: \"p\",\n \"href\": \"https://github.com/gaearon/redux-thunk\"\n }, \"redux-thunk\"), \" middleware. Thunks work great, but can get confusing for sequences of actions and can be challenging to test effectively.\"), mdx(\"p\", null, \"Consider our image gallery application. When the application loads, it needs to:\"), mdx(\"ul\", null, mdx(\"li\", {\n parentName: \"ul\"\n }, \"request an array of images from the server\"), mdx(\"li\", {\n parentName: \"ul\"\n }, \"display some notification that the images are loading\"), mdx(\"li\", {\n parentName: \"ul\"\n }, \"select an initial image for display when the results have been received\"), mdx(\"li\", {\n parentName: \"ul\"\n }, \"handle any errors that might occur\")), mdx(\"p\", null, \"This is all before the user has clicked anything in the application!\"), mdx(\"p\", null, \"So how do we do it?\"), mdx(\"p\", null, \"This is where \", mdx(\"strong\", {\n parentName: \"p\"\n }, \"redux-saga\"), \" can be of great service to our application!\"), mdx(\"h2\", null, \"redux-saga\"), mdx(\"p\", null, \"redux-saga is built to handle asynchronous actions in our Redux applications. It provides middleware and a handful of effects methods that make building complex sequences of asynchronous actions a breeze.\"), mdx(\"p\", null, \"A saga is a \", mdx(\"strong\", {\n parentName: \"p\"\n }, \"generator\"), \" function. Generators are an ES2015 addition to JavaScript. This might be your first encounter with generator functions, and if that\\u2019s the case, they might be a little weird. If that is the case, take a few minutes to read \", mdx(\"a\", {\n parentName: \"p\",\n \"href\": \"https://www.2ality.com/2015/03/es6-generators.html\"\n }, \"ES6 Generators in Depth\"), \" and watch this \", mdx(\"a\", {\n parentName: \"p\",\n \"href\": \"https://egghead.io/lessons/ecmascript-6-generators\"\n }, \"short generators video\"), \". Don\\u2019t fret to much if you\\u2019re still scratching your head. To use redux-saga you won\\u2019t need a PhD in JavaScript Async Programming. Promise.\"), mdx(\"p\", null, \"Because of the way generators work, we are able to create flat sequences of commands describing complex workflows within our application. The entire image loading sequence described above could look like this:\"), mdx(\"pre\", null, mdx(\"code\", {\n parentName: \"pre\",\n \"className\": \"language-javascript\"\n }, \"export function* loadImages() {\\n try {\\n const images = yield call(fetchImages);\\n yield put({ type: 'IMAGES_LOADED', images });\\n yield put({ type: 'IMAGE_SELECTED', image: images[0] });\\n } catch (error) {\\n yield put({ type: 'IMAGE_LOAD_FAILURE', error });\\n }\\n}\\n\\nexport function* watchForLoadImages() {\\n while (true) {\\n yield take('LOAD_IMAGES');\\n yield call(loadImages);\\n }\\n}\\n\")), mdx(\"h3\", null, \"The first saga\"), mdx(\"p\", null, \"We'll start with a simple example of a saga, and then we will configure redux-saga to connect it to our application. Create a file called \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"saga.js\"), \" in the source folder and add the following:\"), mdx(\"pre\", null, mdx(\"code\", {\n parentName: \"pre\",\n \"className\": \"language-javascript\"\n }, \"export function* sayHello() {\\n console.log('hello');\\n}\\n\")), mdx(\"p\", null, \"Our saga is simply a generator function. You can tell by the little \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"*\"), \" after \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"function*\"), \". It's called the \\\"super star\\\" {% emoji star %}!\"), mdx(\"p\", null, \"Now in \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"main.js\"), \" we will import our new function and execute it.\"), mdx(\"pre\", null, mdx(\"code\", {\n parentName: \"pre\",\n \"className\": \"language-diff\"\n }, \"import \\\"babel-polyfill\\\";\\n\\nimport React from 'react';\\nimport ReactDOM from 'react-dom';\\n\\nimport Gallery from './Gallery';\\n\\nimport { createStore } from 'redux'\\nimport {Provider} from 'react-redux';\\nimport reducer from './reducer'\\n\\n+import {sayHello} from './sagas';\\n+sayHello();\\n\\nconst store = createStore(reducer);\\n\\nReactDOM.render(\\n
\\n \\n ,\\n document.getElementById('root')\\n);\\n\")), mdx(\"p\", null, \"No matter how long you stare at the console, your \\\"hello\\\" will never arrive {% emoji cry %}\"), mdx(\"p\", null, \"This is because \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"sayHello\"), \" is a \", mdx(\"strong\", {\n parentName: \"p\"\n }, \"generator\"), \"! Generators don't execute immediately. If you changed the line to \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"sayHello().next();\"), \" your greating will appear. Don't worry, we won't call \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"next\"), \" all the time. Like Redux, redux-saga is built to remove pain and bolierplate and make our development experience more pleasurable.\"), mdx(\"h2\", null, \"Configure redux-saga\"), mdx(\"pre\", null, mdx(\"code\", {\n parentName: \"pre\",\n \"className\": \"language-diff\"\n }, \"import \\\"babel-polyfill\\\";\\n\\nimport React from 'react';\\nimport ReactDOM from 'react-dom';\\n\\nimport Gallery from './Gallery';\\n\\n-import { createStore } from 'redux'\\n+import { createStore, applyMiddleware } from 'redux'\\n+import createSagaMiddleware from 'redux-saga'\\nimport {Provider} from 'react-redux';\\nimport reducer from './reducer'\\n\\nimport {sayHello} from './sagas';\\n-sayHello()\\n\\n-const store = createStore(reducer);\\n+const store = createStore(\\n+ reducer,\\n+ applyMiddleware(createSagaMiddleware(sayHello))\\n+);\\n\\nReactDOM.render(\\n
\\n \\n ,\\n document.getElementById('root')\\n);\\n\")), mdx(\"p\", null, \"We've imported the \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"applyMiddleware\"), \" function from Redux, and the \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"createSagaMiddleware\"), \" from \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"redux-saga\"), \". When we create the store, we need to supply Redux with the middleware that we want to use. In this case we call \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"applyMiddleware\"), \" and send it the result of \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"createSagaMiddleware(sayHello)\"), \". Behind the scenes redux-saga loads in the \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"sayHello\"), \" function, and politely calls the initial \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"next\"), \" for us.\"), mdx(\"p\", null, \"It should greet you in the console!\"), mdx(\"p\", null, \"Now let's build a saga for loading images.\"), mdx(\"h2\", null, \"Loading Images with a Saga\"), mdx(\"p\", null, \"We'ill get rid of the \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"sayHello\"), \" saga and replace it with a \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"loadImages\"), \" saga in \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"sagas.js\"), \".\"), mdx(\"pre\", null, mdx(\"code\", {\n parentName: \"pre\",\n \"className\": \"language-diff\"\n }, \"-export function* sayHello() {\\n- console.log('hello');\\n-}\\n\\n+export function* loadImages() {\\n+ console.log('load some images please')\\n+}\\n\")), mdx(\"p\", null, \"We can't forget to update \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"main.js\"), \" as well:\"), mdx(\"pre\", null, mdx(\"code\", {\n parentName: \"pre\",\n \"className\": \"language-diff\"\n }, \"import \\\"babel-polyfill\\\";\\n\\nimport React from 'react';\\nimport ReactDOM from 'react-dom';\\n\\nimport Gallery from './Gallery';\\n\\nimport { createStore, applyMiddleware } from 'redux'\\nimport {Provider} from 'react-redux';\\nimport createSagaMiddleware from 'redux-saga'\\nimport reducer from './reducer'\\n\\n-import {sayHello} from './sagas';\\n+import {loadImages} from './sagas';\\n\\nconst store = createStore(\\n reducer,\\n- applyMiddleware(createSagaMiddleware(sayHello))\\n+ applyMiddleware(createSagaMiddleware(loadImages))\\n);\\n\\nReactDOM.render(\\n
\\n \\n ,\\n document.getElementById('root')\\n);\\n\")), mdx(\"p\", null, \"And now the saga is loading. Let's add our \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"fetchImages\"), \" method we used earlier inside of \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"sagas.js\"), \":\"), mdx(\"pre\", null, mdx(\"code\", {\n parentName: \"pre\",\n \"className\": \"language-javascript\"\n }, \"const API_KEY = 'a46a979f39c49975dbdd23b378e6d3d5';\\nconst API_ENDPOINT = `https://api.flickr.com/services/rest/?method=flickr.interestingness.getList&api_key=${API_KEY}&format=json&nojsoncallback=1&per_page=5`;\\n\\nconst fetchImages = () => {\\n return fetch(API_ENDPOINT).then(function(response) {\\n return response.json().then(function(json) {\\n return json.photos.photo.map(\\n ({ farm, server, id, secret }) =>\\n `https://farm${farm}.staticflickr.com/${server}/${id}_${secret}.jpg`,\\n );\\n });\\n });\\n};\\n\\nexport function* loadImages() {\\n const images = yield fetchImages();\\n console.log(images);\\n}\\n\")), mdx(\"p\", null, \"The \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"fetchImages\"), \" method returns a promise. We are going to call \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"fetchImages\"), \", but we are going to use the \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"yield\"), \" keyword. By dark arts and sorcery, generators \", mdx(\"em\", {\n parentName: \"p\"\n }, \"understand promises\"), \", and as the console log will show, we've yielded an array of image urls. Looking at \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"loadImages\"), \", it looks like typical syncronous code. The \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"yield\"), \" keyword is the secret sauce that lets us code in this syncronous style for asyncronous activity.\"), mdx(\"h3\", null, \"Encapsulating our async API requests\"), mdx(\"p\", null, \"Let's define the api we want to use in its own file. It is nothing special. In fact, it's the same code we used earlier to load Flickr images. We're going to create a file called \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"flickr.js\"), \" in the src folder:\"), mdx(\"pre\", null, mdx(\"code\", {\n parentName: \"pre\",\n \"className\": \"language-javascript\"\n }, \"const API_KEY = 'a46a979f39c49975dbdd23b378e6d3d5';\\nconst API_ENDPOINT = `https://api.flickr.com/services/rest/?method=flickr.interestingness.getList&api_key=${API_KEY}&format=json&nojsoncallback=1&per_page=5`;\\n\\nexport const fetchImages = () => {\\n return fetch(API_ENDPOINT).then(function(response) {\\n return response.json().then(function(json) {\\n return json.photos.photo.map(\\n ({ farm, server, id, secret }) =>\\n `https://farm${farm}.staticflickr.com/${server}/${id}_${secret}.jpg`,\\n );\\n });\\n });\\n};\\n\")), mdx(\"p\", null, \"This isn't strictly required, but it makes a lot of sense to me. We are at the very \", mdx(\"strong\", {\n parentName: \"p\"\n }, \"boundaries of our application\"), \", where things are a bit messy. By encapsulating the mechanics of the interaction with the remote API, our code will be cleaner and easier to update. It also makes it dead simple to \", mdx(\"em\", {\n parentName: \"p\"\n }, \"completely swap out\"), \" the image service provider! Nice.\"), mdx(\"p\", null, \"Our \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"saga.js\"), \" should now look like this:\"), mdx(\"pre\", null, mdx(\"code\", {\n parentName: \"pre\",\n \"className\": \"language-javascript\"\n }, \"import { fetchImages } from './flickr';\\n\\nexport function* loadImages() {\\n const images = yield fetchImages();\\n console.log(images);\\n}\\n\")), mdx(\"p\", null, \"We still need to get data out of our saga and into the application state. To handle this, we will utilize \\\"effects\\\" provided by redux-saga.\"), mdx(\"h3\", null, \"Update the application from a saga\"), mdx(\"p\", null, \"We could probably call our saga with the \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"dispatch\"), \" function or store as an argument, but that approach would be unpleasant and perhaps a tad confusing over time. Instead, we'll rely on a method provided by redux-saga called \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"put\"), \".\"), mdx(\"p\", null, \"First we will update \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"reducer.js\"), \" to handle a new action type \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"IMAGES_LOADED\")), mdx(\"pre\", null, mdx(\"code\", {\n parentName: \"pre\",\n \"className\": \"language-diff\"\n }, \"const defaultState = {\\n+ images: []\\n}\\n\\nexport default function images(state = defaultState, action) {\\n switch(action.type) {\\n case 'IMAGE_SELECTED':\\n return {...state, selectedImage: action.image};\\n+ case 'IMAGES_LOADED':\\n+ return {...state, images: action.images};\\n default:\\n return state;\\n }\\n}\\n\")), mdx(\"p\", null, \"We added the case, and also deleted the hard coded URLs from the \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"defaultState\"), \". The \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"IMAGES_LOADED\"), \" case now returns an updated state that includes images delivered by the action.\"), mdx(\"p\", null, \"Next we will update the saga:\"), mdx(\"pre\", null, mdx(\"code\", {\n parentName: \"pre\",\n \"className\": \"language-diff\"\n }, \"import {fetchImages} from './flickr';\\n+import {put} from 'redux-saga/effects';\\n\\nexport function* loadImages() {\\n const images = yield fetchImages();\\n+ yield put({type: 'IMAGES_LOADED', images})\\n}\\n\")), mdx(\"p\", null, \"After importing \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"put\"), \", we add another line to \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"loadImages\"), \". It \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"yield\"), \"s the result of the call the \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"put\"), \" which sends along an action object. Behind the scenes redux-saga dispatches that for us, and the reducer receives the message!\"), mdx(\"p\", null, \"What if we don't want to loadImages implicitly like this, simply because we have wired up a saga? How do we trigger a saga with a specific type of action?\"), mdx(\"h3\", null, \"Triggering saga workflows with actions\"), mdx(\"p\", null, \"Sagas become much more useful if we have the ability to trigger their workflows with Redux actions. When we do this, we can leverage the power of sagas from any component in our app. First we will create a new saga called \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"watchForLoadImages\"), \".\"), mdx(\"pre\", null, mdx(\"code\", {\n parentName: \"pre\",\n \"className\": \"language-diff\"\n }, \"import {fetchImages} from './flickr';\\n-import {put} from 'redux-saga/effects';\\n+import {put, take} from 'redux-saga/effects';\\n\\nexport function* loadImages() {\\n const images = yield fetchImages();\\n yield put({type: 'IMAGES_LOADED', images})\\n}\\n\\n+export function* watchForLoadImages() {\\n+ while(true) {\\n+ yield take('LOAD_IMAGES');\\n+ yield loadImages();\\n+ }\\n+}\\n\")), mdx(\"p\", null, \"This new saga uses a \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"while\"), \" loop so that it is always active and ready. Inside of the loop we are yielding a call to a new method from redux-saga called \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"take\"), \". Take listens for actions of a given type, and when they occur, it advances the saga to the next yield. In this case, we are yielding a call to \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"loadImages\"), \", which initiates the loading of images.\"), mdx(\"pre\", null, mdx(\"code\", {\n parentName: \"pre\",\n \"className\": \"language-diff\"\n }, \"import \\\"babel-polyfill\\\";\\n\\nimport React from 'react';\\nimport ReactDOM from 'react-dom';\\n\\nimport Gallery from './Gallery';\\n\\nimport { createStore, applyMiddleware } from 'redux'\\nimport {Provider} from 'react-redux';\\nimport createSagaMiddleware from 'redux-saga'\\nimport reducer from './reducer'\\n\\n-import {loadImages} from './sagas';\\n+import {loadImages} from './watchForLoadImages';\\n\\nconst store = createStore(\\n reducer,\\n- applyMiddleware(createSagaMiddleware(loadImages))\\n+ applyMiddleware(createSagaMiddleware(watchForLoadImages))\\n);\\n\\nReactDOM.render(\\n
\\n \\n ,\\n document.getElementById('root')\\n);\\n\")), mdx(\"p\", null, \"After updating \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"main.js\"), \", the application is no longer loading images. We can add a \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"loadImages\"), \" action to our action creators.\"), mdx(\"pre\", null, mdx(\"code\", {\n parentName: \"pre\",\n \"className\": \"language-diff\"\n }, \"export const IMAGE_SELECTED = 'IMAGE_SELECTED';\\n+const LOAD_IMAGES = 'LOAD_IMAGES';\\n\\nexport function selectImage(image) {\\n return {\\n type: IMAGE_SELECTED,\\n image\\n }\\n}\\n\\n+export function loadImages() {\\n+ return {\\n+ type: LOAD_IMAGES\\n+ }\\n+}\\n\")), mdx(\"p\", null, \"Since we have already bound the action creators, all we need to do is call the action from the \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"Gallery\"), \" component.\"), mdx(\"pre\", null, mdx(\"code\", {\n parentName: \"pre\",\n \"className\": \"language-diff\"\n }, \"export class Gallery extends Component {\\n+ componentDidMount() {\\n+ this.props.loadImages();\\n+ }\\n render() {\\n\")), mdx(\"h3\", null, \"Blocking and non-blocking effects\"), mdx(\"p\", null, \"This works fine for our application, but there is a broader issue that we should be concerned with. The \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"watchForLoadImages\"), \" sage contains \", mdx(\"strong\", {\n parentName: \"p\"\n }, \"blocking\"), \" effects. What does that mean? Well, it means that we can only execute a single \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"LOAD_IMAGES\"), \" workflow at a time! It isn't obvious with a simple example like this, because we actually only load images once, but it is definitely a consideration. In fact, the general practice when listening for action evens is to use the \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"fork\"), \" effect instead of \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"yield loadImages()\"), \".\"), mdx(\"pre\", null, mdx(\"code\", {\n parentName: \"pre\",\n \"className\": \"language-diff\"\n }, \"export function* watchForLoadImages() {\\n while(true) {\\n yield take('LOAD_IMAGES');\\n- yield loadImages();\\n+ yield fork(loadImages); //be sure to import it!\\n }\\n}\\n\")), mdx(\"p\", null, \"Using the \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"fork\"), \" helper will convert our \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"watchForLoadImages\"), \" into a non-blocking saga that can be executed regardless of whether or not a previous call is in progress. redux-saga \", mdx(\"a\", {\n parentName: \"p\",\n \"href\": \"https://yelouafi.github.io/redux-saga/docs/basics/UsingSagaHelpers.html\"\n }, \"provides two helpers\"), \", \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"takeEvery\"), \" and \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"takeLatest\"), \" that assist in these situations.\"), mdx(\"h3\", null, \"Selecting the default image\"), mdx(\"p\", null, \"Sagas are sequences of actions, so we can add more aspects to a saga easily.\"), mdx(\"pre\", null, mdx(\"code\", {\n parentName: \"pre\",\n \"className\": \"language-diff\"\n }, \"import {fetchImages} from './flickr';\\nimport {put, take, fork} from 'redux-saga/effects';\\n\\nexport function* loadImages() {\\n const images = yield fetchImages();\\n yield put({type: 'IMAGES_LOADED', images})\\n+ yield put({type: 'IMAGE_SELECTED', image: images[0]})\\n}\\n\\nexport function* watchForLoadImages() {\\n while(true) {\\n yield take('LOAD_IMAGES');\\n yield fork(loadImages);\\n }\\n}\\n\")), mdx(\"p\", null, \"As part of the \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"loadImages\"), \" workflow, we can yield another call to \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"put\"), \" with the \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"IMAGE_SELECTED\"), \" action type and send along the image we want to select when images are loaded.\"), mdx(\"h3\", null, \"Handling errors\"), mdx(\"p\", null, \"If something goes wrong inside of the saga, we might want to notify the application so that it can respond accordingly. Do do this, we simply wrap the workflow in a try/catch block, and yield a \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"put\"), \" with a nitification that has the error as the payload.\"), mdx(\"pre\", null, mdx(\"code\", {\n parentName: \"pre\"\n }, \"import {fetchImages} from './flickr';\\nimport {put, take, fork} from 'redux-saga/effects';\\n\\nexport function* loadImages() {\\n+ try {\\n const images = yield fetchImages();\\n yield put({type: 'IMAGES_LOADED', images})\\n yield put({type: 'IMAGE_SELECTED', image: images[0]})\\n+ } catch(error) {\\n+ yield put({type: 'IMAGE_LOAD_FAILURE', error})\\n+ }\\n}\\n\\nexport function* watchForLoadImages() {\\n while(true) {\\n yield take('LOAD_IMAGES');\\n yield fork(loadImages);\\n }\\n}\\n\")), mdx(\"h2\", null, \"Testing Sagas\"), mdx(\"p\", null, \"Using Redux makes testing most of our app a breeze. Check out \", mdx(\"a\", {\n parentName: \"p\",\n \"href\": \"https://egghead.io/series/react-testing-cookbook\"\n }, \"this egghead course\"), \" for lots of techniques for testing React in general.\"), mdx(\"p\", null, \"One of the awesome aspects of redux-saga is how easy it makes testing these bits of asynchronous code. Testing async javascript can be a real chore. With sagas, we don't need to jump through hoops to test this core functionality of our application. Sagas take the pain out of aync tests! Which means we will write more tests. Right?\"), mdx(\"p\", null, \"We're going to use \", mdx(\"a\", {\n parentName: \"p\",\n \"href\": \"https://github.com/substack/tape\"\n }, \"tape\"), \". Let's set up a few tests for our saga.\"), mdx(\"pre\", null, mdx(\"code\", {\n parentName: \"pre\"\n }, \"import test from 'tape';\\nimport {put, take} from 'redux-saga/effects'\\nimport {watchForLoadImages, loadImages} from './sagas';\\nimport {fetchImages} from './flickr';\\n\\ntest('watchForLoadImages', assert => {\\n const generator = watchForLoadImages();\\n\\n assert.end();\\n});\\n\")), mdx(\"p\", null, \"We'll go ahead and import everything we need for now, and add a single test. The test function takes a name and a function as arguments. Inside of the function, we create an instance of the sage generator. Armed with that instance, we can start advancing the saga to test each step.\"), mdx(\"pre\", null, mdx(\"code\", {\n parentName: \"pre\",\n \"className\": \"language-diff\"\n }, \"import test from 'tape';\\nimport {put, take} from 'redux-saga/effects'\\nimport {watchForLoadImages, loadImages} from './sagas';\\nimport {fetchImages} from './flickr';\\n\\ntest('watchForLoadImages', assert => {\\n const generator = watchForLoadImages();\\n\\n+ assert.deepEqual(\\n+ generator.next().value,\\n+ false,\\n+ 'watchForLoadImages should be waiting for LOAD_IMAGES action'\\n+ );\\n\\n assert.end();\\n});\\n\")), mdx(\"p\", null, \"The \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"assert.deepEqual\"), \" method takes two values and checks to see if they are equal (deeply!). The first is a call \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"generator.next().value\"), \" which advances the generator and gets the value. The next value is simple \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"false\"), \". We want to see it fail! The final argument is a description of the expected behavior.\"), mdx(\"p\", null, \"Run \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"npm test\"), \" in the project folder to see the result.\"), mdx(\"pre\", null, mdx(\"code\", {\n parentName: \"pre\"\n }, \"\\u2716 watchLoadImages should be waiting for LOAD_IMAGES action\\n-----------------------------------------------------------\\n operator: deepEqual\\n expected: |-\\n false\\n actual: |-\\n { TAKE: 'LOAD_IMAGES' }\\n\")), mdx(\"p\", null, \"The test fails as expected and the results are interesting. The actual result is \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"{ TAKE: 'LOAD_IMAGES' }\"), \", which is the output we receive when we call \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"take('LOAD_IMAGES');\"), \". In fact, our saga could yield an object instead of calling \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"take\"), \", but \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"take\"), \" gives us a little sugar and eliminates annoying keystrokes.\"), mdx(\"pre\", null, mdx(\"code\", {\n parentName: \"pre\",\n \"className\": \"language-diff\"\n }, \"import test from 'tape';\\nimport {put, take} from 'redux-saga/effects'\\nimport {watchForLoadImages, loadImages} from './sagas';\\nimport {fetchImages} from './flickr';\\n\\ntest('watchForLoadImages', assert => {\\n const generator = watchForLoadImages();\\n\\n assert.deepEqual(\\n generator.next().value,\\n- false\\n+ take('LOAD_IMAGES'),\\n 'watchForLoadImages should be waiting for LOAD_IMAGES action'\\n );\\n\\n assert.end();\\n});\\n\")), mdx(\"p\", null, \"We can simply call \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"take\"), \" in our test and get the result we need!\"), mdx(\"pre\", null, mdx(\"code\", {\n parentName: \"pre\",\n \"className\": \"language-diff\"\n }, \"import test from 'tape';\\nimport {put, take} from 'redux-saga/effects'\\nimport {watchForLoadImages, loadImages} from './sagas';\\nimport {fetchImages} from './flickr';\\n\\ntest('watchForLoadImages', assert => {\\n const generator = watchForLoadImages();\\n\\n assert.deepEqual(\\n generator.next().value,\\n take('LOAD_IMAGES'),\\n 'watchForLoadImages should be waiting for LOAD_IMAGES action'\\n );\\n\\n+ assert.deepEqual(\\n+ gen.next().value,\\n+ false,\\n+ 'watchForLoadImages should call loadImages after LOAD_IMAGES action is received'\\n+ );\\n\\n assert.end();\\n});\\n\")), mdx(\"p\", null, \"Our next test makes sure that the \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"loadImages\"), \" saga is called as the next step in the workflow. We'll add a false value here to see the result.\"), mdx(\"p\", null, \"For a brief moment, let's update our saga code to yield the \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"loadImages\"), \" saga:\"), mdx(\"pre\", null, mdx(\"code\", {\n parentName: \"pre\",\n \"className\": \"language-diff\"\n }, \"export function* watchForLoadImages() {\\n while(true) {\\n yield take('LOAD_IMAGES');\\n+ yield loadImages();\\n- yield fork(loadImages); //be sure to import it!\\n }\\n}\\n\")), mdx(\"p\", null, \"Now when you run the tests, you will see.\"), mdx(\"pre\", null, mdx(\"code\", {\n parentName: \"pre\"\n }, \"\\u2716 watchForLoadImages should call loadImages after LOAD_IMAGES action is received\\n---------------------------------------------------------------------------------\\n operator: deepEqual\\n expected: |-\\n false\\n actual: |-\\n { _invoke: [Function: invoke] }\\n\")), mdx(\"p\", null, \"Hmm, \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"{ _invoke: [Function: invoke] }\"), \" is \", mdx(\"em\", {\n parentName: \"p\"\n }, \"definitely\"), \" not as obvious as the simple object that we got when yeilding \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"take\"), \".\"), mdx(\"p\", null, \"This is a problem. Luckily it's one that redux-saga has solved in a nice way with effects like \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"fork\"), \". \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"take\"), \", \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"fork\"), \", and other effect methods return and easily testable simple object. The object is a \", mdx(\"em\", {\n parentName: \"p\"\n }, \"set of instructions\"), \" for redux-saga to execute. This is beautiful for testing because we don't have to worry about the actual side effects (like remote service calls). All we care about are the commands we are requesting to be executed.\"), mdx(\"p\", null, \"Let's update the saga to use \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"fork\"), \" again:\"), mdx(\"pre\", null, mdx(\"code\", {\n parentName: \"pre\",\n \"className\": \"language-diff\"\n }, \"export function* watchForLoadImages() {\\n while(true) {\\n yield take('LOAD_IMAGES');\\n- yield loadImages();\\n+ yield fork(loadImages);\\n }\\n}\\n\")), mdx(\"p\", null, \"We will go back to \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"yield fork(loadImages)\"), \" instead of yielding \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"loadImages\"), \" directly. Note that we aren't executing \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"loadImages\"), \". Instead we are \", \"*\", \"passing the function \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"loadImages\"), \" as an argument to \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"fork\")), mdx(\"p\", null, \"Run \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"npm test\"), \" again:\"), mdx(\"pre\", null, mdx(\"code\", {\n parentName: \"pre\"\n }, \"\\u2716 watchForLoadImages should call loadImages after LOAD_IMAGES action is received\\n---------------------------------------------------------------------------------\\n operator: deepEqual\\n expected: |-\\n false\\n actual: |-\\n { FORK: { args: [], context: null, fn: [Function: loadImages] } }\\n\")), mdx(\"p\", null, \"Instead of a function invocation, we get a plain object. That object has the \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"loadImages\"), \" function embedded in it. The application loads exactly the same in the browser, but now we can easily test this step in the saga workflow.\"), mdx(\"pre\", null, mdx(\"code\", {\n parentName: \"pre\",\n \"className\": \"language-diff\"\n }, \"import test from 'tape';\\nimport {put, take} from 'redux-saga/effects'\\nimport {watchForLoadImages, loadImages} from './sagas';\\nimport {fetchImages} from './flickr';\\n\\ntest('watchForLoadImages', assert => {\\n const generator = watchForLoadImages();\\n\\n assert.deepEqual(\\n generator.next().value,\\n take('LOAD_IMAGES'),\\n 'watchForLoadImages should be waiting for LOAD_IMAGES action'\\n );\\n\\n assert.deepEqual(\\n generator.next().value,\\n- false,\\n+ yield fork(loadImages),\\n 'watchForLoadImages should call loadImages after LOAD_IMAGES action is received'\\n );\\n\\n assert.end();\\n});\\n\")), mdx(\"p\", null, \"Testing the \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"loadImages\"), \" saga is similar. We need to update \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"yield fetchImages\"), \" to \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"yield fork(fetchImages)\"), \".\"), mdx(\"pre\", null, mdx(\"code\", {\n parentName: \"pre\",\n \"className\": \"language-javascript\"\n }, \"test('loadImages', assert => {\\n const gen = loadImages();\\n\\n assert.deepEqual(\\n gen.next().value,\\n call(fetchImages),\\n 'loadImages should call the fetchImages api',\\n );\\n\\n const images = [0];\\n\\n assert.deepEqual(\\n gen.next(images).value,\\n put({ type: 'IMAGES_LOADED', images }),\\n 'loadImages should dispatch an IMAGES_LOADED action with the images',\\n );\\n\\n assert.deepEqual(\\n gen.next(images).value,\\n put({ type: 'IMAGE_SELECTED', image: images[0] }),\\n 'loadImages should dispatch an IMAGE_SELECTED action with the first image',\\n );\\n\\n const error = 'error';\\n\\n assert.deepEqual(\\n gen.throw(error).value,\\n put({ type: 'IMAGE_LOAD_FAILURE', error }),\\n 'loadImages should dispatch an IMAGE_LOAD_FAILURE if an error is thrown',\\n );\\n\\n assert.end();\\n});\\n\")), mdx(\"p\", null, \"Take note of the last \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"assert\"), \". It's testing the \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"catch\"), \" by using \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"throw\"), \" instead of \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"next\"), \" on the generator. Another cool feature is the ability to send values in. Notice that we've created an \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"images\"), \" constant, and we pass that into \", mdx(\"inlineCode\", {\n parentName: \"p\"\n }, \"next\"), \". The saga \", mdx(\"em\", {\n parentName: \"p\"\n }, \"uses the value we pass in\"), \" for the next step in the sequence.\"), mdx(\"p\", null, \"It's awesome, and this level of control is a dream when it comes to testing async activity!\"), mdx(\"h2\", null, \"What's next?\"), mdx(\"p\", null, \"You can \", mdx(\"a\", {\n parentName: \"p\",\n \"href\": \"https://github.com/joelhooks/egghead-react-redux-image-gallery\"\n }, \"check out the full code for this example on github\"), \". I'm considering making a course on egghead to cover this. Would you be interested? \", mdx(\"a\", {\n parentName: \"p\",\n \"href\": \"https://twitter.com/jhooks\"\n }, \"Let me know on twitter\"), \"!\"), mdx(\"p\", null, \"If you wanted to expand the example a bit, you might:\"), mdx(\"ul\", null, mdx(\"li\", {\n parentName: \"ul\"\n }, \"make it a slide show where the image advances to the next image on a timer\"), mdx(\"li\", {\n parentName: \"ul\"\n }, \"allow the user to search Flickr with keywords\"), mdx(\"li\", {\n parentName: \"ul\"\n }, \"drop in another API that delivers images\"), mdx(\"li\", {\n parentName: \"ul\"\n }, \"allow the user to select what APIs to search\")), mdx(\"p\", null, \"We've only touched the surface of generators, but even at this level, hopefully you can see how useful they can be when coupled with the redux-saga library, Redux, and React.\"), mdx(\"p\", null, mdx(\"img\", {\n parentName: \"p\",\n \"src\": \"https://s3.amazonaws.com/f.cl.ly/items/2s2q3B3x0Q04131p3V0C/jhooks_2016-Mar-20.jpg?v=db21427c\",\n \"alt\": null\n })));\n}\n;\nMDXContent.isMDXComponent = true;","frontmatter":{"title":"Build an Image Gallery Using React, Redux and redux-saga","date":"March 20, 2016","banner":null,"slug":null,"keywords":null}}},"pageContext":{"id":"493e8c7c-a6cd-5985-993f-b224a7e193d3","prev":{"id":"f124d64b-676e-5754-ab6a-4062665be57b","parent":{"name":"2016-04-08-setting-goals-for-my-version-of-success","sourceInstanceName":"legacy"},"excerpt":"There is this amazing conference in Las Vegas once a year called MicroConf. It's a gathering of like-minded entrepreneurs that (for the most part) are boot-strapping their business. This means that they aren't taking outside investment, specifically…","fields":{"title":"Setting goals for (my version of) success.","slug":"blog/2016/04/08/setting-goals-for-my-version-of-success","date":"2016-04-08T00:00:00.000Z"}},"next":{"id":"123cb5d0-32dc-52ee-89c1-94ee10149488","parent":{"name":"2015-12-31-2015-year-in-review","sourceInstanceName":"legacy"},"excerpt":"It’s been two years since I woke up dreading a workday. And I work almost every day. When we first set out to build egghead, I told my parter John that all he had to do was make amazing content, and that I would do the rest . {% emoji flushed %} For…","fields":{"title":"2015 Year in Review","slug":"blog/2015/12/31/2015-year-in-review","date":"2015-12-31T00:00:00.000Z"}}}},
"staticQueryHashes": ["1045846374"]}
![](\\\"https://cloud.egghead.io/2G021h3t2K10/download/egghead-logo-head-only.svg\\\"){kind=logo}
\\n