Please don’t create HOCs for error boundaries. They are not necessary. Regular components work just fine there! <ErrorBoundary />
-
-
Replying to @dan_abramov
I mean, you can do anything, but I don’t see the point there. They don’t need to be customizable at definition time. Just use components.
1 reply 0 retweets 12 likes -
Replying to @dan_abramov
Error boundary work many levels deep, so there’s no need to “wrap at every level”. Just put your <ErrorBoundary> in a few strategic places.
5 replies 4 retweets 35 likes -
Replying to @dan_abramov
One good use case for HOC would be if you want to protect all usages of a specific component. Then you could wrap it. (Thanks
@acdlite!)2 replies 1 retweet 18 likes -
Replying to @dan_abramov @acdlite
Still, I’d suggest to have few error boundaries in places you want to protect rather than wrapping a lot of different things at definition.
1 reply 0 retweets 8 likes -
Replying to @dan_abramov @acdlite
Anyway don’t listen to me. Figure out what works for you and what doesn’t. I’m just being grumpy
3 replies 0 retweets 34 likes -
Replying to @dan_abramov @acdlite
I guess the main thing I’m trying to say is: resist the impulse to wrap *every* component in error boundary. That’s just bad UX.
3 replies 3 retweets 19 likes -
Replying to @dan_abramov @acdlite
"why have you wrapped this?" "it could throw" "but it's a div!!". Yes, a could see this happening
1 reply 0 retweets 1 like -
BTW. What about IDEs. Is Atom, VS, Webstorm are support new array returns introduced in React 16?
2 replies 0 retweets 0 likes
Haven't tested 16 beta yet, planning to have a look later this week.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.