Improve the structure of PostReaction

[RiccardoM]

Context

Currently in order to represent a single post reaction, what we are doing is using this object:

// PostReaction is a struct of a user reaction to a post
type PostReaction struct {
  Owner sdk.AccAddress `json:"owner" yaml:"owner"` // Creator that has created the reaction
  Value string         `json:"value" yaml:"value"` // Value of the reaction, either an emoji or a shortcode
}

This is used also inside the GenesisData to represent all the reactions that have been added to the different posts.

Using this object from an outsider point of view, it is not enough in specific cases. Particularly, I've found some difficulties when handling it inside the genesis from within DJuno. Since the Value field can contain either the reaction shortocode or emoji value, it's hard to parse them and store them inside the database.

Solution

In order to solve the above mentioned problem I propose a revisit of this data type, in order to extend it so that it includes both the shortcode and the value of the emoji:

// PostReaction is a struct of a user reaction to a post
type PostReaction struct {
  Owner sdk.AccAddress `json:"owner" yaml:"owner"` // Creator that has created the reaction
  Shortcode string     `json:"shortcode" yaml:"shortcode"` // Shortcode of the reaction
  Value string         `json:"value" yaml:"value"` // Value of the reaction, either an emoji or an URI
}

Notes

I acknowledge that this approach comes with a con, which is the fact that emoji values and registered emojis will occupy a lot more storage than the current version due to the fact that their shortcode will be stored multiple times.

While this might be a problem, supposing we have all reactions with shortcodes that are 20 characters long (equivalent of 160 bytes, which is a very long shortcode to be honest), it would mean that in order to have a significant disk space change (1GB) we would have to have at least 6,250,000 reactions used. Personally I think that 1GB for 6 millions reactions is fair as long as that change allows for a better usage from the developer perspective.

[leobragaz]

The change you suggest is good and I think that, if we do this to help for a better integration with middle-layers like Djuno, 1GB will not change our lives.
Also, these changes would not be so problematic for the whole codebase.

[kwunyeung]

It's already another story for Desmos when there are 6m reactions 😄. Performance and data integrity is at higher priority than storage.