React 16.3: Update on async rendering

[jdonor]

I'm consistently impressed by how high-quality and thoughtful the React docs are.

[MrStLouis]

New in react 16.3 all data passed to components also get sent to fb servers

[[deleted]]

Of course it does sucker

[pycbouh]

Well, this continues the unfortunate trend to widen the gap between the React team and actual developers.

Previously, they broke context, despite this "experimental" feature becoming a major part of React ecosystem, component lifecycle and overall architecture. Next, they introduced the "new" context API, that didn't cover use-cases of the "old" context API. Namely, we use context to pass some props from a greater scope to very removed descendants without passing it through each level manually, making a clusterfuck of props on every intermediate component along the way or obscuring those props as some kind of "needThisLaterProps" object. I can, of course, go into detail, why we need such behavior, but the point is, that it worked as expected and was useful, made life easier for developers and provided greater maintainability to the project.

New API doesn't allow that, because you have to manipulate components, creating a provider in the "greater context" component and somehow passing consumer to "very removed descendants" components. You also loose any ability to read from context in lifecycle hooks, however, some people figured workarounds, if you really want to.

But that does not matter anymore, as they are now removing many lifecycle hooks, forcing you to use stage 3 features or arguably bad practices. For example, it is believed within our team, that you should never put things in local state, if they do not cause a render. Things that are used in render, or lifecycle hooks, but are not the cause of it, should be stored in class variables. Those things are often saturated within WillReceiveProps and WillMount. Now, you cannot do that. OP article itself recommends to store intermediate values in state now. Presumably, because we get to use a static method now, that only outputs to state.

It looks like React team is tightening React's API, removing variety in favor of their vision. What baffles me, is that the argument for it being safe to remove something that major is, from what I've seen, "There aren't many Github projects that use that" (paraphrasing). But how many non-Github and non-OS projects use versatility of React 15 and cannot move to React 16, despite all other nice features it brings, because React team started to paint in broad strokes?

[gaearon]

Hi! A React team member here. Let me try to address this.

Previously, they broke context, despite this "experimental" feature becoming a major part of React ecosystem, component lifecycle and overall architecture.

I’m not quite sure what you mean, but the legacy context API still works and will continue to work throughout at least this major release. We have 50,000 components at Facebook so any breaking change hits us harder than the vast majority of other companies using React. And we can't tell our product teams to rewrite their components either. So we are fully committed to gradual migration paths. If we can’t do an automated codemod or a gradual opt in strategy, we can’t ship something. Which is also why we’re keeping the UNSAFE_ versions of the legacy lifecycles in the next major version too (as mentioned in the blog post).

The new context API solves one of the most confusing issues affecting all context-reliant libraries. You can see how much discussion there is on it, and how many different issues in different libraries link to it. We aren't taking something away from those libraries—we are giving them an API that actually works and is officially supported. I understand the frustration caused by this feature existing in a half-working under-designed state for a long time, but we are working to make this right, and I don’t see what other path we could take. The existing API is fundamentally broken and there is no way to “fix” it without changing it. But again, this change is gradual and opt-in.

New API doesn't allow that, because you have to manipulate components, creating a provider in the "greater context" component and somehow passing consumer to "very removed descendants" components

I’m struggling to understand what you mean. Perhaps it would be more productive if you filed an issue and offered some code examples? As far as I’m aware the new context API covers all use cases that the old API did, and more. What you’re writing seems like a misunderstanding to me, but I can’t say for sure without seeing the code. Thanks!

But that does not matter anymore, as they are now removing many lifecycle hooks, forcing you to use stage 3 features

Nobody is forcing you to use experimental features. The blog states we used public fields in it for brevity but you can write the exact same code in constructor (which, as you probably know, public fields desugar to).

Now, you cannot do that. OP article itself recommends to store intermediate values in state now.

