QUESTION: how to get the string from the encode function about js-multibase

[rvagg]

I think you're running into the problem of not having a 'hex' serializer for Uint8Arrays - in the previous version we exported Buffer objects which can do a native toString('hex'), now we export a Uint8Array which has a subset of the Buffer functionality (which is just a wrapper around Uint8Array). This is all done because it means browser users don't need to pull in the entire Buffer` polyfill if they don't want - at least this library won't for you to do that.

What you can do, if you're on Node or want to pull in that polyfill is pass it through Buffer: Buffer.from(buf).toString('hex') and you'll get the polyfill. Or you could pull in a light polyfill for this purpose, such as uint8arrays which has a toString() method that will do most of the things Buffer#toString() will do: https://github.com/achingbrain/uint8arrays#tostringarray-encoding--utf8:

const toString = require('uint8arrays/from-string')
toString(buf, 'base16')

Or roll your own if perf isn't a high priority, such as this one-liner: https://github.com/multiformats/js-multiformats/blob/b0eca3c1384abd22afa2cdf7e37c63468c535001/src/bytes.js#L1

[woss]

gotcha!

so you took away the functionality from the multibase and offloaded this to the users of the lib.

not sure do i agree with that though I would if that would bring the package smaller size and speed but based on this it doesn't.

I use CID extensively and build on top of it and multi* and now i have 2 diff versions of multibase, 3 that comes with new CID and 1 that i use independently. you can totally say why am i complaining since it is a major version change, i wouldn't if you were so kind to make migration doc ( maybe you have it, in that case put it in obvious place , top of readme file ) and add more example, not EVERYONE will multibase the text.

[vmx]

not sure do i agree with that though I would if that would bring the package smaller size and speed but based on this it doesn't.

The breaking change was a step towards a smaller bundle size. Next step (a non-breaking change) is getting also the Buffer dependency removed from other dependencies. This work happens at #64. Once that is merged, the bundle size will be smaller.

[woss]

thanks for clearing that out. but why did you ditch the functionality toString() just because of the size?

[vmx]

but why did you ditch the functionality toString() just because of the size?

The reason wasn't size. The reason is that we want the JS libraries to be Browser first libraries that don't use Node.js APIs that need to be polyfilled. Removing the dependency on Buffer is a step into that direction.

toString() wasn't really multibase functionality, but one of Node.js Buffer.

[woss]

yes that's true, now it makes sense for the browsers, but this breaks the nodejs. here is the runkit where i made 2 examples, browser and node, based on the readme and what was written in the comments.

i know people are compiling the packages for bot the node and browser, couldn't you guys do the same?

[vmx]

yes that's true, now it makes sense for the browsers, but this breaks the nodejs

How does it break in Node.js? I know in Node.js it's common to use Buffer, but even there you could just use Uint8Array directly.

From your example it has the exact same behaviour in the Browser and on Node.js. And if you want to have the toString('hex') functionality, you can wrap it in Buffer.from(), just as you did.

If you do a Browser based application, you could also load the Buffer polyfill yourself to get that functionality.

i know people are compiling the packages for bot the node and browser, couldn't you guys do the same?

We do compile for the Browser, but we don't want to have a large Polyfills in there for stuff that can be done without.

[woss]

Thanks @vmx for patient explanation. i need to familiar myself more on this topic Uint8Array Buffers and differences in the Browser and Node approach. I still don't understand FULLY but i will check the code when i have time, maybe then i can get the proper grasp of the problem.

Also if you don't mind checking that example i sent earlier and see what am i doing wrong when changing the base.

[vmx]

Do you mean the runkit example? I don't understand what you mean with "changing the base".

[woss]

yes, there is a comment on the line where the

const baseEnc = 'base32' // how come base58btc shows correct decoded bytes? try to change the baseEnc

is defined

When i have the const baseEnc = 'base32' the decode function returns the bytearray string, and when i have const baseEnc = 'base58btc' it returns the string that was passed in the TextEncoder.

[vmx]

That's due to #64. Once fixed, it will always return a Uint8Array instead of a Node.js Buffer.

[woss]

aha, many thanks!