3 ms·

As a company that runs both Django Rest Framework and GraphQL backends, there is one phenomenal argument in favor of GQL: Apollo Client. When you just want a si

As a company that runs both Django Rest Framework and GraphQL backends, there is one phenomenal argument in favor of GQL: Apollo Client. When you just want a simple, normalized reactive data store it’s really amazing (even though the Apollo kids seem to break it with every minor release). Loads of redux boilerplate go right out the window.

acemarke 7y ago
Per the last comment, please check out our new official Redux Toolkit package. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once without writing any action creators or action types by hand: https://redux-toolkit.js.org https://redux-toolkit.js.org Not saying it's a replacement for Apollo (since Redux itself doesn't provide anything around data fetching), but we specifically created RTK to eliminate the concerns around "Redux boilerplate".
- damidekronik 7y ago
  Still requires boilerplate for thunks, which in my case is most redux actions. Also I think you still don't support for specifying same reducer for many actions (for example as an array - https://github.com/piotrwitek/typesafe-actions https://github.com/piotrwitek/typesafe-actions). The immutable update logic however is amazing and I am glad I got introduced to it by you!
  - acemarke 7y ago
    Not sure what you mean by "boilerplate for thunks". You write thunks the same way you always have. And yes, `createSlice` explicitly supports responding to actions that were defined elsewhere in the app, using the `extraReducers` argument: https://redux-toolkit.js.org/api/createSlice#extrareducers https://redux-toolkit.js.org/api/createSlice#extrareducers Although... are you saying that you want one reducer function to handle many different actions in one slice? Just define the reducer outside the slice itself, and pass it as the handler for each action: createSlice({ name: "someSlice", initialState, reducers: { action1: someCaseReducer, action2: someCaseReducer, } }) Did something similar in my own app recently at work, where multiple slices all needed to handle loading data similarly. So, I wrote a couple generic reducers, and passed them in to each of the slices.

acemarke 7y ago

Per the last comment, please check out our new official Redux Toolkit package. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once without writing any action creators or action types by hand: https://redux-toolkit.js.org https://redux-toolkit.js.org Not saying it's a replacement for Apollo (since Redux itself doesn't provide anything around data fetching), but we specifically created RTK to eliminate the concerns around "Redux boilerplate".

damidekronik 7y ago
Still requires boilerplate for thunks, which in my case is most redux actions. Also I think you still don't support for specifying same reducer for many actions (for example as an array - https://github.com/piotrwitek/typesafe-actions https://github.com/piotrwitek/typesafe-actions). The immutable update logic however is amazing and I am glad I got introduced to it by you!
- acemarke 7y ago
  Not sure what you mean by "boilerplate for thunks". You write thunks the same way you always have. And yes, `createSlice` explicitly supports responding to actions that were defined elsewhere in the app, using the `extraReducers` argument: https://redux-toolkit.js.org/api/createSlice#extrareducers https://redux-toolkit.js.org/api/createSlice#extrareducers Although... are you saying that you want one reducer function to handle many different actions in one slice? Just define the reducer outside the slice itself, and pass it as the handler for each action: createSlice({ name: "someSlice", initialState, reducers: { action1: someCaseReducer, action2: someCaseReducer, } }) Did something similar in my own app recently at work, where multiple slices all needed to handle loading data similarly. So, I wrote a couple generic reducers, and passed them in to each of the slices.