How do you take breaks from coding? When do you quit using a broken OSS framework for a project?

What do you do when you find what you're working on completely fails, and the open source project creators/maintainers have very little support on Discord/Slack?

Sorry for all of the frustration that you are feeling right now! I've been there, too. I also work on frontend, so I've been through the limbo of having to evaluate many open source solutions. It might be worth it to find the library that offers as close of a solution as you can get, fork it, and modify the code to fit your own needs.

How do we know when to take a break (as in stop coding) after trying to debug for hours and days on end?

At some point, it is easier to modify or dig into the project codebase than to try force the library to do what you want. It sounds like you might be reaching that point. I don't know if the solution is to take a break, but rather, it might be to zoom out and think about how you would solve the problem from scratch if you were an author of the open source project. It sounds like you are hitting a point of diminishing returns with the library. That's usually a signal that it's time to revaluate the approach you're taking.

I'm not a front-end web dev, but I've gone through a similar experience doing iOS development. iOS has a pretty weak OSS scene (at least compared to Android) as:

1. Apple is terrible at designing APIs
2. The iOS SDK and operating system are closed-source, unlike AOSP (literally stands for Android Open Source Project)

When you are running into major OSS library headwinds, just switch. For what you mentioned (bad code, no maintainer support), this seems like an obvious case where you need to find another library. Hopefully there is another one that theoretically does the same thing for your use-case.

In terms of when to give up, my general advice is to work backyards from deadlines and timebox things. For example, let's say you have a project that takes 1 month and just 1 of 4 components requires some library:

1. You have 1 week to build that component (1 week out of 4 in a month, assume components are equal weight)
2. To build a component, you need to first scope out general strategy and then implement
3. A good breakdown of scoping out/implementation is like 2 days/3 days. So 2 days to plan and socialize approach with team and 3 days to write the code once approach is figured out
4. Scoping out includes what library to use, so if a library is failing after 1-2 full days of trying to get it to work, I would just give up and pivot to another

Unless you are working on some massive project at FAANG, 2 weeks just to choose a library is way too long. I can't imagine this process taking more than 2-3 days. It shouldn't take long to figure out that a library just isn't going to cut it. If a library is well-documented, importing the module and calling the APIs should be fast. If the library is poorly documented, including the steps to import it, well... That's a probably an immediate sign you shouldn't use the library haha.