7 ms·

I largely came to the same conclusion, including going back to Redux. I have found using Apollo for client side state very cumbersome and even difficult. You re

• acemarke 6y ago
  > I really do think if Redux hadn't been so concerned about being opinionated way back when, it'd be far better received today Can you clarify what you mean here? From my perspective as a Redux maintainer, most of the concerns I've seen expressed about Redux over the last few years really didn't focus on whether it was "opinionated" or not. It's been a combination of: - Not understanding the original intent behind Redux's design and the historical context that led to it being designed that way [0] - People being told they _had_ to use Redux with React, even when it really wasn't a good fit for their use case - The "incidental complexity" of common Redux usage patterns [1], most of which were due to the way the docs and tutorials showed things (writing `const ADD_TODO = "ADD_TODO"`, separate files for actions/constants/reducers, etc). - Changes in the ecosystem leading to other tools whose use cases overlapped with why you might have chosen to use Redux previously All that said, yeah, we've made a concerted effort in the last year or so to be much more opinionated about how you _ought_ to use Redux, based on how we've seen people use it. Those opinions are built into our new official Redux Toolkit package [0], which is now our recommended approach for writing Redux logic, and the Redux Style Guide docs page [1], which lists our guidance on best practices and patterns for using Redux. I also just published a brand-new "Redux Essentials" core docs tutorial [2], which teaches "how to use Redux, the right way", using our latest recommended tools and practices like Redux Toolkit and the React-Redux hooks API. We unfortunately can't wave a magic wand and get folks to update the seemingly endless parade of Medium tutorials and Youtube videos that show the older approaches to using Redux, but I'm hopeful that the emphasis on using RTK will make it a lot easier for folks to learn and use Redux going forward. [0] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-1/ https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta... [1] https://blog.isquaredsoftware.com/2019/10/redux-starter-kit-1.0/#dealing-with-complexity https://blog.isquaredsoftware.com/2019/10/redux-starter-kit-... [2] https://redux-toolkit.js.org https://redux-toolkit.js.org [3] https://redux.js.org/style-guide/style-guide https://redux.js.org/style-guide/style-guide [4] https://redux.js.org/tutorials/essentials/part-1-overview-concepts https://redux.js.org/tutorials/essentials/part-1-overview-co...
  • city41 6y ago
    You certainly have more experience and context than me. But my experience with Redux over the years is there was so many ways to do it leading to a lot of uncertainty. Do you use a switch statement or something like redux-actions? Do you use the duck pattern, where do all these things live in the codebase? What package do you grab for async actions? Are actions 1:1 with DOM events, or are they more like a state machine? How do you compose reducers? Should you compose reducers? I think this led to a lot of confusion and uncertainty with Redux. "I'm using it, but I'm not sure I'm using it effectively." I think a lot of ineffective implementations caused a lot of developers to get a really bad taste. I can unfortunately say at my previous company, just mentioning Redux would make just about every developer cringe. I hated that. But I feel like a lot of what is making Redux more successful these days is the more opinionated releases like the toolkit and the new docs. Since they've only been around about a year now, I think it's reasonable to conclude that before their existence, Redux didn't have a strong opinion a new developer could lean on. It's similar to React, which also tries to avoid opinions. I can appreciate and understand that approach (for both React and Redux), but I do wonder would React be better if there was a stronger opinion on things like CSS, routing, state, etc? I don't mean to criticize. I love Redux and am very grateful for it. This is just how I experienced it over the years.
    • acemarke 6y ago
      I certainly get where you're coming from, and agree that all of the questions you listed are things we didn't express opinions on previously and had to decide for yourself. Still, the bulk of the concerns I've seen over time fall into the categories I've listed - I just really don't remember seeing many comments from folks who were concerned that they "weren't using it effectively" as a particular pain point. Perhaps that was being felt, but expressed in different ways? (I definitely think a lot of people _haven't_ been using it effectively, but didn't necessarily realize it.) In any case, the highly positive response to RTK and the docs work tells me we're headed in the right direction. My next task is to rewrite the existing low-level "Basics/Advanced" tutorial sequence to remove outdated references, show simpler patterns, and improve explanations. I've got my notes on things I want to change here: https://github.com/reduxjs/redux/issues/3855 https://github.com/reduxjs/redux/issues/3855 If you or anyone else has any particular feedback on things you don't like with that existing tutorial or would like to see covered better, please comment and let me know!
