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

React v16.3.0: New lifecycles and context API

reactjs.org

Post reply on HN
Print view View original

81–90 of 133 posts

Re: React v16.3.0: New lifecycles and context API

#81

Post by hungerstrike »

zackify wrote: post #20
eric_b wrote: post #10

I like that they are taking the deprecation of the lifecycle methods slowly. And the automated script to migrate to the 'UNSAFE' version of those methods in 17 is a nice touch. I don't know if I love the new context API, but it's great they're giving an official option. Of the big JS frameworks that are popular at the moment, I think the React team is doing the best job of balancing new features with minimizing devel…

“higher order components should be the exception, not the rule.” This just isn’t true. Abstracting form logic. Request logic. Anything else you use across your app. Connect in redux. There are hundreds of good reasons to have a higher order component. It makes testing easy. Test your request logic in one place, anything that uses it is now a stateless component, and testing it is trivial.

No, they should still be the exception for the reasons already stated but also because defining all logic in a “render” function means it’s tightly coupled to your view logic, which you do not want.

Request logic doesn’t belong in a render function. Routing definitions don’t belong in a render function and neither does abstract form logic.

Re: React v16.3.0: New lifecycles and context API

#82

Post by BigJono »

brlewis wrote: post #68

Can someone point me to reasonably simple but not contrived examples that put createContext and forwardRef to good use? As I look at this from a Mithril perspective the value isn't obvious.

Context is a way to pass state down the component tree without it having to go through intermediate nodes.

Say context doesn't exist, and you have a branch of components A -> B -> C, if C depends on some state in A, B would have to have a dependency on that state too. And you'd need some boilerplate code in B that reads the props from A, and passes them to C.

If you want to use C in a different context, say A -> D -> C, then that boilerplate code needs to exist in D as well.

With larger apps, containing large component trees, the amount of this boilerplate prop-passing you need to do starts to get excessive. It's not uncommon to see components read 14 props from their parent, use one of them, and pass 13 to their child(ren).

Until now, this problem has been solved by using data stores that inject state anywhere in the tree that they please. Context is an alternative to that.

It's always existed, just now it has a new API. I have no idea what was wrong with the old one. Nobody seems to have properly explained it anywhere, the docs just make condescending suggestions not to use it without reasoning. I think I saw an arcane tweet once explaining that certain things may not have re-rendered properly when using the old API or something...

Re: React v16.3.0: New lifecycles and context API

#83

Post by akrumel »

danabramov wrote: post #74
akrumel wrote: post #73

Earlier quoted context omitted.

Component count is around 140. Fwiw, some are stateless, functional components while others are more complex. A form of master/detail is driving the need to detect prop changes to fetch additional data while freeing previous data. Consider the master/detail of multiple levels deep driven by route parameters through the ui hierarchy. In RN, this is less of an issue since screens tend to be more focused and ui stack dr…

Fair enough. As mentioned in Update on Async Rendering blog post, there’s a less verbose data fetching API coming down the line (“suspense”). Not quite ready for the release yet. But it will require components to be async-compatible which is why we're getting these lifecycle changes out now.

Intriguing. Been too busy cranking on a new product to stay up on the latest changes so thanks for the pointer. I have lots of reading to do.

And thanks for listening about my use case. One concern about using a static function for getDerivedStateFromProps() is that it will not allow for taking instance variables into account. Have not thought through how that might come into play but components certainly allow for this, though many may feel it a strange idea. Perhaps a reference to the component could be passed as well as an additional argument.

I look forward to coming up for air and catching up with the improved approach. Things continue to move quickly and I continue to be impressed at how the changes bring improvement to the ecosystem.

Re: React v16.3.0: New lifecycles and context API

#84

Post by hashbig »

navls wrote: post #38
hoodoof wrote: post #26

Earlier quoted context omitted.

There is no demise coming for Facebook. They'll clean up, grandma, aunty and the school mothers will continue posting and they never even knew there was an issue. People will soon forget.

> Will MySpace ever lose its monopoly? [2007] https://www.theguardian.com/technology/2007/feb/08/business....

People that keep comparing FB to Myspace simply don't understand scale.

Having 2 billion users is not a 1000x better than having 2 million ones. It's more like a million times. The network effect compounds non-linearly.

Facebook (the company) is here to stay. Even if the product is gone, they own 2 other multibillion dollar social networks: Instagram and WhatsApp.

Re: React v16.3.0: New lifecycles and context API

#85

Post by girvo »

danabramov wrote: post #71
steve_taylor wrote: post #67

