Earlier quoted context omitted.
Personally, I find the word "derived" to be a somewhat unfortunate choice
Why is that?
Doesn't feel like it's needed. "getStateFromProps" would have been fine. I think any state "derivation" from props is implied.
React v16.3.0: New lifecycles and context API
91–100 of 133 posts
Re: React v16.3.0: New lifecycles and context API
#92[deleted]
Re: React v16.3.0: New lifecycles and context API
#93Earlier quoted context omitted.
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 t…
Lack of instance is intentional—otherwise we would’ve made it an instance method. Happy to hear about specific patterns you’re aiming for but since getDerivedStateFromProps executes during the “render phase” (interruptible in async mode) we want people to treat it as pure and discourage them from any side effects and mutations. If you really need some instance variable there then perhaps you could move it into state.
Re: React v16.3.0: New lifecycles and context API
#94Earlier quoted context omitted.
Why is that?
Doesn't feel like it's needed. "getStateFromProps" would have been fine. I think any state "derivation" from props is implied.
We intentionally made the naming a little bit obtuse. A name like `getStateFromProps` implies this is a common operation because it sounds so “normal”. And this is, in fact, a common misconception with React beginners who try to copy props into state instead of using props directly or lifting state up. So we wanted the naming to reflect that this pattern is not supposed to be the most common.
Re: React v16.3.0: New lifecycles and context API
#95Earlier quoted context omitted.
>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…
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…
There was never a plan to enable async rendering in React 16. “Fiber” referred to a new internal architecture (which enabled fragments, error boundaries, portals, and now context). It was a prerequisite to exploring async rendering, but it was also important for the above features, and it shipped in React 16.0.
Async rendering indeed needed more research but we’ve been testing it internally for months now, and are getting closer to the point where it’s ready. I disagree with you that replacing a few often misunderstood lifecycle hooks with more concrete alternatives significantly raises the abstraction level.
We did anticipate that some lifecycle methods will be problematic (e.g. https://github.com/facebook/react/issues/7671 was filed over a year ago, or a few months before the first line of Fiber code was written).
We’ve thought about these issues for quite a while. Jordan (creator of React) started thinking about them about four years ago (https://twitter.com/jordwalke/status/500587022890061824).
We needed time to evaluate different possible migration strategies and experiment with them, and we have a good idea now of what they look like. We don’t have all the answers yet but we’re getting there, and are doing that in the open.
Re: React v16.3.0: New lifecycles and context API
#96Earlier quoted context omitted.
>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...
We’re always looking at alternative component APIs and that might be a possible future direction.
Re: React v16.3.0: New lifecycles and context API
#97I 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.
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 are jQuery-based apps from 5 years ago.
Would never go back to either one, though.
Re: React v16.3.0: New lifecycles and context API
#98I 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.
Re: React v16.3.0: New lifecycles and context API
#99Earlier 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…
Why do you need to upgrade the code to fix a bug or implement a new feature? I don't understand that. Keep React version and do what client wants.
Re: React v16.3.0: New lifecycles and context API
#100Can 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.
My understanding is that it is like Angular $scope but without the prototypal inheritance footguns.
Instead, you have islands in the vdom tree that share a single, common state object.