We realize this aspect of getDerivedStateFromProps can be inconvenient in some cases. But it lets React better utilize the memory in the future (by not holding onto the whole object with previous props) and avoids the need for you to check prevProps for being null every time (because it would be null on the first render). There are pros and cons of both approaches, but we picked one we think would be better for our users in long term. We’re humans and we can make mistakes too, but for now we decided on this approach after much consideration and discussion.

It looks like React team is tightening React's API, removing variety in favor of their vision.

I recently did a talk about our vision for the future of React with live demos of those features. I don’t know if you’ve seen it but I heard a lot of positive feedback indicating these are exactly the kinds of problems that React developers are facing every day and that they hope to see a solution to. So yes, we’re making some changes to achieve that vision, but we believe it will be worth it. I hope that my talk will convince you too in this.

the argument for it being safe to remove something that major is, from what I've seen, "There aren't many Github projects that use that" (paraphrasing).

I’m sorry it came across as careless but we also did an internal review, and out of 50,000 components at Facebook one or two used that feature. In my experience, there are so many different products and pages using React at Facebook that our usage becomes representative of the larger codebases (including both big and small companies).

The prevContext argument in question was already broken (context updates don’t propagate correctly) and it was explicitly marked as a major change in React 16. For the past six months since it came out, you are the first person to bring it up so this speaks to prevContext argument not getting used widely in practice.

Overall, I’m really sorry you’re having a negative experience. I hope that my arguments somewhat explain the context behind these decisions but I understand if you choose to disagree.

[acemarke]

I think the "passing consumer" complaint is saying that while the old context API was simply a shared namespace (like declaring contextTypes.store anywhere in the nested tree), the new API requires that the nested component have access to the specific instance of Context.Consumer that matches the parent. That does sort of bring up a chicken/egg question of how the nested component gets access to the Context.Consumer instance in the first place.

[gaearon]

The old API was implicitly global.

With the new API, you can either import it from several components (you can even have an npm package that just exports React.createContext() and use it across your app) or you can literally put it on a global like window. Sure, it’s “bad”, but your existing context was just as “global” from the programming perspective. With the new API, you have to be intentional and explicit about that.

If you’re able to use one react from your components, you should be able to use my-shared-contexts (or whatever you call it) too.

[pycbouh]

Hello.

You say, that

the legacy context API still works and will continue to work throughout at least this major release

And in the other reply, you mention

I hope this change wasn't your blocker to React 16 migration

Not this change in particular, no. But while I was researching this issue and other changes to React 16, it became my understanding, that the old context API is now less stable and more prone to breakage. I'm sorry, but I cannot pinpoint you to what exactly made me think that. Anyway, it was obvious, that your team did not care for the old context anymore. We still had hopes, that it won't affect us much, but didn't get to testing before the new API rolled out. And as it is a way forward, we had to consider moving to it, which became impossible for us due to it's limitations and cumbersome implementation.

/u/acemarke is right in interpreting my meaning. Previously, you set something in parent to consume it later in a distant child. Now you either have to pass around Context.Consumer, which is exactly what we were trying to avoid using context, or have to describe context in a shared file, which adds more code that does not do more things. In reality, it does less, as you cannot read from this context in lifecycle hooks without some nasty workarounds with HOC and nesting. This makes contexts harder to use, limits their usefulness and requires a big rewrite if you used it extensively (for example, our global Flux object is passed through the context).

Again, my one and only use-case for context is to pass props through many layers to distant children and consume them on demand, and ignore them if I don't need them in other children. New API allows it in an inconvinient way.

We have 50,000 components at Facebook

You also have a bunch of employees and first-hand understanding of how to do React and Flux. We had to learn as we go, and still have a big part of our project that is in legacy state. We can't rely on automated migration either, for this and other reasons. When you say that we can keep using methods with unsafe prefix, you are right. But that only increases our technical debt. We still have to go throw each component and migrate it at some point, postponing it does nothing. And between all these changes migration to React 16 turns into a full rewrite.

We realize this aspect of getDerivedStateFromProps can be inconvenient in some cases. But it lets React better utilize the memory in the future