• weeksie 6y ago
  I think the biggest problem is the default approach of using thunks for handling async state. You get these "opinionated" frameworks that then reinforce terrible design ideas. If it's simple just put handle async stuff in situ. If it's more complex, use custom middleware. Thunks, sagas, etc are all anti-patterns. The single worst thing the Redux docs did was give the impression that middleware was some kind of advanced functionality only useful for library designers. Most of your app logic should probably live in middleware. The "redux toolkit" or whatever doesn't help with that, it only reifies questionable practices. Skip it. Write a simple utility for generating actions/types, and then go about your business.
  • acemarke 6y ago
    I'll have to disagree with that, on multiple levels. Thunks are simply an approach for writing reusable async logic that has access to `dispatch` and `getState`, without being tied to a specific store [0]. While I do think more people would benefit from writing middleware for their own particular use cases, most people just want to have a place where they can fetch some data and dispatch an action containing the result. Thunks make that straightforward. Thunks are also by far the most widely used async middleware across the Redux ecosystem. These are all reasons why we settled on thunks as the default async middleware included in RTK [1]. (It is worth noting that with the advent of `useDispatch` and hooks, you can write some fetching logic directly in a `useEffect` call vs a thunk, but there's still benefits to using thunks in many cases.) RTK has specific support for thunks in two ways. `configureStore` automatically adds the thunk middleware to the store setup [2], and we have a `createAsyncThunk` API [3] that handles the common pattern of dispatching actions based on the results of a promise. However, nothing about that requires that you use thunks with RTK. You can still add whatever middleware you want to the store, whether it be sagas, observables, custom middleware, or something else. > The "redux toolkit" or whatever doesn't help with that, it only reifies questionable practices. Skip it. Write a simple utility for generating actions/types, and then go about your business. I'm afraid this is entirely wrong. RTK encodes the best practices recommended in our Style Guide docs page [4], and includes APIs that simplify your Redux logic considerably: RTK improves your Redux code in many ways: - `configureStore` lets you set up a Redux store in one line with good defaults built in, including automatically adding the Redux-Thunk middleware, enabling the Redux DevTools Extension, and warning about accidental mutations - `createSlice` generates action creators and action types for you automatically - all you have to do is write reducers and given them reasonably descriptive names. In addition, it uses Immer internally to let you write "mutating" reducer logic that is safely turned into correct immutable updates, so no more nested spread operators. - As mentioned, `createAsyncThunk` handles the typical use case of dispatching actions before and after making an async request - just fetch your data and return a promise, and it'll dispatch actions automatically. - `createEntityAdapter` provides prebuilt reducer logic for typical collection management operations, like `upsertMany`, `addOne`, `removeAll`, etc. So, RTK _is_ that "simple utility for generating actions", and more. It's an official package from the Redux team (ie, myself and the other maintainers), you can pick and choose which of its APIs you actually use in your app, and you can mix and match which parts of your Redux logic are written with RTK with parts that might still be written with other approaches. [0] https://blog.isquaredsoftware.com/presentations/workshops/redux-fundamentals/side-effects.html#/4 https://blog.isquaredsoftware.com/presentations/workshops/re... [1] https://blog.isquaredsoftware.com/2020/02/blogged-answers-why-redux-toolkit-uses-thunks-for-async-logic/ https://blog.isquaredsoftware.com/2020/02/blogged-answers-wh... [2] https://redux-toolkit.js.org/api/configureStore https://redux-toolkit.js.org/api/configureStore [3] https://redux-toolkit.js.org/api/createAsyncThunk https://redux-toolkit.js.org/api/createAsyncThunk [4] https://redux.js.org/style-guide/style-guide https://redux.js.org/style-guide/style-guide
• bengale 6y ago
  Like when you send data to a mutation and it complains about it having a __typename field that they bloody added. Had some pain with that this week.