We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
msgpack-lite supports Custom Extension Types (Codecs). There's a project that I'd love to switch to this faster lib, but it uses a codec.
(Thanks for maintaining this fork btw!)
msgpack-lite's API for that is okay and maybe the best choice for an easy migration path, but you could also consider some class API like:
// impl exports.ToMsgPackSym = const ToMsgPackSym = Symbol("notepack.tomsgpack"); // in `_encode` if (typeof value[ToMsgPackSym] === "function") { bytes.push(value.constructor[MsgPackTypeSym], ...value[ToMsgPackSym](value)); } // usage class MyClass { static [notepack.MsgPackTypeSym] = 0x00; [notepack.ToMsgPackSym]() { return /*something*/; } [notepack.FromMsgPackSym](bytes) { return new MyClass(/*something*/); } } notepack.registerType(MyClass);
The text was updated successfully, but these errors were encountered:
Agreed. Not being able to encode basic built-ins, such as Symbol, is a big downer. Probably will have to fork our own versions to patch that in...
Symbol
Sorry, something went wrong.
No branches or pull requests
msgpack-lite supports Custom Extension Types (Codecs). There's a project that I'd love to switch to this faster lib, but it uses a codec.
(Thanks for maintaining this fork btw!)
msgpack-lite's API for that is okay and maybe the best choice for an easy migration path, but you could also consider some class API like:
The text was updated successfully, but these errors were encountered: