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

What I wish I knew about React

bitsofco.de

Post reply on HN
Print view View original

101–110 of 301 posts

Re: What I wish I knew about React

#101

Post by 7777fps »

efdee wrote: post #66
7777fps wrote: post #54

Earlier quoted context omitted.

I liked that model because as an ASP webforms developer the class lifecycle is easy to reason about, like a page lifecycle. In ASP you wouldn't put initialisation code in the page constructor either, it would go in Page_Init, Page_Load, etc. Of course the tooling there made it both easier to put in the right place and harder to edit the page constructor to stick it in the wrong place.

I remember ASP.NET Webforms, and the reason most of the community moved towards MVC-ish frameworks is exactly that most of the time, you ended up shoehorning functionality into different lifecycle methods, which made them much harder to reason about. Most of the time, for anything more complex than just performing the initial databinding, you'd just be looking at the lifecycle chart and trying to figure out which pla…

Don't worry, I'm not espousing lifecycles as a panacea or solution for the modern programmer, I just wanted to share that experience with lifecycle methods meant that I was less tripped up by the pitfalls of react lifecycles.

Less so than I've been tripped up by react hooks certainly so it's been a surprise that many here are describing them as being much easier and simpler than classes.

Classes had limits and some pitfalls but it's been frustrating that lifecycle methods have been retired and deprecated because sometimes they felt like the natural place to do something.

Re: What I wish I knew about React

#102

Post by kreetx »

ggregoire wrote: post #95
dvcrn wrote: post #83

I am not so up to date with frontend dev but what's with the hate towards React these days? It still does what it's supposed to do very well and very fast. Yeah sure if you want JSX you need transpilation but I would want that anyway if I want any of the ES6 features without losing browser compatibility. And it's also constantly evolving and getting better. Just recently I started a React project with class component…

> I am not so up to date with frontend dev but what's with the hate towards React these days? HN is rarely the place to read constructive comments about JavaScript and frontend development. Personally I've been developing web apps for 10 years (with technologies such as Spring, ASP.NET, CakePHP, Symfony, Django, jQuery, Backbone.js, Angular 1) and I quite enjoy React. I think it makes my job easier and I feel product…

What's a good place for front-end dev discussions, especially the type which are more on the meta-level?

Re: What I wish I knew about React

#103

Post by runawaybottle »

dvcrn wrote: post #83

I am not so up to date with frontend dev but what's with the hate towards React these days? It still does what it's supposed to do very well and very fast. Yeah sure if you want JSX you need transpilation but I would want that anyway if I want any of the ES6 features without losing browser compatibility. And it's also constantly evolving and getting better. Just recently I started a React project with class component…

A whole lot of people use it at work and witnessed valid criticisms. It’s not like we’re going to have the knives out when React/Angular is new.

Give it a little time, see a few codebases, extend and build a few apps, then come back. Now people have some credible stuff to say. We can’t comment much about how great Hooks are after reading a few Medium posts. I’ll see in a few months when it’s all over the codebase.

HN will be full of ‘we rebuilt our api in GraphQl and boy things are a mess’ in 2 years.

Re: What I wish I knew about React

#104

Post by andrewstuart »

I love React. In fact I recently gave plain vanilla JavaScript a go and it was so painful that I was glad to get back to React's way of organising a large application.

I don't use Redux or server side rendering - they're not needed.

The only thing that I think it should do differently is leave styles to be handled natively.

Re: What I wish I knew about React

#105

Post by dragonwriter »

dvt wrote: post #44
osdiab wrote: post #30

Earlier quoted context omitted.

I personally find “the HTML is a function of its inputs, internal state, and nothing else” to be a much more predictable model for writing large web applications than, “anybody anywhere in your code can pull the rug from under you arbitrarily with jQuery”, and for that alone I prefer the React development experience. With Hooks I’m happy in that most of the “business logicky” stuff can be split out into those and my…

> I personally find “the HTML is a function of its inputs, internal state, and nothing else” to be a much more predictable model for writing large web applications than, “anybody anywhere in your code can pull the rug from under you arbitrarily with jQuery”, and for that alone I prefer the React development experience. Respectfully, that's not at all what HTML is supposed to be, but even so, as it turns out, sometime…

> So people started just passing state as props everywhere, but oh no that's an anti-pattern

It's not an anti-pattern because of some abstract aesthetics, it's a pragmatic management nightmare in practice.

