21–30 of 99 posts
I wish they would just revert their site to where it was 2 years ago instead of doing anything new. The new version just looks like yet another Tinder clone, and doesn't resemble anymore what Okcupid was good at: Good profiles, which allowed to get an initial impression about people beyond "I like their looks".
Earlier quoted context omitted.
> 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 Re…
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 machi…
People on whom it was forced on, and who disagreed with those opinions, were VERY vocal, and pushed most of the other crap, which fragmented the community and muddied the message.
From my point of view as a end user, the only real difference between now and then, is that the vocal minority is now the majority, and they shifted focus to match (which is a good decision). Obviously I can't speak for Mark, but it's how it looks like as an external observer (pun not intended)
This adds extra overhead on every single mutation as opposed to Redux, where your the current state is automatically passed into your reducer, and you don't need to worry about writing anything after you update - the store handles that itself by updating the state to the result of the reducer.
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 really do need to understand their cache well, and I also dislike having to deal with things like __typename, which I feel is an implementation detail that unfortunately gets foisted onto the end developer. Sometimes __typename is a royal pain in the butt. The a…
> 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 Re…
You’re not solving any problems, you’re just promoting your framework.
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 really do need to understand their cache well, and I also dislike having to deal with things like __typename, which I feel is an implementation detail that unfortunately gets foisted onto the end developer. Sometimes __typename is a royal pain in the butt. The a…
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 advanc…
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/re...
[1] https://blog.isquaredsoftware.com/2020/02/blogged-answers-wh...
[2] https://redux-toolkit.js.org/api/configureStore
Earlier quoted context omitted.
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 advanc…
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 resu…
None of what you're saying matters in the scheme of things. You can get everything you need from
const { types, actions } = createActions([ 'ACTION_NAME', ...]);
The middleware approach is more straightforward than thunks and far more maintainable. Reifying that as "best practice" is only going to continue to spread this anti-pattern because no real application is about "just grabbing some data for a bit" and inevitably that one api call expands into many, not to mention all of the other side effect related and asynchronous functionality that one has to deal with in user interfaces.
I would definitely encourage all of my competitors to use GraphQL. Nothing like getting a free six-month lead. That's two months they spend learning GraphQL, two months introducing a mystery-meat binding layer and learning that, and two months debugging it all and pulling their hair out. And no, using a giant third-party lock-in toolkit like Hasura or Apollo is not a response.
Earlier quoted context omitted.
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 resu…
What's with the copy paste spam on every one of your posts? None of what you're saying matters in the scheme of things. You can get everything you need from const { types, actions } = createActions([ 'ACTION_NAME', ...]); Where createActions is an exercise for the reader, but shouldn't take more than a few lines. Then go about your business from there. Adding another layer of framework over the top of this stuff only…
const todosSlice = createSlice({
name: 'todos',
initialState: [],
reducers: {
addTodo(state, action) {
const { id, text } = action.payload
state.push({ id, text, completed: false })
},
toggleTodo(state, action) {
const todo = state.find(todo => todo.id === action.payload)
if (todo) {
todo.completed = !todo.completed
}
}
}
})
export const { addTodo, toggleTodo } = todosSlice.actions
export default todosSlice.reducer
Earlier quoted context omitted.
> 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 Re…
Man I wish you’d quit spamming every redux thread with this stuff. You’re not solving any problems, you’re just promoting your framework.
He makes an effort to address specific points, doesn't get defensive or angry, and seems to take criticism and feedback seriously. He has responded to my own critiques of Redux in a reasoned way.
I think that if someone is going to express claims or opinions about a library on HN then we should be happy to see an expert response, rather than letting the discussion become one-sided. Sure, there could be a bias, but I think we all win by having both sides represented.
Do we really want to discourage that?
I would definitely encourage all of my competitors to use GraphQL. Nothing like getting a free six-month lead. That's two months they spend learning GraphQL, two months introducing a mystery-meat binding layer and learning that, and two months debugging it all and pulling their hair out. And no, using a giant third-party lock-in toolkit like Hasura or Apollo is not a response.
As in industry, we're okay with a frontend JS framework - React (or vue or angular) being part of the baseline set of investments you make when building a website. It's just considered the cost of doing business. (But that wasn't always the case! I for one don't miss using jQuery...)
I imagine GraphQL will get to a similar place - where the investment is more well understood and accepted.
(Of course common sense still applies - if a website is simple enough that it doesn't need a frontend js framework then don't use one - same goes for graphql, don't use it if you really don't need it)