95-fix-home-screen-account-button-ui #124
eta357
Reference in New Issue
Block a user
No description provided.
Delete Branch "95-fix-home-screen-account-button-ui"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Fix formatting/styling and give functionality to personal profile section, including logout, login, and signup.
This PR resolves #95.
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 anResult<Option<User>, ...>instead of aResult<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.There's also a few things that maybe should be changed with handling errors/options here (with
Show, etc.). We can discuss these some other time.I'll have to think about this.
@ -16,1 +18,4 @@let (dropdown_open, set_dropdown_open) = create_signal(false);let (image_error, set_image_error) = create_signal(false);let user = create_local_resource(move || dropdown_open.get(), |_| async move { get_user().await });let logged_in = create_local_resource(move || dropdown_open.get(), |_| async move { get_user().await.is_ok() });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.
@ -138,3 +139,3 @@/// }/// ```#[cfg(feature = "ssr")]#[server(endpoint = "get_user")]Turning this into an API endpoint is actually dangerous, as the returned user contains the password hash. This field should be set to
Nonebefore 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 anOption<User>.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 and likely improve performance. This includes the profile page, and any other user-specific pages.
please merge, thanks team