> So now people are using redux, mobx, or the context API to do essentially the exact same thing.

Not to do the same thing, but to improve management of it.

> Three new tools were developed by dozens of engineers to basically re-invent "global state." It's ludicrous.

Why is it ludicrous that engineering effort goes into solving pragmatic problems with how things that have always been possible are done?

Re: What I wish I knew about React

#106

Post by batiste »

awestroke wrote: post #5
prodave wrote: post #2

Aren’t hooks more confusing than the class components? In a class, you write your initialization code in the constructor - no infinite loop if you fetch something. And anyone who has used classes in Java or other languages would feel at home.

No, you use componentDidMount etc, spreading out the logic that could go into a single hook into multiple lifecycle methods, spaghettied with other logic. Hooks are much cleaner.

Would it be possible to have a single method on a class that behaves like whatever useEffect is doing?

Re: What I wish I knew about React

#107

Post by [deleted] »

kreetx wrote: post #102
ggregoire wrote: post #95

Earlier quoted context omitted.

> I am not so up to date with frontend dev but what's with the hate towards React these days? HN is rarely the place to read constructive comments about JavaScript and frontend development. Personally I've been developing web apps for 10 years (with technologies such as Spring, ASP.NET, CakePHP, Symfony, Django, jQuery, Backbone.js, Angular 1) and I quite enjoy React. I think it makes my job easier and I feel product…

What's a good place for front-end dev discussions, especially the type which are more on the meta-level?

[deleted]

Re: What I wish I knew about React

#108

Post by ddek »

7777fps wrote: post #68
andrewstuart wrote: post #32

Earlier quoted context omitted.

This is a critical point to understand. If you're not doing declarative programming with React then you're swimming upstream. Problem is that the concept of declarative programming would be very difficult to get beginners to grasp. Once you grasp it though, it's absolutely incredibly powerful and importantly - simple. And this is where React loses beginners who jump to more intuitive programming models.

But that's great until it isn't. You can design all the declarative things you want, but someone will eventually come up with a requirement that doesn't appear to fit a declarative structure, such as an event that fires 2 seconds after something else happens. And so to resolve that you can construct state machines with transition states to get back to a declarative model, but those state machines can quickly become a…

I can call ‘setTimeout’ from the component?

I honestly don’t see the issue with your example.

I’d use an event handler to work out when something happened. This would set the timeout, and the handle would be stored as a ref. I’d have a use effect hook to clean up the timer, so when the component is unmounted the timeout is cleared.

What’s the issue here?

Re: What I wish I knew about React

#109

Post by marcus_holmes »

capableweb wrote: post #58
genezeta wrote: post #12

React have sold very well the "it's a library" mantra. I find this, at least, bends the difference to build a marketing point around it. The point they make, and the one everyone writing about React simply repeats, is that "it doesn't give you everything" so you can use it with any other library/framework without trouble. While this claim may be indeed correct, it doesn't mean it's a library. React is a UI framework…

I've always found the best distinction between a framework and the library lies in who-calls-who? A library you call when you're ready to use it. With React, that's calling `ReactDOM.render()` when you want to render your application. A framework you just provide code blocks and let the framework call your code, rather than your code calling the libraries/frameworks code. So with that in mind, you can use React as bo…

Excellent description. I'm going to borrow this when talking to new gophers about the difference in attitude between Go and $other_language_that_emphasises_frameworks.

Re: What I wish I knew about React

#110

Post by baddox »

grey-area wrote: post #89
baddox wrote: post #55

Earlier quoted context omitted.

None require React specifically, of course. I’m only referring to the dichotomy between server-rendered apps and apps with significant client-side interactivity.

I sincerely think that dichotomy is not a useful one - that's not a choice you have to make. You can have server-rendered apps with significant interactivity (where it makes sense). Many large websites still use server side rendering (in whatever language they want), and js to refresh data client-side as required and respond to user actions, pulling data from the server side. There is no need to attempt to move every…

I should be more clear. I mean the dichotomy between a web site that is only rendered on the server (which is not more difficult to build now than it was 10 years ago), and web sites that have significant client-side interactivity (which are usually and understandably more difficult to build than the former).

Of course, there are different versions of the latter: you can have an entirely client-rendered site, or a site that runs largely the same client-side code on the server for initial HTML renders (like React SSR), or a site that renders HTML from the server and then has separate client-side code to enhance interactivity, or any number of combinations of these and other approaches.

Post reply on HN