near / borsh-js

TypeScript/JavaScript implementation of Binary Object Representation Serializer for Hashing
Apache License 2.0
112 stars 38 forks source link

Prototype working with object-style schema #62

Closed vgrichina closed 10 months ago

vgrichina commented 1 year ago

This should allow to solve issue with multiple constructor instances in the project, which happens e.g. if you have near-api-js of 2 different versions in your project.

NOTE: This is just a proposal now, wanna know what you folks think, thanks!

volovyks commented 1 year ago

It's a long running problem, it would be awesome to solve it. I like the design, it looks simplier. I think we can make this breaking change and release new majour version, but let's hear the opinion of the main consumer - NAJ. cc @andy-haynes

vgrichina commented 1 year ago

It's a long running problem, it would be awesome to solve it. I like the design, it looks simplier. I think we can make this breaking change and release new majour version, but let's hear the opinion of the main consumer - NAJ. cc @andy-haynes

yeah, there are multiple ways to proceed here:

1) release breaking version 2) release separate package (borsh-ng or whatever) 3) adapt changes so that both schema formats are supported

I'm also thinking to get rid of BN dependency, like if we wanna provide some bigint alternative – big.js seems better

something else I'm building today is tx builder / signer outside of near-api-js (https://github.com/vgrichina/near-tx-builder/blob/main/index.js#L77)

I think if one uses either https://github.com/vgrichina/fast-near or https://github.com/vgrichina/web4 – there is not much use for other parts of near-api-js

volovyks commented 1 year ago

@vgrichina i think it's better not to have 100500 implementations, we already have borhs-ts and borsh-js. Support of old and new schemas is the best optio, not the easiest though.

About your tx-builder: new modular system is not solving your problem? Or you just want to get it faster?

vgrichina commented 1 year ago

About your tx-builder: new modular system is not solving your problem? Or you just want to get it faster?

I just want to make something super minimal that can be used together with web4 and wallets and doesn't depend on constructors. Like I don't need 90% of stuff in near-api-js in practice, I think I just gonna do fast-near REST API shim for nearcore RPC for cases when fast-near won't work.

andy-haynes commented 1 year ago

What needs to change in near-api-js to start using this? Is it just a matter of updating the package once it's published or does the transaction schema need to be updated as well?

vgrichina commented 1 year ago

What needs to change in near-api-js to start using this? Is it just a matter of updating the package once it's published or does the transaction schema need to be updated as well?

transaction schema would need to be updated as this change is not backwards compatible

users of near-api-js public API might be affected if they are parsing raw transaction data vs constructing transactions