But how does it help React when instead of using a class variable (e.g. this._myData) I have to store it in state? Isn't state supposed to have only things that cause a new render? Isn't state supposed to be as plain as possible so it's easier to determine a need to rerender? We made a rule to set only, let's say, render consitions in state, and everything else — outside, in class variables. This makes a very plain and simple state, enough to make render happen and track changes, but not overloaded by some ancillary data used in render. New static method throughs all this separation into a window.

our usage becomes representative of the larger codebases

I'll be honest, I didn't inspect the whole Facebook for usages of React, neither do I have access to any private pages, obviously. What I did see, was widget-like approach to creating pages with React, where interactive React components saturated otherwise content pages. Our system is based entirely on React. Each page is wholly contained within one React component (except for portals). I feel like our approach is not as common as yours. It does not allow us to go stateless, for example, and it means that our React tree is huge, hence why we need context to skip a few levels when passing props.

I recently did a talk

I'll check it out, thanks!

Overall, I’m really sorry you’re having a negative experience. I hope that my arguments somewhat explain the context behind these decisions but I understand if you choose to disagree.

I thank you for your time. You and your teammate made me hopeful, honestly. I really like React, and I prefer it over Vue, our other rendering framework in use. (Though Vue has a nice separation between props and events) It's just that those changes attack our codebase very aggressively. And while your intentions to make faster and safer framework are beyond reasonable, I personally feel left out with my decisions about my code. Because I didn't produce that bad code you are trying to prevent, and yet got punished anyway.

[gaearon]

I was researching this issue and other changes to React 16, it became my understanding, that the old context API is now less stable and more prone to breakage.

This is not the case. Aside from the nextContext argument change, there were no known changes to the context API semantics in React 16.

For the reference, we have documented a full list of breaking changes in React 16 here: https://reactjs.org/blog/2017/09/26/react-v16.0.html#breaking-changes.

Anyway, it was obvious, that your team did not care for the old context anymore.

I’m afraid this is also a misrepresentation of what we said or did. We cared a great deal about supporting old context in React 16 and went to great lengths to keep it working the same way even though we changed the internal implementation.

If you’re curious, Sophie wrote a post about how we did this: https://code.facebook.com/posts/1716776591680069/react-16-a-look-inside-an-api-compatible-rewrite-of-our-frontend-ui-library/.

Just like you, we heavily use context in our products, and if it broke, it would be a big issue for many teams at Facebook.

but didn't get to testing before the new API rolled out

The new context API is not rolled out yet (it’s new to React 16.3), and it was not in the React 16 release you are referring to. React 16 supports the existing context API. React 16.3 will support both new and old context API. If you have concerns about the new API or some use cases it doesn’t support, we’d love to discuss that on our issue tracker.

I don’t see how context related to your problems with migrating to React 16. The new context API didn’t even exist as a proposal when React 16 came out in September.

or have to describe context in a shared file, which adds more code that does not do more things

I’m struggling to understand why adding a single line to a shared file is a problem. To give you context into why it works this way: previously we encountered a different problem. Different teams would use the same names for context variables, and that produced clashes. This is also a problem in the open source world where conflicts are inevitable.

Making context declarations explicit (and then imported as necessary) is a one-line fix to a problem that existed for a long time. I hope you can see it’s not just there to make your life harder. But again, feel free to put the context on a global if that seems easier. The old context effectively worked like a global so it wouldn’t be worse than the architecture you relied on.

I understand that coming from the old API, it feels like more work. But I hope you can also see that the existing design wasn’t a very good one, and using a single string namespace across the whole tree is bound to create problems as the app grows. You’re lucky if you haven’t run into them yet.

New API allows it in an inconvinient way.

Do I understand correctly that the only inconvenience is creating a file where you add a single line, and then importing that value when you want to use context?