These lifecycle changes make me nervous. We’re losing some important escape hatches to make way for async rendering which solves a problem that very few web apps have. To use an analogy, it’s like “unsafe” features being deprecated in C to make way for the next major release which will be more like Java. My first impression of this is that it’s the beginning of the end for React. People can still use old versions, bu…

>async rendering which solves a problem that very few web apps have. From my experience of talking to React developers, data fetching is the most common problem people bump into with React apps. Async rendering is key to making data fetching easy and natural in React, and to providing a great user experience whether the user is on a fast or a slow network. Please watch the second part of my talk for a demo if you’re…

For what it’s worth, I think the async rendering changes/data fetching within components is a lovely idea. But I’m biased and desperately want reducerComponent from ReasonReact in Flow/React...

Re: React v16.3.0: New lifecycles and context API

#86

Post by plexicle »

aioprisan wrote: post #65
adam_sohn wrote: post #63

Earlier quoted context omitted.

Angular 5 is very popular now. Big teams with data intensive administration dashboards are choosing it over React.

I don't buy it. Vue is eating Angular's lunch, with React leading. https://medium.jonasbandi.net/angular-vs-react-popularity-ea...

I don't buy that. I actually see Angular being USED in big corporate environments. I hear from friends about how their team is USING it.

I hear people TALK a lot about Vue. Nothing against it, I enjoyed my little hobby project in it. But way more people talk about using Vue than actually using it. In no way is it "eating Angular's lunch". This is coming from someone quite critical of Angular.

Re: React v16.3.0: New lifecycles and context API

#87

Post by bcherny »

jdpigeon wrote: post #32

I've been thinking about different situations in which Redux could be replaced with the new Context. Id sure appreciate having to write less boilerplate. The biggest concern I always get stuck on is where I'll put all my app's business logic, which I'm so used to putting in async redux-observable or redux-thunk actions. Does anyone have anything ideas on how to make an elegant business-logic-full Provider component?

If you want less boilerplate and type safety, consider Undux - https://github.com/bcherny/undux

Re: React v16.3.0: New lifecycles and context API

#88

Post by GenKali »

BigJono wrote: post #82
brlewis wrote: post #68

Can someone point me to reasonably simple but not contrived examples that put createContext and forwardRef to good use? As I look at this from a Mithril perspective the value isn't obvious.

Context is a way to pass state down the component tree without it having to go through intermediate nodes. Say context doesn't exist, and you have a branch of components A -> B -> C, if C depends on some state in A, B would have to have a dependency on that state too. And you'd need some boilerplate code in B that reads the props from A, and passes them to C. If you want to use C in a different context, say A -> D ->…

AFAIK the problem with the old context is that values in context were not used to determine whether or not the component tree should update. So if a context value in A changed, but no props/local state changed, it would not redraw the tree below it (B -> C). If C's render depended on the context value, it would not be redrawn to reflect the change.

Re: React v16.3.0: New lifecycles and context API

#89

Post by Vinnl »

brianvaughn wrote: post #79
steve_taylor wrote: post #77

Earlier quoted context omitted.

I watched the video and I’ll keep an open mind. I really hope you will hold off deprecation warnings until 17.0.0 instead of 16.x, even if that means you need one more major version than you had planned. Being on a team whose policy is to not shrinkwrap, so that we automatically get patches (not my policy, personally), at some point we’re going to start seeing all these deprecation warnings without having explicitly…

> From the outside, having seen Fiber slated for release in 16.0.0 and, being pushed back to an unknown 16.x release, and then being pushed back to 17.0.0, it seems like you had not anticipated the extent to which the core React API had to be changed to enable the async renderer. "fiber" was the code name for the rewrite that was released as version 16. Async rendering is a feature that we've been working on adding-…

> We're also working on other cool, related efforts- like a compiler (https://twitter.com/trueadm/status/944908776896978946)

That sounds like it could bring a lot of benefits. Would, and if so how, that affect people using TypeScript?

Re: React v16.3.0: New lifecycles and context API

#90

Post by wolco »

brianvaughn wrote: post #30
nkkollaw wrote: post #28

I use and love React, but I'm also a little scared of it. I opened this little app I did 1 year ago in React 15, and it's completely incompatible with what I use now. Every time I read of a new release I get this chill down my spine for a second.

Our upgrade process is very gradual. As long as you've fixed all of the dev warnings for the last minor release of a given version, you should be able to upgrade to the next major without any problem.

For someone who hasn't opened the app in three years going through the upgrading process for each major version/minor high version would be more difficult vs rewriting for most smaller components.

To the parent's parent's point Javascript has evolved since 2015 and comparing what a 2015 app looks like to a 2018 app is day and night.

Post reply on HN