Conversation
|
Hi @Ry-DS ! Thanks a lot for the PR.
Based on https://github.com/tommoor/react-emoji-render/blob/master/src/renderer.js#L76, if we have the github aliases in our dataset, we should not have that issue. I understand this is an edge case as Github emojis are not part of the unicode standard and we can't really have entries in that file without a matching unicode emoji, but I think your |
|
@Ry-DS any chance you pull this off to an end ? |
|
@enzoferey hey! Thanks for the reminder. I did a quick commit which I think fixes it, definitely take a look and confirm if you think its an ok solution. If so, I plan to polish it up with comments later today and it should be g2g. |
|
@enzoferey just bumping this, let me know if you need anything else from my end (I should be a little more active to any requests this and next month) :) |
|
Hey @Ry-DS , thanks for the follow up, this is far from a priority for me 😅 Reading again the comments above and your code, I had something very specific in mind that should reduce the complexity of the chances introduced and enable future similar use cases to integrate in the same way. Quoting my previous message:
So far you have changed a lot about how the replacing and rendering algorithms work, but I think just introducing a single check on the Also, we are introducing a lot of useless tests on the different vendors that only affect the Github component, we should improve that don't you think so ? |
Closes #67


Works well for most cases:
How the customAliases were found:
Issues:

Solved!:octocat:doesn't work because:oturns to :open_mouth. There are some more emojis like this. Let me know if you have a good solution to this...