Hyperlink URLs so that they are clickable

[iteles]

As a user who keeps the details to her tasks elsewhere (for now, until further notes and attachment features are available), I would like to be able to have link I add to my list items be clickable So that when I go into my list I can quickly click through to the things I need to reference in order to be able to get up and running with my task quickly.

Level 2 of this will be to have the links converted to a short URL as opposed to just hyperlinked but that is absolutely not a priority for now!

Acceptance Criteria

• [x] When I click enter to complete the writing stage of my task, the URL portion of the task appears underlined
• [x] When I mouse over the underlined URL appears in a different colour (on desktop)
• [x] When I click on the underlined URL it opens a new tab with the linked URL and takes you to that tab
• [ ] When I click anywhere else in the task other than the URL, it opens up the task in Edit mode

[nelsonic]

@iteles thank you for opening this issue to capture your feedback/requirements. 🙌

At present the behaviour we have for items in the MVP UI/UX is that single-clicking/tapping on the item.text will enter "edit mode" 📝

If you can please be specific with your requirements. Please add acceptance criteria/checklist to the OP, then we can build this on Monday.

Related to https://github.com/dwyl/app/issues/281 which is specific to GitHub links :octocat: and https://github.com/dwyl/app/issues/279 more generic. 🔗 As for the link shortener, totally agree this is a super useful feature: https://github.com/dwyl/app/issues/284

[iteles]

I've added a starter acceptance criteria :+1: In reality I think this will evolve a LOT as we add other features, but I've tried to keep this as simple as possible for now.

If the interaction is difficult on mobile because of the smaller touch area and getting that right, we could add the following as an addition to criteria 3:

• [ ] On mobile, clicking anywhere in the task including the URL opens the task in edit mode

[nelsonic]

@iteles these acceptance criteria are a good starting point 👌

In the 3^rd AC the part about "and takes you to that tab" is definitely a separate requirement and is controlled by the device browser settings:

We can set the links to target="_blank" so the browser knows we want to open a new Tab. But we cannot force it to make the new tab active.

Let's start by trying to split the item.text into a <label> and an <a> so that the browser can treat the two things separately.

We can pair on this today when A* naps if you have time. 💭 👩‍💻

Follow up question: should an item be allowed to have multiple urls? ✌️

[panoramix360]

hey everyone! @nelsonic @iteles @LuchoTurtle

I hope you are doing well!

I was thinking of getting this issue, I know this is old, but is there some progress on this?

If you guys have any other issue or even repo in mind so I can contribute more, let me know!

[nelsonic]

@panoramix360 thanks for reminding us of this feature. We are very keen to have it. 🔗 But it's not as straightforward as it appears from the OP... 💭 At present the behaviour when we click/tap on item.text is to switch into Edit Mode. 📝 And to split the item.text into a plaintext and an URL requires stepping back and considering the longer-term goal(s) for the interface: https://github.com/dwyl/app/issues/275#issuecomment-1646862277

However ... 🤔 💭

Revisiting the DOM of the MVP we see:

The item.text is a <label>.

Code: https://github.com/dwyl/mvp/blob/93df1b9ad7e55d1315da74b4339559f831527500/lib/app_web/live/app_live.html.heex#L420-L427

Instead of just calling a <label> and printing the item.text we could invoke a function here that can parse if there are links in the item.text ... 🔗

[panoramix360]

hey! nice tests!

I believe that inserting <a> inside the <label> will work.

We should only test if the link will be clickable and won't trigger the phx-click on the label.

Are you making an experiment?

[nelsonic]

@panoramix360 yeah, I’m trying to get something working. But it looks like I may need to use a LiveView Component … 💭

[panoramix360]

Good idea, we could create a LiveView component called LinkComponent.

Inside it, it will receive a text, then separate the links and use the link library to shorten it.

And render the <a> together with the <label>

I think that's a good solution and keep things separate.

[nelsonic]

Full Markdown Support working in my SPIKE: live/editor.ex

Try it: https://amemo.fly.dev

# Hello Inês! 😊

Write something **bold**, _italic_ or ***both*** with a 
[link](https://mvp.fly.dev/)
and some code `dbg("hello")`.  
Pasting URLs directly works too: 
https://mvp.fly.dev

![iteles](https://avatars.githubusercontent.com/u/4185328?s=80&v=4)

+ Bullet Point
1. Ordered List

Quietly confident that we can get this working in the MVP now. 🤞

[nelsonic]

Thanks to: https://github.com/dwyl/link/pull/5 Longer GitHub links pasted into the <textarea> are now "compacted":

Try it: https://amemo.fly.dev/

Type some text ...
[link](https://mvp.fly.dev/)
https://mvp.fly.dev/
Long links are compacted:
https://github.com/dwyl/mvp/issues/141#comment

e.g:

Only a couple more steps until this is in the MVP. 🧑‍💻 But ... have to go do something else for a few hours now ... ⏳

[panoramix360]

I think I found a bug on dwyl/link, testing on the fly.dev app you sent.

When you type ...something it generates a link to this.

Is that expected?

[nelsonic]

@panoramix360 thanks for QA-testing. 🙏 That's definitely a false positive in the URL parser RegEx: link.ex#L132 🔗 However this seems to be a common question: https://stackoverflow.com/questions/27142359/is-a-url-with-multiple-consecutive-dots-valid Opened a separate issue: ~~https://github.com/dwyl/link/issues/6~~ done. ✅

[nelsonic]

@iteles given the work done in https://github.com/dwyl/link this feature is practically "low hanging fruit" at this point. Have you had a chance to test it over on: https://amemo.fly.dev/ ? 👩‍💻 💭

From your original Acceptance Criteria:

I've not added the underline. Because Google removed the underlines on links in 2014: https://www.theverge.com/2014/3/13/5503894/google-removes-underlined-links-site-redesign So most people are used to "blue text means link" now and don't need the underline.

But if you are keen on having the underline that's 1-line of CSS ... which you can totally add! 🎉 I know there are accessibility guidelines on this: https://webaim.org/techniques/hypertext/link_text

So happy for you to make a decision on this. ⚖️

The color change on hover is implemented: And that's also when the underline is currently applied.

https://github.com/dwyl/mvp/assets/194400/aacfa804-04eb-4f22-829d-3c1975521174

Please let us know if you feel this is already in a useful state and we will create a PR to ship it. :shipit:

[nelsonic]

Only applied priority-2 to this issue because of the many other priority-1 issues assigned to @iteles ... 💭 But didn't expect it to be ignored for 2 months ... 😢 I use links all the time in my items and would benefit from being able to click/tap on them to visit the issue/page they are linked to. 🔗

[nelsonic]

Made a couple of updates; so links are underlined and target="_blank" so they always open in new Tab: https://amemo.fly.dev