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

111–120 of 133 posts

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

#111

Post by brianvaughn »

brlewis wrote: post #102
BigJono wrote: post #82

Earlier quoted context omitted.

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…

I'm curious why the theme example I mentioned in my earlier comment- (and showed in the docs)- doesn't qualify as "useful" to you. Another example would be using context to share the selected language/locale between all of the localized components in an application.

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

#112

Post by brianvaughn »

CuriouslyC wrote: post #103
brianvaughn wrote: post #24

Earlier quoted context omitted.

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…

> 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%.

Not if you use a HOC (e.g. `withContext(Component)`) like a couple of the docs examples showed.

> Additionally, the semantics of having a consumer's props.children be an immediately invoked function are a little bit unintuitive to me.

That's fair! I would encourage you to give it a chance though. I think it's a pattern that really grows on you after a short time. :)

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

#113

Post by Vinnl »

brianvaughn wrote: post #108
Vinnl wrote: post #89

Earlier quoted context omitted.

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

Obviously, but thanks for the tentative impact estimates :)

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

#114

Post by brianvaughn »

wolco wrote: post #90
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.

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.

Upgrading any project after 3 years of inactivity would be difficult, regardless of framework.

I did not mean to imply that you would need to step through every minor version though. I was just saying that- if you were using e.g. 15, update to the latest 15 release (15.6.2) and fixing warnings in it before updating to 16.

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

#115

Post by brianvaughn »

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…

I'm not sure why you would need to upgrade your app in that case. Is the problem that our documentation only reflects the latest release?

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

#116

Post by djhartman »

danabramov wrote: post #70
WhitneyLand wrote: post #66

Earlier quoted context omitted.

Developer learning curve: The context name is a good choice I think. Context API sounds much more elegant than global variables API. While that’s a little tongue in cheek, the lifecycle method names I would rate as a drastic drop in intuitiveness: Previous: componentWillMount componentWillReceiveProps componentWillUpdate New: getDerivedStateFromProps getSnapshotBeforeUpdate

This is intentional because those are relatively rare use cases. We want them to stand out and be quite specific about what they're doing. You still have `componentDidMount`, `componentDidUpdate`, and `componentWillUnmount` that should be used more commonly and do exactly what you expect them to.

In your experience, what are the kind of things that people do in `componentWillMount` that they shouldn't be doing? Is it correct to say that `getSnapshotBeforeUpdate` is named to indicate what you were supposed to use `componentWillMount` for?

Thanks to you and brianvaughn for answering so many questions.

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

#117

Post by bsimpson »

joshribakoff wrote: post #105
bsimpson wrote: post #21

Earlier quoted context omitted.

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

I mean PointerEvent, not MouseEvent:

https://developer.mozilla.org/en-US/docs/Web/API/PointerEven...

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

#118

Post by brianvaughn »

djhartman wrote: post #116
danabramov wrote: post #70

Earlier quoted context omitted.

This is intentional because those are relatively rare use cases. We want them to stand out and be quite specific about what they're doing. You still have `componentDidMount`, `componentDidUpdate`, and `componentWillUnmount` that should be used more commonly and do exactly what you expect them to.

In your experience, what are the kind of things that people do in `componentWillMount` that they shouldn't be doing? Is it correct to say that `getSnapshotBeforeUpdate` is named to indicate what you were supposed to use `componentWillMount` for? Thanks to you and brianvaughn for answering so many questions.

> In your experience, what are the kind of things that people do in `componentWillMount` that they shouldn't be doing?

The biggest one is probably adding event listeners or setting up subscriptions (which can cause memory leaks).

Here are some others: https://github.com/reactjs/rfcs/blob/master/text/0006-static...

> Is it correct to say that `getSnapshotBeforeUpdate` is named to indicate what you were supposed to use `componentWillMount` for?

No. `getSnapshotBeforeUpdate` is not really related to `componentWillMount`. It relates more to what people were using `componentWillUpdate` for.

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

#119

Post by brlewis »

brianvaughn wrote: post #111
brlewis wrote: post #102

Earlier quoted context omitted.

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…

I'm curious why the theme example I mentioned in my earlier comment- (and showed in the docs)- doesn't qualify as "useful" to you. Another example would be using context to share the selected language/locale between all of the localized components in an application.

In self-contained apps couldn't a single prop be passed down that's an object with all things like that in it? Maybe there's a scenario with 3rd-party components where context could make it look more elegant, but I don't have a clear picture.

I know there are several ways to construct a component, but I like that your examples make them functions of props, because that's how I picture a component. Having its behavior depend on a semi-hidden context appears less purely functional. To stretch the term a little, the component is no longer idempotent. Maybe there's a situation where that's what you want, but the examples you've given so far sound like ones where props would serve just fine.

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

#120

Post by brianvaughn »

brlewis wrote: post #119
brianvaughn wrote: post #111

Earlier quoted context omitted.

I'm curious why the theme example I mentioned in my earlier comment- (and showed in the docs)- doesn't qualify as "useful" to you. Another example would be using context to share the selected language/locale between all of the localized components in an application.

In self-contained apps couldn't a single prop be passed down that's an object with all things like that in it? Maybe there's a scenario with 3rd-party components where context could make it look more elegant, but I don't have a clear picture. I know there are several ways to construct a component, but I like that your examples make them functions of props, because that's how I picture a component. Having its behavior…

Yes, but then that prop would need to be passed down explicitly through every component. This would require a _lot_ of boilerplate.
Post reply on HN