Hacker News Reader

Comment by ervine | Hacker News Reader

Maybe bad UX, but global error / success handling of network requests is way easier than handling in every component that triggers one.

View on HN

I don't think that's a convincing argument unless you are a tiny company that has to optimize for development time. You can also wonder why the frameworks you are using make this hard, because it's a pretty common to want feedback close to where the action happens.

I didn't say it was hard, it's just very nice to not have a bunch of extra error / success code in all of your components that make async requests.

Trade offs, as usual.

In my experience the overwhelming majority of teams out there are understaffed (especially when it comes to good and productive professionals) so your example is the rule, not the exception.

I don't know anyone who isn't optimising for development time in some way. That said, most frameworks don't provide any worthwhile error handling infrastructure, and it's a problem.

In a Jetpack Compose app I wrote, I created generic "error barrier" components, so that error messages display over relevant parts of the app, with just a few lines each time, timeouts included. I think this is the best approach, easy for developers and informative for users. Too many apps just ignore errors.

I meant optimizing for developer time over usability in the context of the story, that mostly shows products from Google. Google being the opposite of a small development team that could be forced to choose developer time over usability.

Then refactor your app to make it easy. If it is hard in your tool, choose a different tool that make it easy.

Again, it's not hard - just being devil's advocate for when toasts are useful.

Less code, centralized messaging.

Reply on news.ycombinator.com