Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: support for links (and maybe links previews) #74

Open
giulioco opened this issue May 7, 2024 · 5 comments · May be fixed by #148
Open

Feature request: support for links (and maybe links previews) #74

giulioco opened this issue May 7, 2024 · 5 comments · May be fixed by #148
Labels
enhancement New feature or request

Comments

@giulioco
Copy link

giulioco commented May 7, 2024

Love this library 💯 would be really cool to see support for links, and for allowing to copy messages. Right now the long press just makes the "Reply" button show up.

@f3dm76 f3dm76 added the enhancement New feature or request label Jun 17, 2024
@matthewrfennell
Copy link
Contributor

I spent a little time looking at this.

One approach could be to change Message.text from a String to an AttributedString. This would let consumers pass links in a general way, also giving arbitrary styling for free.

For backwards compatibility, we could continue to offer initialisers that use String, and convert to the AttributedString directly (either providing no attributes, or using some heuristics to detect links).

I'd be interested to pick this up, would that be ok? If so, if there are any suggestions / improvements for the approach, I'd love to hear them :)

@f3dm76
Copy link
Collaborator

f3dm76 commented Feb 22, 2025

Hey @matthewrfennell, that would be most appreciated, no extra suggestions, sounds good

@matthewrfennell
Copy link
Contributor

matthewrfennell commented Mar 7, 2025

I was playing around with link previews; how does this look? This uses the built-in LPLinkView:

Image Image

One disadvantage is that we need to hardcode the preview's height in order to make this small preview (without the image).

Apple doesn't give us another way to force the small version of the preview, and the big version looks out of place and takes up too much space in the message bubble.

If the design looks ok, here is what I was thinking of implementing:

  • Above design
  • Tap action disabled in reply messages
  • In-memory cache of previews
  • ChatView builder function to enable or disable previews on a chat-wide basis
  • A reasonable, configurable limit to the number of previews (e.g. max of 4 previews per message)

Let me know if you have any other thoughts or suggestions!

@f3dm76
Copy link
Collaborator

f3dm76 commented Mar 7, 2025

Hey @matthewrfennell, looks wonderful! Hardcoding is bad, but I know what Apple is like, so I guess we don't have choice. Why do you want to disable tap on reply messages though? Tapping a link there should be ok too, or did I misunderstand that part? Everything else sounds great. Thank you so much for all your support of this library, have a marvellous day!

@matthewrfennell
Copy link
Contributor

Great, thank you!

Why do you want to disable tap on reply messages though? Tapping a link there should be ok too, or did I misunderstand that part?

My thinking was that it might confuse users if they tap a reply message (perhaps expecting it to scroll them back to the original message) and the link opens.

That said, I see attachments in reply messages are clickable, so now I think agree we should leave the tap handler there, and only remove it if we implement scrolling back to a previous message on tap.

I'll get working on it :) thanks for the feedback!

@matthewrfennell matthewrfennell linked a pull request Mar 10, 2025 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants