Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing Hooks

reactjs.org

Post reply on HN
Print view View original

291–300 of 310 posts

Re: Introducing Hooks

#291

Post by Aeolun »

acemarke wrote: post #289
Aeolun wrote: post #287

Earlier quoted context omitted.

I don’t really think there is a way around it if you go with the action/reducer/saga model. I enjoy my code fairly explicit, so writing a button click that invokes some request has me writing: - A click handler - 3 new action name consts (request, success, failure) - An action instantiation function that takes the necessary arguments for request. - A saga function that catches these request actions, runs a request, a…

Sagas are a great power tool, but I personally wouldn't use them for most simple API requests, largely because of the need for "signal actions" to trigger the logic. You might want to check out our new `redux-starter-kit` package [0], which can simplify some common use cases for things like action creators and reducers. There's also many other existing libraries to handle repetitive code like API requests as well [1]…

I think you need to use sagas for either all your logic, or none of it. Having it half/half just means you’re always searching for where something is located.

That said, thanks for the recommendations! I’ll check them out.

Re: Introducing Hooks

#292

Post by acemarke »

Aeolun wrote: post #291
acemarke wrote: post #289

Earlier quoted context omitted.

Sagas are a great power tool, but I personally wouldn't use them for most simple API requests, largely because of the need for "signal actions" to trigger the logic. You might want to check out our new `redux-starter-kit` package [0], which can simplify some common use cases for things like action creators and reducers. There's also many other existing libraries to handle repetitive code like API requests as well [1]…

I think you need to use sagas for either all your logic, or none of it. Having it half/half just means you’re always searching for where something is located. That said, thanks for the recommendations! I’ll check them out.

FWIW, I use sagas _and_ thunks in my own app, depending on what it is I need to do.

Also related, the new Redux FAQ entry on choosing between async middlewares: https://redux.js.org/faq/actions#what-async-middleware-shoul...

Re: Introducing Hooks

#293

Post by jnbiche »

tangent128 wrote: post #216
jnbiche wrote: post #201

Earlier quoted context omitted.

> You sound like you don't actually understand why people like Typescript, or, more specifically, static typing. Eh, in my experience, there are two types of Typescript users: 1) those users who appreciate the safety that type systems provide when used properly, and 2) those enterprise users of the language who have mostly only coded Java and C# and who like Typescript because it lets them write Java-style code for t…

Typescript doesn't do anything ES6 & Webpack don't already do; Javascript already lets you write Java-style code if you really want to.

Typescript significantly predates ES6 and Webpack. Java developers have been drawn to Typescript for over 5 years now.

Re: Introducing Hooks

#294

Post by cmx66 »

fiatjaf wrote: post #191
anonytrary wrote: post #137

Unpopular opinion: There are too many cooks. I used React two years ago because the API was tiny, simple and elegant. They are adding new API features left and right, and the framework feels very uncoordinated now. The surface area is way bigger than it needs to be. This is my cue to finally explore other frameworks.

I agree with you, but I've also tried other frameworks and there isn't a single one that is all-around better than React. Unless you're willing to migrate to other compile-to-js languages.

Have you tried mithril.js?

Re: Introducing Hooks

#295

Post by cmx66 »

nine_k wrote: post #104
brlewis wrote: post #96

Earlier quoted context omitted.

> Even mithril.js isn't completely dead. That's a rather un-generous description of a framework under active development with an active community.

A lot of code is 1-2 years old. Though I'm happy that mitrhil.js lives and is being developed (not just maintained). I only wish it wider adoption. The "not completely dead" was meant to be somehow tongue-in-cheek.

v2.0 is coming. Breaking changes are minor stuff. Migration of my very large app took me about an hour. The API of mithril is pretty much settled, which IMO is a good thing. We even plan to remove stuff for next major. Simplicity is key.

Re: Introducing Hooks

#296

Post by christopherscot »

rimunroe wrote: post #284
badestrand wrote: post #226

Earlier quoted context omitted.

