Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Dec 02 09:46
    JaapWeijland commented #2142
  • Dec 02 09:20
    JaapWeijland commented #2142
  • Dec 02 09:20
    JaapWeijland closed #2142
  • Dec 01 14:14
    Andarist commented #2142
  • Dec 01 14:07
    JaapWeijland opened #2142
  • Nov 27 22:41
    github-actions[bot] synchronize #2069
  • Nov 27 22:41
    github-actions[bot] edited #2069
  • Nov 27 22:41

    github-actions[bot] on master

    Version Packages (compare)

  • Nov 27 22:40

    Andarist on master

    Fixed typo (#2136) (compare)

  • Nov 27 22:40
    Andarist closed #2136
  • Nov 27 11:35
    Andarist commented #2141
  • Nov 27 09:52
    mikabytes opened #2141
  • Nov 18 23:34
    hubertokf opened #2140
  • Nov 17 20:28
    Slapbox opened #2139
  • Nov 17 11:18
    egorovsa commented #884
  • Nov 17 07:28
    Andarist commented #1828
  • Nov 16 23:08
    Slapbox commented #1828
  • Nov 16 07:26
    JasonXiaoSpace commented #1883
  • Nov 15 15:09
    Andarist commented #1800
  • Nov 15 11:29
    gadiGuesty commented #1800
Dimitri Mitropoulos
@dimitropoulos
I've been struggling with this for about 6 hours and I've tried everything under the sun I can think of including:
  • introducing every combination of the babel polyfills, regenerator-transforms, runtimes, etc.
  • testing to make sure generators transpile in my project at all (they do)
  • flipping every option I can think of in my tsconfig
Edoardo Gallo
@EdoardoGallo_twitter

Hey guys! I'm looking for the best way to manage these sagas

  • classic LOGIN/LOGOUT process but - after login and before logout - i need to manage a websocket connection. For example:
LOGIN_REQUEST -> OPEN_WS_REQUEST

LOGOUT_REQUEST -> CLOSE_WS_REQUEST

Does the rootSaga need to watch for the WS actions or is it better that the LOGIN/LOGOUT workers handle some logic?

Within the LOGIN/LOGOUT workers i can fork/dispatch the actions to OPEN/CLOSE the websocket. Looking for the best approach in this case.
Thanks!
Alan.He
@alanhg
anyone know this issue
about exception handing
joystick
@joystick
Hi, could you please advise me with following?
I'm loading react app with URL query string arguments. I would like to check if they are valid and fire an API call to fetch app data from server.
I got URL query string params using query-string in componentDidMount() but now I would like to dispatch actions to update state with extracted params and fire an API calls from redux-saga. What's the recommended way to do so?
Katherine Xu
@zhixu
Hi all, would anyone happen to know if there is support for the redux batch() command with Redux saga ( https://react-redux.js.org/api/batch )?
stephouphoune
@stephouphoune
Hi all,
I have a question about redux-saga, here is my problem. When I’m rendering a list on React, I’m dispatching the exact same saga multiple times concurrently for the same API call. I’m wondering if there is a way to tell saga to automatically cancel the duplicates and only call one of them.
Cheers.
Andrew Craswell
@AndrewCraswell
Looking for some quick advice. I'm building a generic Saga wrapper at my company to let people connect to an API endpoint, and specify a Saga EffectCreator. As the EffectCreator (takeEvery, takeLatest, etc) process the API method, it assigns a unique Id to each request and tracks it in the store so the component can check the status. This works great for takeEvery, but when 3 components request the same endpoint simultaneously while using takeLeading, the subsequent tasks get ignored. This leaves entries in my Redux store that are still designated as isFetching, and my components think their data is still loading. How can I track (a) which tasks were actually taken, (b) which were ignored, and (c) dispatch an action to tell my component that the request was superseded?
It feels like the only way to accomplish this may be to recreate the EffectCreators and add my own custom handling logic in each, but I really want to avoid that.
Rob Cecil
@robcecil
Hello, what is the Redux Saga pattern for calling streaming APIs ?
rupertbulquerin
@rupertbulquerin

Hey guys.. I'm having response is undefined on my request using sagas

export function* getCompanies({ payload }: any) {
  try {
    const { data: response } = yield call(api.get, '/companies-list', {
      params: {
        keyword: payload,
      },
    });
    console.error(response);
    const { data } = response;
    yield put(handleFetchCompaniesAsync.success(data.companies));
  } catch ({ response }) {
    yield all([
      put(handleFetchCompaniesAsync.failure(response.data)),
      put(handleAsyncNotification(response.data)),
    ]);
  }
}

export default function* companySagas() {
  yield takeLatest(handleFetchCompaniesAsync.request, getCompanies);
}

What could be the problem here?

Jonathan Jacobs
@jonathanj
I have an issue with Fast Refresh on React Native, my sagas are started multiple times and in particular I have several eventChannels that are never closed. I've read redux-saga/redux-saga#1961 but I don't think helps me figure out how to properly close my channels. The pattern I'm using here is something like this:
const channel = eventChannel(…) // Unsubscribe is returned etc.
yield takeEvery(channel, process)
I'm not sure what I have to do to know when to close the channel. takeEvery returns a task (and is non-blocking) so I would need some way to say "wait until this saga is cancelled, and then close the channel" but I don't know how to express that.
Jonathan Jacobs
@jonathanj
I've come up with the following method for a single takeEvery:
const channel = …
try {
  const task = yield takeEvery()
  yield join(task)
} finally {
  if (yield cancelled()) {
    channel.close()
  }
}
I don't know if this is silly, or if there's a better way but I can't see another way to ensure my generator function doesn't finish (i.e. run out of things to yield) and leave me with no way to detect cancellation. This seems like it would be a fairly common issue though, maybe I'm just searching for the wrong thing?
Is this a real pattern or is this an anti-pattern? yield all([takeEvery(…), takeEvery(…), takeEvery(…)])
lieut z
@Virgil-N_gitlab
@dimitropoulos Hi, I have the same problems. What's your solution?
Tawan
@ttawan
Guy, need some help. I want to use 'useApolloClient' in saga context, how can I do that? Any recommendation? I trying to create saga middle or redux middle to use setContext but not working as I expected.
Henrique Barcelos
@hbarcelos

Hey guys, I have a more of a conceptual problem I've been struggling with in the past couple of days.

I have to subscribe to N event streams and react to the events occurring in them. Those are standard Node-like event-emitters.
I also have a facade API which should merge those N event streams together into a single one.
My initial thought was to convert the subscription into an async generator:

  async function* subscribe({ fromBlock = 0, toBlock = 'latest', filter = {} } = {}) {
    let res;
    let rej;
    let promise = new Promise((resolve, reject) => {
      res = resolve;
      rej = reject;
    });

    const subscription = linguo.events.allEvents({ fromBlock, toBlock, filter });
    subscription
      .on('data', event => {
        res(event);

        promise = new Promise((resolve, reject) => {
          res = resolve;
          rej = reject;
        });
      })
      .on('error', err => {
        rej(err);
        promise = new Promise((resolve, reject) => {
          res = resolve;
          rej = reject;
        });
      });

    while (true) {
      try {
        const event = await promise;
        yield event;
      } catch (err) {
        console.warn(`Canceling event subscription for contract ${linguo.options.address}`, err);
        break;
      }
    }

    subscription.unsubscribe();
  }

Then to combine the multiple subscribe() calls, I've found this merge operator from the repeatable library.

Then I happily wrote my saga:

export async function* subscribeSaga(action) {
  const { fromBlock, toBlock, filter } = action.payload ?? {};

  const linguoApi = yield getContext('linguoApi');
  const subscription = yield call([linguoApi, 'subscribe'], { fromBlock, toBlock, filter });
  for await (const evt of subscription) {
    console.log('>>>', evt);
  }
}

Only to find out then that redux-saga does not support async generators :/

Any ideas?

Mihai Moraru
@mihaimoraru19
Hi guys, I just posted an article on medium about a simple way of using redux saga (+ reduxsauce). Check it here. I'd appreciate any feedback.
Cooper Maruyama
@coopermaruyama
Is there an idiomatic way to replace the following super common pattern with redux-saga?
componentDidUpdate(prevProps) {
  const didIdChange = prevProps.id !== this.props.id;

  if (didIdChange) {
   this.props.fetchData(this.props.id);
  }
}