5 ms·

React is starting to turn from a novel, but essentially simple idea into a clusterfuck mess.

scrollaway 8y ago
Care to write a substantial contributing comment, or do you intend to keep this random complaint about the simplification of a common pattern in React as shallow as possible? Edit: No really, I'd like to hear why you think this would make React a "clusterfuck mess" rather than... simpler.
- dbbk 8y ago
  I actually agree, this is a mess. This is wildly more complex and confusing than the current state of affairs.
  - acemarke 8y ago
    What specific aspects do you feel are more complex and confusing?
- nyclowkey 8y ago
  I agree React is turning into a clusterfuck mess.For evidence look at the pull requests https://github.com/facebook/react/pulls?q=is%3Apr+is%3Aclosed https://github.com/facebook/react/pulls?q=is%3Apr+is%3Aclose... Even the developers have no idea WTF is going on.
  - scrollaway 8y ago
    You're not showing me anything of note here. Is this some low key trolling or am I missing something?
  - Sacho 8y ago
    what are we supposed to see here?
jagger27 8y ago
I feel like Vue.js is the solution for people who feel like this.
TopWaltz 8y ago
Why? I feel like this solution makes using React even simpler.
rhacker 8y ago
I feel like Redux was a clusterfuck mess and this is the cleanup. Excuse the language. Edit: Expanding on this and why (I think) this solution is cleaner: * In redux you ended up with pointless constant piles of strings that are the named actions. Totally useless in a JS world where a function that IS an action can take up that mantle. * While reducers are a good way to make state consistent, using redux for state management when you actually don't have 17 different producers and 1 consumer it's major overkill. Most of the time you actually have 1 or 2 event (and value changing) producers and MANY consumers on the screen at one time. * When you DO need a reducer, instead of making that the norm, this new hook library does provide a useReducer function that works exactly like that- and guess what? NO STRING CONSTANTS YAY. I think the only downside I can think of is TTDebugging might be complicated to create under this dome, but was the same issue for stateful classes. That being said, it might be more possible now that the control is placed in a single feature area.
- acemarke 8y ago
  I'll point out that Ryan's demo _did_ show using string constants with `useReducer()`. Also, our new `redux-starter-kit` library auto-generates action types and action creators for you, _and_ modifies the action creators so they can be used for the `case someAction` comparisons: https://github.com/reduxjs/redux-starter-kit https://github.com/reduxjs/redux-starter-kit .
  - rhacker 8y ago
    What is the downside to changing the example here: https://reactjs.org/docs/hooks-reference.html#usereducer https://reactjs.org/docs/hooks-reference.html#usereducer To something without strings and hard-coding the actual "reduction code" to something like export const increment = (state) => ({count: state.count + 1}); And give modern JS languages like typescript import the increment function and use it directly? Why are we so attached to these action type strings?
    - acemarke 8y ago
      Redux is based on the Flux Architecture. In particular, it carries on the idea of describing events or state update requests as plain objects. One of the key insights of Redux is that you can then write additional logic to act on those actions as they progress through a centralized pipeline (ie, middleware). I've seen lots of Redux-alikes that are "Redux, but without reducers/actions/etc". They mostly claim that they're making things simpler, and in some ways, maybe they do. But, what they're also doing is throwing away the ability to act on those actions as they get dispatched. If I "dispatch a function", I can't programmatically inspect its contents, modify it, log it, attach additional info to it, or all the other myriad of useful things you can do with a plain object. As for the type strings, you need some kind of useful identifier to distinguish different action objects. You could use Symbols, but those don't serialize well. You could use numbers, but those aren't very meaningful when viewed in an action history log. Ultimately, you want your app's reducer logic, middleware, and the action history itself to be readable and semantically meaningful.

Care to write a substantial contributing comment, or do you intend to keep this random complaint about the simplification of a common pattern in React as shallow as possible? Edit: No really, I'd like to hear why you think this would make React a "clusterfuck mess" rather than... simpler.

dbbk 8y ago
I actually agree, this is a mess. This is wildly more complex and confusing than the current state of affairs.
- acemarke 8y ago
  What specific aspects do you feel are more complex and confusing?
nyclowkey 8y ago
I agree React is turning into a clusterfuck mess.For evidence look at the pull requests https://github.com/facebook/react/pulls?q=is%3Apr+is%3Aclosed https://github.com/facebook/react/pulls?q=is%3Apr+is%3Aclose... Even the developers have no idea WTF is going on.
- scrollaway 8y ago
  You're not showing me anything of note here. Is this some low key trolling or am I missing something?
- Sacho 8y ago
  what are we supposed to see here?

jagger27 8y ago

I feel like Vue.js is the solution for people who feel like this.

TopWaltz 8y ago

Why? I feel like this solution makes using React even simpler.

rhacker 8y ago

I feel like Redux was a clusterfuck mess and this is the cleanup. Excuse the language. Edit: Expanding on this and why (I think) this solution is cleaner: * In redux you ended up with pointless constant piles of strings that are the named actions. Totally useless in a JS world where a function that IS an action can take up that mantle. * While reducers are a good way to make state consistent, using redux for state management when you actually don't have 17 different producers and 1 consumer it's major overkill. Most of the time you actually have 1 or 2 event (and value changing) producers and MANY consumers on the screen at one time. * When you DO need a reducer, instead of making that the norm, this new hook library does provide a useReducer function that works exactly like that- and guess what? NO STRING CONSTANTS YAY. I think the only downside I can think of is TTDebugging might be complicated to create under this dome, but was the same issue for stateful classes. That being said, it might be more possible now that the control is placed in a single feature area.

acemarke 8y ago
I'll point out that Ryan's demo _did_ show using string constants with `useReducer()`. Also, our new `redux-starter-kit` library auto-generates action types and action creators for you, _and_ modifies the action creators so they can be used for the `case someAction` comparisons: https://github.com/reduxjs/redux-starter-kit https://github.com/reduxjs/redux-starter-kit .
- rhacker 8y ago
  What is the downside to changing the example here: https://reactjs.org/docs/hooks-reference.html#usereducer https://reactjs.org/docs/hooks-reference.html#usereducer To something without strings and hard-coding the actual "reduction code" to something like export const increment = (state) => ({count: state.count + 1}); And give modern JS languages like typescript import the increment function and use it directly? Why are we so attached to these action type strings?
  - acemarke 8y ago
    Redux is based on the Flux Architecture. In particular, it carries on the idea of describing events or state update requests as plain objects. One of the key insights of Redux is that you can then write additional logic to act on those actions as they progress through a centralized pipeline (ie, middleware). I've seen lots of Redux-alikes that are "Redux, but without reducers/actions/etc". They mostly claim that they're making things simpler, and in some ways, maybe they do. But, what they're also doing is throwing away the ability to act on those actions as they get dispatched. If I "dispatch a function", I can't programmatically inspect its contents, modify it, log it, attach additional info to it, or all the other myriad of useful things you can do with a plain object. As for the type strings, you need some kind of useful identifier to distinguish different action objects. You could use Symbols, but those don't serialize well. You could use numbers, but those aren't very meaningful when viewed in an action history log. Ultimately, you want your app's reducer logic, middleware, and the action history itself to be readable and semantically meaningful.