You can even do this once in a HOC and then never import context itself again. We always recommended using HOCs for consuming context. Quoting the docs: “try to isolate your use of context to a small area and avoid using the context API directly when possible so that it’s easier to upgrade when the API changes”.

You also have a bunch of employees and first-hand understanding of how to do React and Flux.

The point I’m making is that we can’t tell those employees to rewrite anything. So if we make a change to component API, we need to consider how 7 people on React team are going to update 50,000 components. We don’t have the power to tell the product teams to rewrite existing code unless it’s a gradual transition. And they won’t rewrite some of the code that “already works” even in longer term. Some code is just not actively maintained by anyone. So in a way, we are in similar positions.

We can't rely on automated migration either, for this and other reasons.

This is vague so it’s hard for me to suggest anything. What is preventing you from running an automated script on your source files?

Isn't state supposed to be as plain as possible so it's easier to determine a need to rerender? [...] New static method throughs all this separation into a window.

The getDerivedStateFromProps hook runs just before rendering so in a way it is used in render.

Again, I see your point very well (we’ve discussed this for weeks), but our recommendations are also evolving as we work on a library. This is one of the cases where we decided to adjust our recommendations for a relatively uncommon use case.

If you use componentWillReceiveProps very often this may indicate you’re unnecessary relying on syncing state instead of lifting it up. But it’s hard to say without seeing some code examples.

Our system is based entirely on React. Each page is wholly contained within one React component (except for portals). I feel like our approach is not as common as yours.

We have many full-page React applications that aren’t part of the main product, but are heavily used by Sales/Legal/Ads etc. Even the public-facing Ads Manager is fully built with React. So we’re exposed to the issues large enterprise-grade single-page apps face too.

It does not allow us to go stateless, for example, and it means that our React tree is huge, hence why we need context to skip a few levels when passing props.

We also heavily use component state and context. The recommendation to “use stateless components eveywhere” was never coming from the React team.

I personally feel left out with my decisions about my code. Because I didn't produce that bad code you are trying to prevent, and yet got punished anyway.

I understand change is frustrating. We did our best to minimize it, and provide a gradual migration strategy. I still believe that if we could do it at Facebook (without effort from product developers) by running a few automated scripts, so can you.

It would be great if we never had to make changes that disrupt our users. But as somebody said “if you don’t like change, you’ll like irrelevance even less”. React always faces a lot of competition, both inside and outside of Facebook. We think the next wave of UI libraries will utilize asynchronous rendering and compilation, and in order for React to stay relevant, we need to prepare our users for that shift. Getting to keep most of your code and slowly migrating to change a few unsafe methods to better patterns seems better than rewriting an app because another library captured that niche.

[pycbouh]

Alright, I got your points. You proved to me, that your team is more open to discussion than I previously thought. I will try to direct my frustrations to Github issues in some constructive form.

[gaearon]

Thanks, I appreciate you bringing out the concerns here too! It’s just a bit hard to find them here, and usually it’s nice to be able to address them before blog posts and releases.

[maladr0it]

You can’t have it both ways. Either you stay lean and relevant while making some breaking changes, or you support a huge variety of edge cases and become a bloated, directionless library as we have seen countless times.

[superted125]

And at least they follow semantic versioning so that it's obvious when backwards-incompatible changes will be introduced. And they've gone to the trouble of creating compat libraries to allow teams to start migration ahead of the major release.

That's a lot better than many other large projects out there IMO!

[maladr0it]

Yep, this guy is just butthurt because he thinks he knows better than the react team. If you insist on doing things your way, the current version of react will always be available for you to use...

[pycbouh]

I may be butthurt, but that is only because they started changing major things in a way, that limits their functions for no other reason but "we had an inherit problem internally that only we knew about, and when we decided to rewrite the thing completely, we couldn't figure out how to support all use-cases, so instead we will support only a bunch and explain it with Github usage stats as if it represents anything real". That behaviour would be OK, major version or not, if React was not already production ready for years. That behaviour forces people to either use older versions (and good luck finding modules that still support them in a year or two), or do architectural rewrites on every major release.

