Question

我有一个登录弹出窗口，它将“ isLoggingIn”布尔值映射到redux存储。分派登录请求操作时，传奇会拦截该操作并发送该登录正在处理的另一个操作，Reducer会将其接收，并将'isLoggingIn'布尔值设置为true。

我的商店：

export interface AppState {
  playerToken:string,  
  loginOpen: boolean,
  loginProcessing: boolean
}

登录传奇：

function* loginUser(action: any) {
  yield put({ type: (LOGIN + PROCESSING) });

  try {
    const response = yield call(apiCall, 'api/token', 'POST', { username: action.payload.username, password: action.payload.password });

   if (response) 
   {
      yield put({ type: (LOGIN + SUCCESS), payload: response.data });
  }
  catch ({ statusCode }) {
    if (statusCode === 401) {
      yield put({ type: (LOGIN + FAIL), payload: { error: "Invalid username or password" } })
    }
    console.log(statusCode);
  }
}

一旦错误完成了登录的传奇，它将调度一个操作，reducer将其设置为商店中的'loginError'字符串，并将isLoggingIn设置为false，否则将isLoggingIn设置为false并使用用户登录ID已设置，提示弹出窗口隐藏自身（即isVisible = {this.props.playerToken == undefined）。

这似乎非常复杂，但是我不确定如何使用Redux原理来分解。我强烈感觉到isProcessingLogin应该是组件状态的一部分，但是该组件不知道发送登录尝试事件后发生了什么，除非它正在侦听道具中的内容，否则它永远无法知道。 / p>

随着各种需要执行的操作和必须在商店中设置为true / false并正确映射到组件中的各种'isCreatingXModel'布尔值，情况变得更加糟糕。

这是应该如何工作的redux，还是我在它不属于的地方过度使用它？

如果应该使用redux的话，它的好处是什么？我已经在网上阅读了很多有关单点真相的文章，但是这些事情都可以在不需要疯狂的redux膨胀的情况下完成，我读过人们说不要使用redux直到您需要它时，但这意味着我“当我“需要时”将redux集成时，将在两个概念上分开的代码区域中进行api调用，最后，倡导者们认为，我看到的最大优势之一是其能够及时倒带和前进。很棒，但是它不能在任何它可以操作的后端连接到数据库的实时应用程序中运行，除非作为倒带的一部分进行了最后一个api调用操作。

Answer 1

请记住，这些全都是我的意见。

1。您可能不需要sagas（或thunk或其他“异步” redux插件）

请记住，redux仅是状态管理。 API调用可以使用带有或不带有redux的原始javascript编写。例如：这是不使用sagas的流程的基本复制：

例如

import { setLoadingStatus } from './actions'
import { store } from './reducers' // this is what is returned by a createStore call

export function myApiCall(myUrl, fetchOptions) {
  store.dispatch(setLoadingStatus('loading'))

  return fetch(myUrl, fetchOptions)
    .then((response) => {
      store.dispatch(setLoadingStatus('succeeded', data))
      // do stuff with response data (maybe dispatch a different action to use it?)
    })
    .catch((error) => {
      store.dispatch(setLoadingStatus('failed', error))
      // do stuff 
    })
}

请注意store.dispatch的使用。在React-Redux中有一个有趣的概念，即您只能使用mapDispatchToProps调度动作，但是幸运的是，这不是真的。

我用需要状态和可选数据的一项替换了您的多项行动。这将减少您需要编写的动作和简化程序的数量，但是您的动作历史记录将更难阅读。（只有三个动作，而不是三个动作。）

2。您可能不需要redux。

如果您不使用redux，则上面的示例函数可能看起来基本相同-想象将store.dispatch调用替换为this.setState调用。将来，当您添加它时，您仍然必须编写所有reducer，action，action creator的样板，但这只会比一开始就痛苦得多。

如上所述，在与React一起工作时，我通常会使用Redux，而内置状态管理在任何大型应用程序中的思维导图都很糟糕。

有两个相反的经验法则：

将redux用于需要在各组件之间共享的状态
对所有状态使用redux并获得单一事实来源

我倾向于第二个。我讨厌在大型React组件树的叶子中寻找错误的状态。这绝对是一个没有“正确”答案的问题。

异步动作的当前状态之类的内容应存储在react-redux应用程序中的什么地方？

1 个答案:

1。您可能不需要sagas（或thunk或其他“异步” redux插件）

2。您可能不需要redux。