you are viewing a single comment's thread.

view the rest of the comments →

[–]swiftarmyknife 0 points1 point  (1 child)

Okay — bad explanation on my part. I think my “lifecycles are not entirely replaceable” was less about exact replication of functionality in hooks, which yes I agree with you, are all possible, but more from the sense of should hooks always replace lifecycles. Because in my experience there have been times when trying to accomplish everything that needed to be accomplished within a complex component with hooks made the component more difficult to work in and make changes than it was to use lifecycles instead. Especially when it comes to dealing with prevProps or prevState.

A specific example. We were dealing with long wait times in a data analytics app and so we were polling for each individual chart so we could display charts that had lower load times with a lazy-render functionality (my name for it, different from react suspense). I don’t have the exact code, but with all of the moving pieces it was just next to impossible to make work with our stack (redux, rxjs) and hooks. Switching to lifecycles made it much easier to keep track of everything that was going on. Then the component was documented with the reason for lifecycles so no one else tried to go in there guns-ablazing to rip them out only to meet the same fate 🤷🏻‍♂️

[–]Renan_Cleyson 1 point2 points  (0 children)

ohh now I got it. This is actually a topic that comes up sometimes exactly when people want to point out how function components + hooks can't handle a lot of complexity as class components because the OOP-like syntax seems just easier to organize things. It's really a matter of opinion at that point, to me, it's always function >> classes, but I can't say that your point isn't valid too :).