I just did a quick look, but it seems to suffer from common problems lots of UIs suffer from. Zero tests (unless I missed where they are located), even for things that doesn't even touch the DOM (like the "helpers"). Components filled with heavy logic at instead of being cleanly separated out. Just two examples after a quick 5 minute browse.
That said, I've definitely seen worse codebases and this wouldn't be too hard to work on in a professional setting. Clearly it works for them, and they seem to be progressing, which is good enough. But again, wouldn't flag it as "exceptional" either which you seemed to have done here.
Maybe AI will change that. But for now I think dev time is generally better invested in other ways of making code work properly, or just fixing bugs that have already been reported.
I know that sounds heretical.
Yes, that's because you're doing them wrong.
Don't mess around with the "golden master" testing (edit: seems the frontend ecosystem call that "Snapshot Testing" actually, but it's the same) you see bunch of projects do, that compare the old DOM vs the new DOM you accept/deny changes based on component render output. That's a waste of time and won't actually prevent bugs.
Instead, extract the logic-heavy parts out from your components, then put those under unit tests, like any other code you write.
Boom, easy to maintain, verifies your implementation and makes your UI easier and faster to refactor and build in the first place.
In an ideal world one might argue that everything testing-worthy (ie. the logic-heavy parts) is already factored out from the UI components but getting to that point either needs a good amount of foresight and discipline or some a lot of refactoring which is difficult to trust without existing UI tests...
This is not the best practice codebase as I wrote it when I was learning Django. But is it very applied. Any beginner should be able to understand this.
I remember looking once at a project me and some others got pulled into, where everything was working but the code was spaghetti (which, to be fair, is usually why I get pulled in), and they were having a hard time adding new features without breaking existing ones.
At first, our reaction was the same as many programmers; "Oh my god what have they done and why have they done it like this?!"
Turns out, the company was on the brink of extinction, had about two months of runway left and made this Hail Mary project to attract some new attention and eventually landed them new funding.
So the project was rushed, a lot, but that's OK, but if they didn't rush and wrote super shitty code, the company wouldn't have existed at all. They were OK with this, because they traded "existing today" for "refactoring in the future", which sometimes is the right call to do.