The problem is that the hooks seem to be much more restricting than setState. You can `if (condition) this.setState({x: 1})` but you can not with hooks because React keeps track and doesn't allow you to break out of a very narrow usage. Look at the rules from the docs: > Only call Hooks at the top level. Don’t call Hooks inside loops, conditions, or nested functions. > Only call Hooks from React function components.…

I think it's best to treat the various hooks the same as method definitions: you wouldn't conditionally define componentDidUpdate or componentWillUnmount in a class component. Instead, you would conditionally do something within those (always-present) functions. The same applies for these hooks.

I had this thought as well. Ironic isn’t it, given that the main reason for hooks is that “classes are hard”.

Re: Introducing Hooks

#297

Post by christopherscot »

sadturnip wrote: post #27

> 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…

In my experience classes are one of the few boring, easily understood parts of react for almost everyone I mentor/work with.

Re: Introducing Hooks

#298

Post by cmx66 »

vinceguidry wrote: post #6
ggregoire wrote: post #4

While 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…

At the end of the day, the framework that allows people to get more done with less thought is going to win the most mindshare.

That is unfortunately not true. The framework with the best marketing will win.

That's why frameworks like angular and react are so popular. Both are designed to work well in large teams that work on huge codebases. Most of us probably would came along with much much simpler solutions.

Re: Introducing Hooks

#299

Post by tracker1 »

jf- wrote: post #290
tracker1 wrote: post #281

Earlier quoted context omitted.

At this point not really... it's been over a year since I've had to really worry about it. It was better using angular-redux or ngrx, but still was a weird experience. When you have eventing issues with RXJS, or handling integration with other libraries, it's definitely not as broad or mature as the React space is. Anything from chartjs to color pickers, I'm trying to recall the last big issue I had in an angular app…

Funny you should mention drag drop, it’s now built in as of version 7, just released a few days ago. Look up the CDK for more details. Whenever I’ve needed drag and drop functionality in the past I’ve found it in existing UI components. A fairly comprehensive one is primeng. I’ve also added an angular colour picker and highcharts without very much trouble. Often when I hear people complain about angular, I wonder if…

I feel the opposite... I feel like React, by comparison, and JSX are much like the huge lego sets you used to be able to get generically... being able to plug in whatever I want. Angular feels like being stuck with a Duplo version of MindWorks.

As to JSX, it's something close to what I wanted a long time ago... when E4X was added to Mozilla's browsers, along with support for it with Flash/ActionScript3 and XML literal support in VB.Net (not that I love that language) ... interactivity to the UI was SO much simpler. The shame is it was never really supported in other browsers, which left it dead on the vine.

When JSX came out, it's REALLY close to what I already wanted, and in most cases better. In the end, I can compose a React/JSX component starting with a static render function in a file by itself... I can grow it and turn it into a class or wrap it in higher order components. Compose with extensions like react-redux, material-ui, react-jss with ease. Every single time I write an Angular component, I'm looking up configuration arguments for @directives. It's just painfully restrictive by comparison.

Simplest react component

    // HelloComponent.js
    import React from 'react';
    export default ({name}) => Hello {name}!


    // StatefulComponent.js
    import Hello from './HelloComponent.js';
    ...
       return
That's off the top of my head... that's just the code you have to write... Now, do the same thing in Angular off the top of your head, I'm willing to bet it's a LOT more verbose, ugly and hard to remember/modify what you need.

Re: Introducing Hooks

#300

Post by tracker1 »

AlexCoventry wrote: post #222
tracker1 wrote: post #194

Earlier quoted context omitted.

There are other ways to approach an issue beyond shoving everything into a class. I'm not sure I really like the new hooks over the state methods at that level since I tend to separate global state (redux) vs component state (class) vs component state rendering (functional component). In the end it depends on your style. I think this might be useful in a way that can be more pure than some other methods might be.

I don't know what you mean by pure. There is nothing reverentially transparent about the new API. (Nor can there be, really.)

And nothing that requires you to use the new API.
Post reply on HN