Since I started using Mobx I'm actually enjoying using React purely as a rendering library and user input. No Redux, and certainly no setState.
I really don't see the point in hooks.
Introducing Hooks
151–160 of 310 posts
Re: Introducing Hooks
#152How the hell do you test the damn things?
Don't test implementation details.
Re: Introducing Hooks
#153Earlier quoted context omitted.
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 .
What is the downside to changing the example here: 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?
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.
Re: Introducing Hooks
#154Earlier quoted context omitted.
I can see both sides. I teach React to newish coders, and classes are easy for them to grasp...and then immediately create labyrinthine monoliths. To be fair, that's pretty much what happens to all newish coders who are learning classes. Learning to use classes responsibly is really just part of the learning, though that seems to be the part that instructors pawn off to the next guy. Once you learn how to use them ju…
Maybe newish coders should learn the language they are using. And of course there is typescript (and a gazillion of languages that can be transpiled to js these days), which synergizes very well with enterprise people and java/dotnet devs who never did a line of frontend before.
Maybe newish coders should learn the language they are using.
It's not a language thing. OOP discipline is a coding thing in general.
And of course there is typescript (and a gazillion of languages that can be transpiled to js these days), which synergizes very well with enterprise people and java/dotnet devs who never did a line of frontend before.
You sound like you don't actually understand why people like Typescript, or, more specifically, static typing.
Re: Introducing Hooks
#155I really wish React wouldn't add more state handling, because it's never been particularly good. I use MobX and loathe the overcomplication of stuff like e.g. Redux. Hooks look like a misguided attempt at addressing React's lack of automatic reactivity.
Re: Introducing Hooks
#156I went from skeptical to sold in five minutes. This API is absolutely beautiful. I have quite a few components in each of my projects that do nothing other than call lifecylcle methods (they render `props.children`). Composing them is sometimes easy, and sometimes awkward. Especially when trying to read a value back from a child component. With the hooks API, that child component can be rewritten as a simple hook, ma…
> I have quite a few components in each of my projects that do nothing other than call lifecylcle methods (they render `props.children`)
I have a few of those too, but I feel like ES7 decorators already solve this problem quite well (e.g. [1]). But I guess hook will generate better code for prepack than decorators will.
1: https://medium.com/@jihdeh/es7-decorators-in-reactjs-22f701a...
Re: Introducing Hooks
#157While I agree that class components has always felt like a workaround to bypass the limitations of function components, and that it's obviously annoying to rewrite a function component to a class component just to add a state or a lifecycle method, the following explanation sounds a bit silly to me: > In our observation, classes are the biggest barrier to learning React. You have to understand how this works in JavaS…
In the live talk, Sophie also discussed how Javascript classes are difficult for machines: minifiers aren't able to shorten the names of methods (because it's apparently hard to work out all the ways that the method could be invoked), and they cause stability problems with hot code reloading. So there are benefits beyond ease of use for humans. (Also, I'm pretty fluent in Javascript and I still forget to bind event h…
> because it's apparently hard to work out all the ways that the method could be invoked
Simple example case of a statement that makes it impossible to minify function names:
class Test { static func() { /* function code */ } }
test[prompt('function to call')]()Re: Introducing Hooks
#158> In our observation, classes are the biggest barrier to learning React. As someone who struggled hard with some aspects of learning react, i felt this to be the absolute opposite. Watching people to combine and spread logic over dozens of functional components, and drag in other external libraries like recompose to do stuff like lifecycle hooks, and using HoC's, just to avoid classes makes my head hurt. > Only call…
I feel the same way! Maybe I'm just getting older, but I like code to be boring. A class is something everyone can read and understand. If you have to navigate a maze of HOCs withStateHandlers, enchancers, redux actions, reducers and connectors you end up needing to open 10-20 files and jump around between as many functions to build a picture of how a component works. Considering code is read more often than written - that seems like a huge step backwards.
Hi, I'm Dan. I write boring code. I love Go because it's super boring.
I like to read boring code, write boring code, and then get on with my day. I don't like long walks through the codebase trying to understand how everything is wired up in a super-cool functional way. Get off my lawn kids.
Re: Introducing Hooks
#159Earlier quoted context omitted.
I don't think the issue is "what is a class". It's more that the lifecycle functions get tied into the class, and you end up with a ball of highly conditional logic. It's easy for newbies to just add stuff to make it work, but end up with a mess. React is the view layer, so the class concept of "here's some data and methods to alter it" doesn't really match with what happens - I don't know that components every shoul…
According to the article yes, the issue is "what is a class": "You have to understand how this works in JavaScript, which is very different from how it works in most languages. You have to remember to bind the event handlers." etc.
Eh, even in the same paragraph it says "The distinction between function and class components in React and when to use each one leads to disagreements even between experienced React developers."
Also, bits of class issues show up in the other complaints.
So, no, it's not just "what is a class" and it's a weird hill to die on. I feel like most of these responses to hooks in general just focus on the most trivial detail aka bikeshedding.
Re: Introducing Hooks
#160My gut reaction is that Hooks isn't the greatest addition to React. One thing I've always pitched about React is the clean and extremely explicit API (with `dangerouslySetInnerHTML` being my favourite example). The hooks API is taking the dangerous road down to implicitness and magic which can only ever mean bad things in my book. It's really not clear to me how calling the setter for these individual pieces of state…
Have you looked at what `React.Component.setState()` actually does under the hood? The logic isn't implemented in `React.Component` itself - instead, it tells the core React rendering logic to queue up a re-render. The real work is all inside React's internals. I agree that the `useState()` aspect _looks_ a bit magical, but it's ultimately doing the same thing that `setState()` does in the end. React already knows wh…
[deleted]