Action keys are undefined if a certain action never occured for a particular token. Currently ecash-herald overwrites undefined keys that we use for sorting logic with default zero values.
However, we could improve the sorting and msg building logic to handle undefined keys.
It is a bit of an open question whether it would be more performant to give every token default values (many if not most are not expected to have most keys) or use this nullish coalescing in the sort. Would have to test both with many mocks and do some time checks.
For now, I think this is the best solution as
- The type API is simple to undertand. If we don't have a key, we don't have that action
- Most tokens will not have most actions
- Running the script locally to send test msgs using 24 hrs of real data, I can't discern any speed impact
It could be something to look into as an optimization problem down the line, but I do not see a good deal of impact from getting into it now.