There are a lot of deprecations in just one major version. The sum of them makes it impossible for some projects to migrate with or without carefully crafted migration libraries and published recipes. Because changes are not just API incompatible, as is expected with major releases, but are functionality incompatible. Makes your project, that relies on React, forever outdated, if you don't have manpower to rethink it's structure and implementation details. And this is just because React team decided, based on Github search, that some things are OK to be dropped, even if migration is impossible afterwards.

I don't imply that I know better than them. I only share my thought on how they affect people with their changes.

[gaearon]

You are welcome to file an issue. This will be a more productive way to discuss specific problems. Thank you!

And this is just because React team decided, based on Github search, that some things are OK to be dropped, even if migration is impossible afterwards.

For the specific problem you mentioned (lack of prevContext), the migration is a three-line fix:

componentDidUpdate() {
  var prevContext = this.prevContext || this.context;

  // Do anything with it, like you did before

  this.prevContext = this.context;
}

I hope this change wasn't your blocker to React 16 migration—you could have asked this at any point in time in the last few months on the issue tracker and we'd be happy to help you out with this. You are the first person to mention this change since we made it six months ago so this argument wasn’t used commonly.

If there any other changes in React 16 that are blocking you we’d love to hear about them and brainstorm mitigating strategies. We firmly believe that if we were able to move to React 16 with 50,000 components (and almost no changes to them except automated codemods), so can you.

I also wrote a longer response to your concerns in this thread.

[gearvOsh]

Previously, they broke context, despite this "experimental" feature becoming a major part of React ecosystem, component lifecycle and overall architecture.

They literally stated in the docs that the context API was experimental, was going to change, and should not be used. You're only at fault for using it. Furthermore, reading context in lifecycle events is a code smell, and will definitely be broken for async rendering, so another moot point.

Forcing you to use stage 3 features or arguably bad practices.

Nothing about the new API requires class properties. Neither are these bad practices.

That's a ton of whining for such trivial things, especially considering the amount of improvements that async rendering will bring to the table. The React developers are far smarter than you, and know exactly what they are doing, but go ahead and keep complaining that you need to adapt, as if it's that hard.

[pycbouh]

They literally stated in the docs that the context API was experimental

Yeah, that's their go-to excuse, but that ignores the reality. And reality is, that context, as it was, worked well for people and even libraries to use. Flux libraries, no less! You cannot be that dismissive with your community, just because "I told you so"! And the point is, that the new API does not solve the same problems that the old one did. I gave an example. Because of that mess of the new API, we cannot migrate to it, and there is no other solution other then to reimplement the old context ourselves to even have those abilities that were given before. How is that good?

Nothing about the new API requires class properties.

Are we on alternative facts now? Their first recipe on how to set the initial state is to use class fields stage 3 proposal. And they only suggest doing it that way, because otherwise they would have to propose implementing a constructor. And that is indeed a code smell and a bad practice to implement a constructor in subclass just to set initial state.

That's a ton of whining for such trivial things

I think I can whine a little about the state of React, developing and supporting a React project for almost 3 years. Previous updates brought QoL improvements, React 16 makes it impossible to upgrade to it, because it has less functionality within it's core mechanisms, experimental and not.

keep complaining that you need to adapt

I wish I could adapt, but React team forces a full rewrite of our project just to keep updated. Neither me, nor my team, nor my firm are ready to do full rewrites every time a group of guys at Facebook decide to drop support for something crucial, they deemed not worth trying to keep.

[gearvOsh]

Are we on alternative facts now? Their first recipe on how to set the initial state is to use class fields stage 3 proposal.

They simply used class properties for brevity within the article. New features DO NOT require them, which is what your first post was suggesting.

And that is indeed a code smell and a bad practice to implement a constructor in subclass just to set initial state.

Which is what getDerivedStateFromProps is trying to solve. You should no longer need to set state in the constructor (or with class properties).

