fix profile double type and links bugs, tidy profile code

[chrismclarke]

PR Type

• Bug fix (non-breaking change which fixes an issue)

PR Checklist

• - Latest master branch merged
• [x - PR title descriptive (can be used in release notes)
• - Passes Tests

Description

• Remove additional workspace type text for regular profiles (closes [bug] Profile with "double type" after editing #818)
• Refactor profile links to own component and remove code duplication (could be further tidied but small improvement for now)
• Add workaround for opening URLs without HTTP prefix (fixes [bug] - Profile links without full url (e.g. https://) don't link correctly #968)

Git Issues

Closes #818
Closes #968

[cypress]

---

Test summary

60 • 0 • 0 • 0

---

Run details

Project	onearmy-community-platform
Status	Passed
Commit	798632e ℹ️
Started	Jun 9, 2020 6:30 AM
Ended	Jun 9, 2020 6:35 AM
Duration	04:34 💡
OS	Linux Ubuntu Linux - 16.04
Browser	Multiple

View run in Cypress Dashboard ➡️

---

This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard

[BenGamma]

Yep that fix the issue with the links that doesn't have http:// protocol.
I was mentioning in my comment that we had a addProtocol mutator to add the protocol on the form validation when the user is saving his infos. But for some reason the mutator passed here is not going down to his children Link.field anymore.

So actually at the moment you can save whatever text you want from the links inputs in the user settings, there is no custom validation anymore (customOnBlur method not being called). Maybe we missed that during the previous refactoring of the settings form ?

I tried to add the customBlurMethod on the Link.field but I didn't manage to triggered the mutator from there, I'm probably missing something in the way react final form pass down props.
Do you think you can have a quick look at this before merging ?

[chrismclarke]

Sure thing, can take a quick look. Yeah I had remembered there being a better URL check before, so will be good to get that back in alongside the fix for existing links

[chrismclarke]

OK, yeah I see the problem. It was part of the refactor, specifically the way the mutator was used previously isn't really compatible with array mutator used for form links.

I've fixed it so that first the form now properly checks the validation methods (a state variable required wasn't being updated), and added a standalone format method to use directly in the input format function instead of form validators for the links. I also checked the only other place the protocol validator was used (events page) and that is still working fine without change.

So should be good to go assuming the latest commits passes tests. Will check back in tomorrow

[BenGamma]

Cool thanks for the fix Chris. I added 3 small commits, nothing critical. See commit message for description.

I noticed a warning in the console when the input is empty :

A component is changing a controlled input of type undefined to be uncontrolled. Input elements should not switch from controlled to uncontrolled (or vice versa). Decide between using a controlled or uncontrolled input element for the lifetime of the component. More info: https://fb.me/react-controlled-components

I guess it's because we use a custom method to validate the field onBlur that is now in conflict with react-final-form validation. Since it's just a warning and we know why it appends, it's fine to me. I'll approve and feel free to merge :)

[chrismclarke]

Great, thank for that. Yeah I jumped back and forth on whether directing to http or https site would be better, I still think it would be better to by default assume the site as https for a couple reasons:

1. Not all sites are setup to redirect from http to https if they have certificates installed. E.g. visiting http://apache.org/ will give the insecure version of https://apache.org/ in most browsers

2. More than half of the world runs on https and that includes all major social media outlets (likely where people will be linking to).

Let me know if there's another reason you had thought of though that I have missed, otherwise we can revert that one small change and merge.

Happy with the other additions though (I understand the warning given, ideally we should be make those form alterations at a higher level and passing through state but I tried and it was a bit messy and tricky to get working correctly...so I suggest just leaving for now).

[BenGamma]

I agree on your points but I removed it because :

• Even if we consider https better & more secure we shouldn't change the user input (more than we already do).
• For social media they will be redirected to https anyway but you can also add your own website which is more likely not to be under https (small associations and non technical ppl don't have the reflex to activate https on their hosting like we do)

[chrismclarke]

Ah, I understand the confusion now - yes we definitely don't want to be changing things a user has put (especially if it can't be changed back by them), but the protocol change only happens if there is nothing there - i.e. if they want their HTTP website, they can still type http://... and it will stay the same.

Actually even for personal websites HTTP is super rare these days, as most people like to use 3rd party web providers and all the largest ones (e.g. heroku, google firebase, netlify, zeit etc.) all provide free https as a default - so it's only really for sites running on their own personal web servers. And again, this is still much less that people who will just be putting social media links. So I've reverted back to https and will merge

[BenGamma]

Well I REVERTED BACK TO HTTP (that's a joke) 😁

Sorry I'm reopening this branch because I've spotted a weird behavior in the link validation while doing a last check. See a screencast here
It happend in the case you have an invalid url first, then the validation removes the last char of the input. But I don't get it because we are not striping any character, we are just adding from the existing value 🤔

I've added a commit also to remove the url check on discord type, which are not links but discord id (mine for example is benj#2480)

I'm always surprised of the ability of this form errors to always end up in headbanging. But we're almost there 👊

[BenGamma]

I moved the discussion to #979

[chrismclarke]

hahahahaha! I wouldn't have been surprised. Whaat? that bug is super weird. Oh and good catch on the discord - I'm guessing we should actually link to the discord user page but that can be a job for another day if someone else views it as important.