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

101–110 of 133 posts

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

#101

Post by danabramov »

nkkollaw wrote: post #97
brianvaughn wrote: post #30

Earlier quoted context omitted.

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.

The problem is when--like in my case--people develop a project for a client and then go on with their lives, until the client notices a bug, or wants to implement a new feature months after. I tried to explain the client that I needed to upgrade the code before even being able to understand what the problem was, and I lost the client. As much as they suck, PHP apps from 10 years ago are still working great, and so ar…

Could you clarify how React is different from jQuery in that sense? Not sure I’m following.

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

#102

Post by brlewis »

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

Thanks, that seems like a good explanation.

I still think I'll need examples to be convinced of the usefulness, though. I don't see why a large component tree would have 14 disparate props passed down individually. If the tree is supposed to be a reusable component, why not define a single object to pass down?

Edit: Having read the docs I now see that my current perspective on it is the one they want me to have. "Don’t use context just to avoid passing props a few levels down. Stick to cases where the same data needs to accessed in many components at multiple levels." So it's better for me to avoid it until I see it's definitely needed.

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

#103

Post by CuriouslyC »

brianvaughn wrote: post #24
CuriouslyC wrote: post #22

I have very mixed feelings about the new context api. On one hand, you're taking a foot-gun away, which I approve of having worked on code bases that abused it. On the other hand, it's very clunky, and I think people who abused the old context will just start making components larger, and wrapping them in a single context, rather than doing the right thing with many small components individually wrapped. Personally I…

Would you elaborate on what you find clunky about the new context API? :)

Well, I tend to make a lot of very small stateless components. If a component is 1-6 JSX tags, the new context API represents a boilerplate overhead of between 100 and ~17%. Additionally, the semantics of having a consumer's props.children be an immediately invoked function are a little bit unintuitive to me. I think having multiple ways to pass "props" increases the api surface area, having everything "just be props" would be simpler.

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

#104

Post by CuriouslyC »

danabramov wrote: post #33
CuriouslyC wrote: post #22

I have very mixed feelings about the new context api. On one hand, you're taking a foot-gun away, which I approve of having worked on code bases that abused it. On the other hand, it's very clunky, and I think people who abused the old context will just start making components larger, and wrapping them in a single context, rather than doing the right thing with many small components individually wrapped. Personally I…

What is props inheritance and IsolatedComponent?

If you're familiar with the scope inheritance behavior of angular 1.x, that would basically be a reasonable model (i.e. setProtoTypeOf on props objects down the chain). That would avoid people taking the shortcut of doing {...spreadProps} when they have to pass a lot of properties to many small child components, and let you distinguish locally passed props vs inherited props during debugging.

IsolatedComponents wouldn't inherit props from their parents. The idea of an IsolatedComponent would be to present a boundary on inherited props. That would give you the simplicity of the old context api, but with more fine-grained control over how it is propagated (hopefully leading to fewer foot gun moments).

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

#105

Post by joshribakoff »

bsimpson wrote: post #21
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…

Using refs to talk to the DOM is a leaky abstraction, but talking the the DOM is a necessity in a framework that renders to the DOM. Before forwardRef, you'd end up with ad-hoc prop names like `domRef` to try to wallpaper around the leak. I'm happy to see a thoughtful solution. There are some things you just can't do with React alone (like listen for PointerEvents).

You can handle pointer events with synthetic events (onMouseMove and such) unless I am misunderstanding

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

#106

Post by Androider »

danabramov wrote: post #48
myth_drannon wrote: post #43

Does anyone finds the new getDerivedStateFromProps adds too much boilerplate code for the developer to write and be aware? So for every previous prop that I need to compare with I need to remember to update it in the state? If before it was as simple as this.props.X!==nextProps.X now I need to set the state with the current prop!

This lifecycle exists for a fairly rare use case. Why do you use it often? Instead of keeping state “in sync” with the props, can you just read it from the props? For the rare cases where you do want to retain previous props, yes, we’re asking you to be explicit about it. This will allow better memory usage in future versions of React, and also avoids the need for an extra `prevProps !== null` check that would need t…

I have 27 componentWillReceiveProps across 286 components, so not a whole lot. But in almost none of those do I update the component state, the most common thing is to compare the previous and new props and dispatch some Redux action that will start a load of some data, which will eventually update the props (of multiple components) via Redux. I guess I should start using componentDidUpdate instead?

The other case of componentWillReceiveProps usage I see is where there is computationally expensive derived state, but for some reason the asynchronous nature of setState prevented it from being used, and an instance variable "had" to be used instead. There are a few cases of these where after much hair pulling the instance variable "fixed" the issue.

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

#107

Post by acemarke »

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

Two major issues with the old context API:

- It was a single shared key/value namespace, which could potentially lead to different libraries attempting to put values at the same key and stomping on each other

- It was fine for passing down _initial_ values, but if you tried to _update_ a value, any components that returned `false` from `shouldComponentUpdate` would block their descendants from receiving the updated context values

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

#108

Post by brianvaughn »

Vinnl wrote: post #89
brianvaughn wrote: post #79

Earlier quoted context omitted.

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

I don't think we know enough about where compilation will end up to comment much. I wouldn't expect TypeScript to be negatively affected though (since it compiles to JavaScript). So far, the problems we're noticing are from certain coding patterns or practices within components. However we deal with these (whether we add new lifecycles or encourage alternate patterns, etc) it should hopefully apply equally to JS/Flow/TypeScript.

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

#109

Post by brianvaughn »

dereke wrote: post #98

I was hoping they were going to simplify the lifecyles but it looks like they are adding more. Since I switched to hyperdom[0] I haven't missed lifecycles at all. In fact my app has practically none of the "plumbing" code that my old react apps seemed to have. Hyperdom is so much simpler but seems to be just as powerful. [0] http://github.com/featurist/hyperdom/

Lifecycles aren't mandatory in React. Pure functional components don't use them. Stateful class components don't necessarily need them either (although they _can_ be useful, particularly when interfacing with imperative APIs like the DOM).

I've never used Hyperdom, so this isn't meant as a criticism or commentary on it.

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

#110

Post by brianvaughn »

Androider wrote: post #106
danabramov wrote: post #48

Earlier quoted context omitted.

This lifecycle exists for a fairly rare use case. Why do you use it often? Instead of keeping state “in sync” with the props, can you just read it from the props? For the rare cases where you do want to retain previous props, yes, we’re asking you to be explicit about it. This will allow better memory usage in future versions of React, and also avoids the need for an extra `prevProps !== null` check that would need t…

I have 27 componentWillReceiveProps across 286 components, so not a whole lot. But in almost none of those do I update the component state, the most common thing is to compare the previous and new props and dispatch some Redux action that will start a load of some data, which will eventually update the props (of multiple components) via Redux. I guess I should start using componentDidUpdate instead? The other case of…

> I guess I should start using componentDidUpdate instead?

Sounds like it, based on your description!

> The other case of componentWillReceiveProps usage I see is where there is computationally expensive derived state, but for some reason the asynchronous nature of setState prevented it from being used, and an instance variable "had" to be used instead.

`setState` calls made from within `componentWillReceiveProps` are processed (synchronously) before `componentWillUpdate` or `render` are called.

Post reply on HN