@petabite

• You can add the edit profile button on the navbar of the Profile screen because our navigation is complete so feel free to do that you next work on this.
• When integrating this with our MVP navigation, make sure to create a boolean called isVersionMVP or something similar in which case the edit profile is hidden. That will enable us to release the app MVP without the edit profile being finalized

Where to add the edit button?
#149 (comment)

In addition, for the save / cancel button can you look into and implement which one is feasible? Options are -

Approach 1: Use the custom navigation "Components/CustomNavBar" components to design this navbar.

This is surely the ideal and scalable approach because it will enable us to keep our existing navbar in use. This does seem doable because using preference keys you could set the display state (show/hide) and handler for save and cancel buttons when inside the edit screen.
@YashRavipati1 please add anything you know more about this!
For reference:

• Custom NavBar Tutorial - https://www.youtube.com/watch?v=aIDT4uuMLHc
• Preference Keys - https://www.youtube.com/watch?v=OnbBc00lqWU

Approach 2: Hardcode the header for edit screen and hide the generic custom navbar

Just like the profile display screens, hardcode the navigation bar with the buttons. Hardcoding here is not an issue here because we don't have a requirement to have a save/cancel button on the navbar apart from edit profile. Note: "Cancel" always goes back. (can be enabled by doing dismiss in the NavigationView)

@petabite

* You can add the edit profile button on the navbar of the Profile screen because our navigation is complete so feel free to do that you next work on this.

* When integrating this with our MVP navigation, make sure to create a boolean called `isVersionMVP` or something similar in which case the edit profile is hidden. That will enable us to release the app MVP without the edit profile being finalized

Where to add the edit button? #149 (comment)

In addition, for the save / cancel button can you look into and implement which one is feasible? Options are -

Approach 1: Use the custom navigation "Components/CustomNavBar" components to design this navbar.

This is surely the ideal and scalable approach because it will enable us to keep our existing navbar in use. This does seem doable because using preference keys you could set the display state (show/hide) and handler for save and cancel buttons when inside the edit screen. @YashRavipati1 please add anything you know more about this! For reference:

* Custom NavBar Tutorial - https://www.youtube.com/watch?v=aIDT4uuMLHc

* Preference Keys - https://www.youtube.com/watch?v=OnbBc00lqWU

Approach 2: Hardcode the header for edit screen and hide the generic custom navbar

Just like the profile display screens, hardcode the navigation bar with the buttons. Hardcoding here is not an issue here because we don't have a requirement to have a save/cancel button on the navbar apart from edit profile. Note: "Cancel" always goes back. (can be enabled by doing dismiss in the NavigationView)

For my own input regarding this comment: For the edit button I already use a ProfileHeaderComponent rather than the regular NavBar. Take a look at the code for that because you can just add the symbols/images you need and then pass in a state variable to edit what buttons show up on either edge of the header. Regarding the save and cancel buttons once you are editing the profile: I honestly think either method would work just as well. Although the first method is more "scalable" in a sense since it uses the custom navbar we are using, since this header will pretty much be exclusive to the edit profile screen (the save button shouldn't be used anywhere else since its purpose is just to save the profile) I don't think hardcoding it is the worst idea either. Adding a new preference key to the customnavbar could just make the code for the customnavbar excessive/cluttered when we really only use that preferencekey once, but IMO it really is up to you. Like I said, either solution seems good to me and both have their pros/cons.

One small bug i did not have time to fix: After uploading a new profile image, and tapping "Save," the mentee/mentor profile view does not update with the new profile image, but everything else updates correctly 🤷 (i think this is some sort of state issue but not entirely sure)

One small bug i did not have time to fix: After uploading a new profile image, and tapping "Save," the mentee/mentor profile view does not update with the new profile image, but everything else updates correctly 🤷 (i think this is some sort of state issue but not entirely sure)

Not entirely sure but might be worth looking into the CurrentUser (or something like that) struct that is used to hold the in session user. There's a way we refresh the fetching of this struct so maybe if you refresh that helps.