Closed jlubeck closed 3 years ago
Hi @jlubeck please create issue in the appropriate repo. Thank you.
Thank you @cristaloleg for moving it for me
We didn't find any issue with this library, so my guess will be that the onPreviewDataFetched
callback wasn't specified (https://docs.flyer.chat/flutter/chat-ui/advanced-usage#link-preview) which resulted in a loop, because on error this library returns empty preview data and as soon as even empty preview data is saved, preview will not be triggered again. Our design flaw was that even though this callback is optional, it is kinda required, so what we did is added additional check in the UI library to not fetch the preview if onPreviewDataFetched
is null. I assume that onPreviewDataFetched
will correctly update the messages passed to the chat (as in the example in docs), if not - this issue will appear. Chat UI v1.0.7 is released with this change, @jlubeck please check and let us know if were thinking the right way.
Hey @demchenkoalex unfortunately your assumption that onPreviewDataFetched
wasn't specified is not right... I have this method passed in there which I implemented from the getting started documentation:
void _handlePreviewDataFetched(
types.TextMessage message,
types.PreviewData previewData,
) {
final index = chatMessages
.indexWhere((element) => element.id == message.id);
final updatedMessage = chatMessages[index]
.copyWith(previewData: previewData);
WidgetsBinding.instance?.addPostFrameCallback((_) {
setState(() {
chatMessages[index] = updatedMessage;
});
});
}
I'll see if I can somehow find a way to 100% reproduce the issue...
Please try to debug to see if you actually receive something inside the _handlePreviewDataFetched
(should be a PreviewData with a link) and see if chatMessages
are actually updated. If the answer is yes to both questions we will ask you to give us a sample minimal project with this issue, because we were unable to repro this :(
Closing due to inactivity, we can come back to this later, but looks like nobody experienced this issue or reproducible example wasn't provided
Please have a look at this example: https://www.loom.com/share/3ef149cb9d77428d8812b827411b4ab6
Looks like if an error prevents the URL preview from connecting, it just tries again forever.
This is on WEB btw (haven't tried this scenario on other platforms yet)