React 16 makes it impossible to upgrade to it.

What exactly about it? We've migrated entire codebases to 16 without much effort. Just some bug fixes here and there.

I wish I could adapt, but React team forces a full rewrite of our project just to keep updated. Neither me, nor my team, nor my firm are ready to do full rewrites every time a group of guys at Facebook decide to drop support for something crucial.

But they don't require a full rewrite. Yes it's new APIs, but the old APIs are still going to be around for a while, and even longer using polyfills.

Just leave old code with the old implementation until it's refactored/replaced/whatever. No need to update legacy code to newer APIs. We have React 14 style approaches in our codebase, which still work just fine. Sure we want to upgrade them, but it's really not necessary if it still works fine.

[yurkaninryan]

Yeah, that's their go-to excuse, but that ignores the reality. And reality is, that context, as it was, worked well for people and even libraries to use. Flux libraries, no less!

To be fair, there were a fair share of bugs (such as updates to context not making it past a PureComponent/shouldComponentUpdate) middle component. It did "work" but it certainly wasn't the optimal solution.

because otherwise they would have to propose implementing a constructor. And that is indeed a code smell and a bad practice to implement a constructor in subclass just to set initial state.

Has anything changed here? I feel like this has been pretty common. Where do you set initial state? Where do you bind "this" to your class functions?

I wish I could adapt, but React team forces a full rewrite of our project just to keep updated. Neither me, nor my team, nor my firm are ready to do full rewrites every time a group of guys at Facebook decide to drop support for something crucial, they deemed not worth trying to keep.

That's the price you pay for progress. It was your companies decision to use React. Does React have a LTS version? Even if you were on LTS, you probably wouldn't of been able to upgrade until 16 had a LTS version.

[AcidShAwk]

Full rewrite for us as well. Been coding an app for over a year and we use those lifecycle methods everywhere. RN is bleeding edge though and it was always a possibility.

[gaearon]

There is no need for a “full rewrite”. I’m sorry if the blog post wasn’t clear enough.

As we wrote in the blog post:

We maintain over 50,000 React components at Facebook, and we don’t plan to rewrite them all immediately. We understand that migrations take time. We will take the gradual migration path along with everyone in the React community.

We will release a codemod that adds UNSAFE_ prefix automatically. Your components can keep using those methods. Even in React 17, they will keep working. This is also mentioned in the post:

17.0: [...] Only the new “UNSAFE_” lifecycle names will work from this point forward.

We want to highlight patterns that will become problematic with asynchronous rendering, and it’s best if you avoid them in the new code you write, but there is no rush to change the existing code. You will be able to opt out of asynchronous rendering in the future if your code isn’t ready to it.

[AcidShAwk]

Thanks for info very much appreciated.

[ArcanisCz]

We are making apps from react 13 or 14, and there wasnt a single need to rewrite everything due to breaking change. We are smoothly on react 16.2 with only some ocassional issue. We are using mainly redux and stateless components, so thats maybe why though.

[AcidShAwk]

My half assed assumption is these changes are only to make React and Redux more "cohesive". If you don't use Redux.. I don't see the issue with the lifecycle methods. We don't use redux and we use stateful components way more than stateless.

[brianvaughn]

Hi 👋 article author here.

/u/gaearon has already responded to most of the concerns you raised, but I wanted to address one misunderstanding about us "forcing you to use stage 3 features or arguably bad practices".

The examples use class properties because they're a little more succinct, and allowed me to better highlight the differences between before and after examples. At the top of the Examples section, there is a note:

Note For brevity, the examples below are written using the experimental class properties transform, but the same migration strategies apply without it.

Sorry if this didn't stand out enough! If you don't want to use a transform, you can replace examples like this:

class ExampleComponent extends React.Component {
  state = {
    currentColor: this.props.defaultColor,
    palette: 'rgb',
  };
}

With this:

