Profile fields should have an edit capability

[glenyingchua]

Expected behaviour

User can see an edit button beside the fields. When clicked, the field turns from display view to edit view with a save button. User can also press enter to save.

Social media links editing feature will be consolidated through one button beside all the links. When clicked, users can put urls beside social media icons with save button.

Dependent on Issue #346 completion.

Checklist

• This issue is linked to the appropriate project.
• This issue has appropriate labels.

[sheacronin]

Today we mostly worked on the social network input fields. We created state in the SocialLinks component that stores the social networks so that networks can be added and removed on the frontend. We decided to limit the user to have 5 social networks at most. There is a dropdown of social networks and an input field for the username/data for each added social network. One thing we need to think about is how to submit the social network data to the database in the correct format using the inputs we have created. The GitHub link is not editable, because the user will always have the same GitHub account that they signed in from.

Previously, we created editable fields for the username, email, and bio.

Things to work on:

• Responsive for smaller screens when in edit mode
• Connect to the real data
• Add state for the name, email, and summary to be updated
• Create a put route to submit new data for when the edit button is toggled off
• Add onChange function for the social network input field and a function to update the state when the user submits their data
• Decide whether we will allow users to have multiple social networks of the same network type (like can they add multiple LinkedIn profiles?). We probably want to let them add multiple websites if desired.

[seidior]

Added in the latest changes from #356, so now you should be able to receive an IUserData object from the database, render it, edit it, and send it back to the database (in an HTTP PUT request). The API will handle all the comparisons to see if anything has updated so that you don't have to do anything special to keep track of changes on the frontend or call different methods for different fields that are added/modified/removed.

[seidior]

Hello, OpenTree family! I'm wrapping up for the evening and I'd like to share my progress of where I'm at for the day.

Compared with the state last night, the profile page is now pulling directly from the database for its information with absolutely no placeholder content. (Sorry to our fictional test user!) Huge thanks to @achichikalova and @Nazanin-Rezaei for getting that work started this morning on the front end and to @SiriusLL for working late last night to try tying in the backend stuff.

This afternoon, I completely re-architected the editing / saving functionality based on combining both teams’ work with React best practices. The user data is now being properly loaded into the profile page's state from the API and is being rendered on the front end. Changes to the user data within the state variable get reflected on the page immediately. And that user data object can now be sent to the server for updates!

I've also updated the bio (from GitHub), full_name (from GitHub), and email_address fields (from social networks) to pull the data from their corresponding places if the fields are not defined (such as when first logging in). However, upon first save, all of those fields’ values that were pre-populated from their original places are now copied into the principals table as they should be.

Here's a quick overview of how it looks right now. This is just after first logging in (although I cheated and added some extra social profiles in my database so you could see how it looks with multiple profiles defined):

This is after clicking the edit button (sorry, I haven't styled anything yet):

And finally, this is after clicking that big "Change My Name to Something Else" button, which changes the full_name in the userData state variable to "OpenTree Education", then pushes that userData object up to the API using an HTTP PUT. The API then saves that field in the database so future page loads show with the full name field override of "OpenTree Education":

(And logging out and logging back in preserves those overrides, as it should.)

I’m really happy with the progress we made this week, and the end product is looking closer and closer to the ideal of how we set out initially. Extra thanks to everyone who put in late and early hours to get as much done as possible.

While the commits from today did clear up a bunch of tasks, there’s still lots more detail work to be done such as making the full name editable, making the social profiles actually editable (they just look editable right now but they’re not; I just wanted the form controls pre-populated with data from the database), making the bio editable, and tons of styling work. Plus, I was really pushing today and I could have been a lot better about commenting the code I wrote.

[seidior]

Decide whether we will allow users to have multiple social networks of the same network type (like can they add multiple LinkedIn profiles?). We probably want to let them add multiple websites if desired.

I'm going to say this is out of scope. Great ideas; however, the purpose of the website is mostly to link to a single portfolio site, and it's unlikely users will ever need to add more than one profile of any other type (the database schema doesn't support this right now, and it'd be tricky to modify at this point).

But insightful out-of-the-box thinking, @sheacronin and @MahoMori.

[seidior]

Daily update: no forward progress was made on this ticket, but I did bring the branch up to date with the latest from #356 which now causes all automated tests on code for the repository to be updated.

I did have to revert a commit from the #356 branch because it affected files in the webapp/ subdirectory. I'll have to manually incorporate those changes here to preserve the work that was done by the mentees.