Interpretation of redux-saga principle (code example)

The content of this article is about the interpretation of redux-saga principle (code example). It has certain reference value. Friends in need can refer to it. I hope it will be helpful to you.

The author has recently been working on some backend projects, using Ant Design Pro, which uses redux-saga to process asynchronous data flows. This article will give a simple interpretation of the principle of redux-saga and will implement a A simple version of redux-saga.

Automatic process control of Generator function

In redux-saga, saga refers to some long-term operations, represented by the generator function. The power of the generator function is that it can manually pause and resume execution, and can interact with data outside the function body. See the following example:

function *gen() {
  const a = yield 'hello';
  console.log(a);
}
cont g = gen();
g.next(); // { value: 'hello', done: false }
setTimeout(() => g.next('hi'), 1000)  // 此时 a => 'hi'   一秒后打印‘hi'

It can be seen that when the generator function performs the next operation completely depends on The external scheduling timing, and its internal execution status are also determined by external input, which makes the generator function convenient for asynchronous process control. For example, we first read the content of a file as a query parameter, then request a query interface and print out the returned content:

function getParams(file) {
  return new Promise(resolve => {
    fs.readFile(file, (err, data) => {
      resolve(data)
    })
  })
}
function getContent(params) {
  //  request返回promise
  return request(params)
}
function *gen() {
  const params = yield getParams('config.json');
  const content = yield getContent(params);
  console.log(content);
}

We can manually control the execution of the gen function:

const g = gen();
g.next().value.then(params => {
  g.next(params).value.then(content => {
    g.next(content);
  })
})

The above can achieve our purpose, but it is too cumbersome. What we want is that the generator function can be automatically executed. We can write a simple automatic execution function as follows:

function genRun(gen) {
  const g = gen();
  next();
  function next(err, pre) {
    let temp;
    (err === null) && (temp = g.next(pre));
    (err !== null) && (temp = g.throw(pre));

    if(!temp.done) {
      nextWithYieldType(temp.value, next);
    }
  }
}
function nextWithYieldType(value, next) {
  if(isPromise(value)) {
    value
      .then(success => next(null, success))
      .catch(error => next(error))
  } 
}
genRun(gen);

At this time, the generator function can be automatically executed. In fact, we can find that the internal state of the generator is completely determined by nextWithYieldType. We can execute different processing logic according to the type of yield.

Effect

In fact, sagaMiddleware.run(saga) can be regarded as similar to genRun(saga), and saga is composed of effects, then the effect is What? Explanation of redux-saga official website: one The effect is a Plain Object JavaScript object containing some elements that will be used by the saga middleware instructions to execute. redux-saga provides many Effect creators, such as call, put, take, etc. Take call as an example:

function saga*() {
  const result = yield call(genPromise);
  console.log(result);
}

call(genPromise) generates an effect, which may be similar to the following :

{
  isEffect: true,
  type: 'CALL',
  fn: genPromise
}

In fact, the effect only indicates the intention, and the actual behavior is completed by nextWithYieldType similar to the above, for example:

function nextWithYieldType(value, next) {
  ...
  if(isCallEffect(value)) {
    value.fn(). then(success => next(null, success)).catch(error => next(error))  
  } 
}

When the promise returned by the genPromise function is resolved, it will be printed. The results.

Producers and consumers

Observe the following example

function *saga() {
  yield take('TEST');
  console.log('test...');
}

sagaMiddleware.run(test);

saga will block at take('TEST'), only dispatch is executed ({type: 'TEST'}) before saga can continue to run (note: the dispatch method at this time is packaged by sagaMiddleware). This feels very much like take is a producer, waiting for disaptch consumption. In fact, take is just an Effect generator, and the specific processing logic is still completed in nextWithYieldType, similar to:

function nextWithYieldType(value, next) {
  ...
  // take('TEST')生成的effect简单的认为是  {isEffect: true, type: 'TAKE', name: 'TEST'}
  if(isTakeEffect(value)) {
    channel.take({pattern: value.name, cb: params => next(null, params)})  
  } 
}

channel is a task generator. It has two methods: take to generate tasks and put to consume tasks:

function channel() {
  /*
    task = {
      pattern,
      cb
    }
  */
  let _task = null;

  function take(task) {
    _task = task;
  }

  function put(pattern, args) {
    if(!_task) return;
    if(pattern == _task.pattern) _task.cb.call(null, args);
  }

  return {
    take,
    put
  }
}

Obviously the task is consumed when dispatch is executed. This work is done in sagaMiddleware , similar to the following:

const sagaMiddleware = store => {
  return next => action => {
    next(action);
    
    const { type, ...payload } = action;
    channel.put(type, payload);
  }
}

Seeing here we can find that what we need to do is to continuously improve the nextWithYieldType function. After completing the logic corresponding to put, fork, and takeEvery, a redux with basic functions -saga was born, so I won’t go into details about the implementation of these functions.

The above is the detailed content of Interpretation of redux-saga principle (code example). For more information, please follow other related articles on the PHP Chinese website!