search

Fintasys / emoji_picker_flutter

A Flutter package that provides an Emoji picker widget with 1500+ emojis in 8 categories.
MIT License
155 stars 114 forks source link

Improvement: 'Replace emoji on limit exceed' config parameter #70

Closed PankovSerge closed 2 years ago

PankovSerge commented 2 years ago

With the current implementation, when recents limit exceeds, even if new emojis (out of existing list) are selected multiple times, recents list will stay the same.

Current PR provides the ability to replace the latest emoji with the fresh one. For backward compatibility new flag set of default false value.

  1. Added 'replaceEmojiOnLimitExceed' config parameter & implementation on picker internal utils
  2. Added parameter & description to README.md
Fintasys commented 2 years ago

@PankovSerge Thanks for your contribution! Because of your PR I checked behavior in Whatsapp and realized that their way of handling recent emoji eventually makes more sense. Regardless of the amount an emoji was used the latest emoji will be at the front of the list. Therefore the issue, which you try to fix here would be non existent. I see 2 possible actions to proceed from here (1) - We continue with your fix (eventually remove the config parameter and force the replacement of the last emoji by default) (2) - You or me gonna make another PR and adjust the recent emoji behavior similar to Whatsapp's behavior and get rid of the issue that way.

Would love to hear your opinion on that !

PankovSerge commented 2 years ago

@Fintasys right now the current naming of tab 'recents' is not correct, in my opinion - it's list of most popular emojis, sorted by use count, and i was confused at the very beginning, why latest emoji not appears in first place :).

And you're completely correct, that it's different approaches, how to operate with 'recents' and 'frequently used'. Current implementation similar to Slack, iOS emoji keyboard and subjectively it's good for out-of box history logic.

It would be nice to stick with this approach (at least for now) and provide ability for the community to use their own implementation by sharing a contract for 'history' metamorphoses. It will provide a way to use different storages for history, and any sort / filter options, which will fit input requirements.