Closed Gozala closed 5 years ago
I actually designed it so that this wasn’t locked in.
https://github.com/ipld/js-ipld-stack/blob/master/src/codec-interface.js#L86
Since the codec interface’s reader()
method takes a block and returns the Reader() interface you could replace this default with one that did partial decoding. You don’t pass in a fully decoded object, you pass in the block instance which lazily computes the decode, we just implement a default Reader() interface that uses a full decoding, but you could return a different implementation that did partial decoding and if you never call block.decode()
you will never end up doing a full decode.
Let me know if this will work for the use cases you’re thinking of so that I know if we can close this issue :)
Alright I understand now. I think it might be worth clarifying in the readme. Let's keep it open for now I'll propose specific changes.
Ya, this is something we should document extensively when the codec-interface
migrates to its own repo. Right now I only documented the basics of the interface but we should document it more from the point of view of an implementor when it migrates.
Closing this as it seems possible through Reader
API.
Codec interface as it stands now still assumes that full block must be decoded to to access arbitrary field.
I would very much prefer to not bake that assumption into the interface because some formats can like flatbuffer allow you to decode individual fields of the record without having to decode unnecessary bits. We have discussed this in a greater degree here https://github.com/ipld/interface-ipld-format/pull/50