Implement linkPreview in v2

[nicolasbraun]

Hello @demchenkoalex

I can dive a bit into it but first would like to discuss the best option to handle linkPreviews in V2.
I think we can rely on the generic chatMessageBuilder and use the bottomWidget.

We could then bascially redo what was done in V1 and use flutter_link_previewer to create the widget.
It could work as-is but flutter_link_previewer depends on flutter_chat_types so it's a bit of an useless -oudated- dependency.

Would you be ok to make flutter_link_previewer depends on chat-core, or, even better, standalone ?

Note we have a type conflic between LinkPreview in chatCore and the LinkPreview Widget

[demchenkoalex]

Hey!

Do you know how to make it standalone? I tried at first, but got the same error: LinkPreview != LinkPreview. I think we could release a new breaking version that switches to flutter_chat_core, since we can’t simply create a LinkPreview there. Or maybe we can map it somehow?

Also, that package currently contains the entire "message" UI. But now, considering that people will most likely use GptMarkdown, it doesn’t really make sense for that package to handle the UI. Maybe it could just resolve the link, and then flutter_chat_ui could manage the rendering?

We could probably create a shared LinkPreview widget and use it in both SimpleTextMessage and FlyerChatTextMessage.

[nicolasbraun]

Hi alex,

Not sure what you mean by

people will most likely use GptMarkdown,
To render the preview?

I think maybe the flutter_link_previewer could only

• expose method to get the data, either as a flutter_chat_core's LinkPreview or if we wanna make it standalone as another class and user can do the mapping in their app
• Optionaly propose a widget to render it.

Then in our apps we can

• fetch the preview (whenever we want: before sending is great, but also upon receiving message if we do not want to commit to repo the LinkPreview)
• display it user bottomWidget in the generic chatMessageBuilder (which can become quite big with avatars + preview + whatever but that's his job. Or if you prefer yeah you could add a bottomWidget to SimpleTextMessage / FlyerChatTextMessage

[demchenkoalex]

Exactly what you said - I meant that before LinkPreview provided the whole message widget, but now we have SimpleTextMessage or FlyerChatTextMessage (which uses GptMarkdown) - and I don't want to override that with LinkPreview.

So, to solve this, we must do exactly as you say - that package handles the preview fetch logic, and UI is here.

[nicolasbraun]

Nice, I may have a little bit of time on Friday / beginning of next week. Let me know if you want me to look at it.

[nicolasbraun]

@demchenkoalex I gave it a first try.

LinkPreview in chat_core is missing imageWidth and imageHeight compared to v1.
OK to add it ?

Also I was think of renaming the widget LinkPreview to LinkPreviewWidget (or we can rename LinkPreview in chat_core to LinkPreviewData). This avoid using chatcore.LinkPreview everywhere for readability.

[demchenkoalex]

OK to add. LinkPreviewData is ok as well.

[nicolasbraun]

@demchenkoalex hello

Close to submitting a PR but wanted your takes on a point.
Currently when receiving a Message we have no way of knowing if linkPreviewData was not fetched or if there was no link in the message's text.
This could end up to every user tryign to fetch previewData, for nothing.

• Option1: the easiest one but a but "weird" when link_previewer is not used within the chat => make the link property optional => message will have a "empty" previewData.
• Option2: add a prop previewDataFetched - bool - on Message

Any preference ?

[demchenkoalex]

we can use metadata field and store isPreviewDataFetched there - I do something similar with isOnlyEmoji - to not grow message type unnecessarily for those who does not use those features.

[nicolasbraun]

@demchenkoalex almost there.

I think most of us will want to render the preview within the bubble of the TextMessage.
So I was thinking of adding a bottomWidget to FlyerChatTextMessage which appears in the bubble compared to bottomWidget of ChatMessage.

That said most of us will also want to have the nicest UI as possible, a bit like in the example =>

To achieve this i made changes in FlyerChatTextMessage, wrapping the current Container into a new one.

return Container(
      decoration:
          _isOnlyEmoji
              ? null
              : BoxDecoration(
                color: backgroundColor,
                borderRadius: borderRadius ?? theme.shape,
              ),
      child: Column(
        mainAxisSize: MainAxisSize.min,
        crossAxisAlignment: CrossAxisAlignment.start,
        children: [
          Container(
            padding:
                _isOnlyEmoji
                    ? EdgeInsets.symmetric(
                      horizontal: (padding?.horizontal ?? 0) / 2,
                      vertical: 0,
                    )
                    : padding,
            child: _buildContentBasedOnPosition(
              context: context,
              textContent: textContent,
              timeAndStatus: timeAndStatus,
              paragraphStyle: paragraphStyle,
            ),
          ),
          if (bottomWidget != null) bottomWidget!,
        ],
      ),
    );

and I can use it like this

textMessageBuilder: (context, message, index) {
          Widget? linkPreview;
          final metadataLinkPreviewFetchedKey = 'linkPreviewDataFetched';
          final isLinkPreviewDataFetched =
              message.metadata?.containsKey(metadataLinkPreviewFetchedKey) ??
                  false;

          if (message.linkPreviewData != null || !isLinkPreviewDataFetched) {
            linkPreview = ClipRRect(
              borderRadius: ChatTheme.dark().shape,
              child: Column(
                children: [
                  Divider(height: 0.5),
                  LinkPreview(
                    text: message.text,
                    width: double.infinity,
                    linkPreviewData: message.linkPreviewData,
                    hideDescription: false,
                    hideTitle: false,
                    linkStyle: TextStyle().copyWith(color: Colors.white),
                    openOnPreviewImageTap: true,
                    openOnPreviewTitleTap: true,
                    onLinkPreviewDataFetched: (linkPreviewData) {
                      _controller?.updateMessage(
                        message,
                        message.copyWith(
                          metadata: {
                            ...message.metadata ?? {},
                            metadataLinkPreviewFetchedKey: true,
                          },
                          linkPreviewData: linkPreviewData,
                        ),
                      );
                    },
                  ),
                ],
              ),
            );
          }
          return FlyerChatTextMessage(
            message: message,
            index: index,
            bottomWidget: linkPreview,
          );
        },

What results in

This look good but before making the PR, do you have any better idea?
Seems "complicated" for the client (has to retrieve the bubble shape from Theme for example) but I did not wanted to add the ClipRect to FlyerChatMessage (would you be ok with it ?)

[demchenkoalex]

Yep, I’d include it in the message as well. I was actually thinking about making this more “automatic.”

Instead of a generic bottomWidget, we could build link preview support directly into FlyerChatTextMessage and SimpleTextMessage, and add a flag like isLinkPreviewEnabled to toggle it.

Similar to how we handle ScrollToBottom, IsTyping, or LoadMore, we’d introduce a LinkPreview widget with a linkPreviewBuilder to customize its appearance. This LinkPreview would then be displayed at the bottom of both FlyerChatTextMessage and SimpleTextMessage.

[nicolasbraun]

Cool, I agreee this is something most will want ! I'll propose something today 🚀

[nicolasbraun]

Du you want to make the link_previewer a package in this monorepo?

[demchenkoalex]

We can move it here so everything is in one place - it’ll probably be easier to debug and develop that way. We’ll just keep the same name to publish it to the same pub package.