5 ms·

>I hate it when library authors blame users (consuming developers in this case) for their blunders. I’m sorry the post came across this way. We didn’t intend t

>I hate it when library authors blame users (consuming developers in this case) for their blunders. I’m sorry the post came across this way. We didn’t intend to blame the users. The component API was virtually unchanged for five years, and when it was originally designed, we didn’t anticipate how it would be used, so the hooks were pretty low level and matched how React worked internally. These days we have a better idea of where we want to take React (I hope that my talk[1] may inspire you even though you already formed a negative opinion). The work we're doing now is just to fix the mistakes we made in the past with a gradual migration path. >no wonder we're ending up with gobbledygook like "getSnapshotBeforeUpdate(...)." I totally see what you mean but this particular lifecycle is for a very rare use case. If you have better suggestions for naming it please let us know—we have an open RFC process and you are welcome to participate there.[2] We didn’t separate it on a whim—it is essential to have a pure lifecycle like this to implement some use cases (like autoscrolling to new data) with asynchronous rendering[1]. >I ended up populating data via componentWillMount on the back-end. Terrible solution, but hey, it's the only one React has You're right—but this solution doesn't solve async data fetching. It only works when the data is synchronously available, and per the post, in that case you can already use the constructor.[3] >This will not work on the server-side because technically components never mount when doing SSR. I think you might have missed this part of the post: >In the longer term, the canonical way to fetch data in React components will likely be based on the “suspense” API introduced at JSConf Iceland. Both simple data fetching solutions and libraries like Apollo and Relay will be able to use it under the hood. It is significantly less verbose than either of the above solutions, but will not be finalized in time for the 16.3 release. The mentioned “suspense” API is both much less verbose and actually was designed with server rendering in mind. It would let us fetch data on the server and on the client and suspend rendering until the data is ready (and show a placeholder if it takes too long). The lifecycle changes in these blog posts are exactly the kind of work we need to do to make APIs like Suspense possible. Again, I encourage you to watch my talk[1], the second half of which demonstrates this API. I hope this clarifies our position a bit, and I’m sorry if it seemed like we don’t care about our users. It took us about a month to write this blog post, and we know it still doesn’t address all use cases. We’ll take your feedback in mind next time we amend it. Thanks! [1]: https://reactjs.org/blog/2018/03/01/sneak-peek-beyond-react-16.html https://reactjs.org/blog/2018/03/01/sneak-peek-beyond-react-... [2]: https://github.com/reactjs/rfcs/pull/33 https://github.com/reactjs/rfcs/pull/33 [3]: https://reactjs.org/blog/2018/03/27/update-on-async-rendering.html#initializing-state https://reactjs.org/blog/2018/03/27/update-on-async-renderin...

dvt 9y ago
My apologies if I came off harsh, I have a love-hate relationship with React. > I totally see what you mean but this particular lifecycle is for a very rare use case. It's not that rare. Consider a route change where some state needs to be preserved or, like the article mentions, a scroll position change (or reset!). > You're right—but this solution doesn't solve async data fetching. It only works when the data is synchronously available, and per the post, in that case you can already use the constructor.[3] I just want to point out how fundamentally flawed this is. The constructor is meant to initialize internal and initial state of objects. Making a data/network request in the constructor is beyond bizarre. In fact, the general consensus was that doing that sort of thing in the constructor is kind of an antipattern[1]. > The mentioned “suspense” API is both much less verbose and actually was designed with server rendering in mind. It would let us fetch data on the server and on the client and suspend rendering until the data is ready (and show a placeholder if it takes too long). I'll have to check out suspense, but I feel that it's yet another API that reinvents the wheel. We'll see. [1] https://discuss.reactjs.org/t/constructor-vs-componentwillmount-vs-componentdidmount/4287/10 https://discuss.reactjs.org/t/constructor-vs-componentwillmo...
- AWebOfBrown 9y ago
  > I just want to point out how fundamentally flawed this is. The constructor is meant to initialize internal and initial state of objects. Making a data/network request in the constructor is beyond bizarre. In fact, the general consensus was that doing that sort of thing in the constructor is kind of an antipattern. Note that he said synchronous data fetching, ie a local cache. If you are querying a local cache, this enables you to grab data before the first render (saving a re-render) which is more obviously beneficial on low-power, slow-to-render devices. It CAN also be used to initiate a network request, but this is discouraged because it can fire multiple times: meaning you should only do this if the endpoint is idempotent and you can live with excess requests. It may also complicate testing. Bit OT, but I generally think "that's an anti-pattern" criticism isn't a great contribution unless you're specifying what the problem is.
  - dvt 9y ago

dvt 9y ago

My apologies if I came off harsh, I have a love-hate relationship with React. > I totally see what you mean but this particular lifecycle is for a very rare use case. It's not that rare. Consider a route change where some state needs to be preserved or, like the article mentions, a scroll position change (or reset!). > You're right—but this solution doesn't solve async data fetching. It only works when the data is synchronously available, and per the post, in that case you can already use the constructor.[3] I just want to point out how fundamentally flawed this is. The constructor is meant to initialize internal and initial state of objects. Making a data/network request in the constructor is beyond bizarre. In fact, the general consensus was that doing that sort of thing in the constructor is kind of an antipattern[1]. > The mentioned “suspense” API is both much less verbose and actually was designed with server rendering in mind. It would let us fetch data on the server and on the client and suspend rendering until the data is ready (and show a placeholder if it takes too long). I'll have to check out suspense, but I feel that it's yet another API that reinvents the wheel. We'll see. [1] https://discuss.reactjs.org/t/constructor-vs-componentwillmount-vs-componentdidmount/4287/10 https://discuss.reactjs.org/t/constructor-vs-componentwillmo...

AWebOfBrown 9y ago
> I just want to point out how fundamentally flawed this is. The constructor is meant to initialize internal and initial state of objects. Making a data/network request in the constructor is beyond bizarre. In fact, the general consensus was that doing that sort of thing in the constructor is kind of an antipattern. Note that he said synchronous data fetching, ie a local cache. If you are querying a local cache, this enables you to grab data before the first render (saving a re-render) which is more obviously beneficial on low-power, slow-to-render devices. It CAN also be used to initiate a network request, but this is discouraged because it can fire multiple times: meaning you should only do this if the endpoint is idempotent and you can live with excess requests. It may also complicate testing. Bit OT, but I generally think "that's an anti-pattern" criticism isn't a great contribution unless you're specifying what the problem is.
- dvt 9y ago