Simplify/update fxparam deserializers & boilerplate #26
Conversation
- update fxparam deserializers & utils as per postspectacular/fxlens@7d0a50b
- replace remaining single quote occurrences w/ double quotes - remove remaining semicolons
* upstream/master: removed iteration number injection add minter & iteration number add version; deprecate old events for single getInfo event add 2nd long string comment fx preview event dispatch remove dislcaimer allow user defined max length
- add rndHash() & matcher() helpers - improve internal re-use for fxhash & fxminter init
- undoing previous megabrain blooper
|
@postspectacular man, thank you so much for your input and your thorough improvements, we are really grateful for the time you spend with our implementation 💘
you are exactly right. all chars are encoded into 4 bytes ultimately resulting in bytelength times two. wasn't a masterpiece xD we are going to checkout your improvements in the upcoming days and do some test with existing tokens etc on our end, so we can integrate these improvements soon! much love and appreciation from the whole fx(hash) team!!! |
maerzhase
changed the base branch from
feature/data-emission
to
feature/serialisation-improvements
maerzhase
changed the base branch from
feature/serialisation-improvements
to
feature/data-emission
|
couldn't push on your branch. changes are incorporated in fxhash/fxlens#22 |
Fix local builds aka update dependencies
This is a companion PR for fxhash/fxlens#18 reflecting the same updates as done in there (plus some additional minor refactoring)...
The original incentive here was to reduce file size (currently 20% smaller), but not doing so for "size coding" reasons, but to simplify and improve internal re-use (incl. the fixes mentioned in the other PR).
There's one thing I'm unsure about, both here and in the other PR: I don't understand why your
byteLength()method for strings always returns the value-times-two. My hunch is that this was your attempt to address the fact that some unicode chars require multiple bytes and so that factor 2 acts as a reserve. If that's the case, then I think that new route usingTextEncoderdoesn't require it that double size anymore. Also in my extensive testing with the updated fxlens I couldn't find any issues (yet)... But maybe I'm misunderstanding...Anyhow, hope these are useful & acceptable updates! Happy to make further changes if needed...