I think you were right originally about having a global logged in user object on the frontend. I can help with the development of this. Adding this would make writing several other pages easier…
Turning this into an API endpoint is actually dangerous, as the returned user contains the password hash. This field should be set to None before returning. Although technically the user is only returned if that user has already logged in (and therefore should already know the password), this is still not a good practice. I know I advised you to use this function, but we should add this protection. However this code may change anyways, see my other comment about potentially adding a new function returning an Option<User>.
Here you're making two separate calls to get_user, each of which causes an API request. In the interest of performance, it would be best to do this as a single query.
See comment about the duplicate requests. I'm also debating changing how get_user() works (for the profile page work I'm doing) to return an Result<Option<User>, ...> instead of a Result<User, ...>, because there is a strong distinction between not having a user logged in, and a server error occurring when checking if a user is logged in.
1f70da1747
Merge pull request 'Added webp files' (#125) from 121-add-webp-files-to-gitignore into main
This is good, except for a few things:
- You didn't quite follow the format of the migration folder name.
- In order to access the data in this column, add a field to the Song struct in…
f299254d55
Merge pull request 'Fix Docker compose missing libretunes-images volume' (#120) from 119-fix-docker-compose-missing-libretunesimages-volume into main