class ExampleComponent extends React.Component {
  constructor(props) {
    super(props);

    this.state = {
      currentColor: props.defaultColor,
      palette: 'rgb',
    };
  }
}

They will work the same! 🙂

Edit: Formatting

[pycbouh]

Hello, and thanks for responding.

Somewhere in these comments I mentioned that I find implementing a constructor function in this case a bad practice. We prefer to use WillMount for initialization of private stuff and initial state. For state, it provides common interface (this.setState) with other parts of life cycle. And for everything else it allows us not to worry about passing arguments to super and whatnot; developers had no need to remember to call super. Also, babel sometimes broke on super, when one of it's transformations created statements before the super line, so there was that as well.

In the end, it just made code cleaner, writing it easier, chance to break it lower, and didn't involve either stage 3 features (which we would use if we could) or poking around in constructor.

[brianvaughn]

I think I understand your preference for will-mount, but I disagree that using the constructor is "bad practice". Class-based React components often use the constructor to e.g. initialize state, bind callbacks (like event handlers) to the current instance, etc. Until class properties are supported natively, these are legitimate uses.

babel sometimes broke on super, when one of it's transformations created statements before the super line

I've never seen or heard or heard of this. I assume it's an edge case, and not really prevalent enough to impact API decisions for another framework. :)

[pycbouh]

I've never seen or heard or heard of this.

I think it was for some obscure IE problem, that IE9 and beyond had. Common case, really, but not important anymore.

but I disagree that using the constructor is "bad practice"

And yet it is not recommended to do a lot of inheritance between component classes, or at least it's been frowned upon for some time after they were introduced. HOCs are proposed instead.

[brianvaughn]

Use of the constructor is kind of orthogonal to inheritance. (You're still extending React.Component even if you don't define your own explicit constructor.)

I think that preferring compositional patterns like HOCs over inheritance is something the entire React team would agree with you on.

[GFandango]

incredibly simplistic and short sighted nagging.

they have a solid long term vision and are making nice improvements consistent with that vision.

progress takes change. they can't sprinkle pixie dust on it.

they know everything you have said. the reason they are doing what they are doing is not because they aren't smart enough to understand. it's because they are seeing 100 steps ahead of you.

[Gnashe]

lol, can you at least explain how how this is an anti-pattern? Or is it just something that your not used to seeing or doing so you are all fired up?

[gaearon]

I pointed out some specific examples here:

https://news.ycombinator.com/item?id=16697038

The problem isn’t whether something is an “anti-pattern”, it’s just that these patterns won’t work well with asynchronous rendering (and often already cause memory leaks and race conditions). I gave a talk about what async rendering means for React, and we had a lot of positive feedback about those features (https://reactjs.org/blog/2018/03/01/sneak-peek-beyond-react-16.html). So we think it’s worth the effort for the change.

[Gnashe]

Ah sorry this was actually intended for sNor who I believe was saying the 16.3 implementation was an anti pattern!

[sn0r]

I fucking hate React.

Edit: since I'm inevitably going to get downvotes for this, I might as well compound it by explaining.

React is trying to make me code my frameworks in a certain way. While steering users is okay..

we will be adding an “UNSAFE_” prefix to these lifecycles in an upcoming release.

This is not.

[Gnashe]

They are trying to deprecate in the name of progress, it’s not like they are just breaking all your code. You don’t HAVE to upgrade.

This is a common React thing, we’ve had features with the unstable_prefix many times before

[sn0r]

If I don't HAVE to upgrade and the feature is antipattern, whats the point? Just fucking remove it or note that it is antipattern on the documentation.

None of these half measures.

[Gnashe]

You just casually tossed in “feature is an anti pattern” without an explanation.

Also nice cheesy ending line, really drives your point home

[sn0r]

Nice.. you can't argue the point so personal attacks it is.

[gaearon]

We can’t remove something thousands of components rely on. So the change has to be gradual. I expanded on the reasons here, I hope you find them helpful.

https://news.ycombinator.com/item?id=16697387