Module System for Smart Contract and Frontend Integration

[behaviary]

Where the contract is init, we should have a mapping.

With this, the frontend API can stay the same no matter what. Long term, this mapping will be part of smart contract meta data.

@NEARModule({
   methods: ['say_hi', 'getHi'],
   mappings: {
     'say_hi':'sayHi'
   }
})

Second benefit is that this is a place where you could actually pull in other contracts. This is the place where you would compose apps. I’ll write an NEP.

[chadoh]

Would it be worth making it possible to call a smart contract function using either snake_case or camelCase, regardless of how it was written? In which library would it make sense to implement such a lookup & conversion? Would this be part of near/NEPs#3?

Would that be simpler than your proposed module system, @potatodepaulo?

[behaviary]

It could be. I think that we should rely on a convention at the end of the day. My opinion would be that you can call a function as you would expect in the environment it's invoked. This would most likely be part of meta data, yes.

…

On Wed, Feb 26, 2020 at 11:15 AM, Chad Ostrowski < ***@***.*** > wrote: Would it be worth making it possible to call a smart contract function using either snake_case or camelCase , regardless of how it was written? In which library would it make sense to implement such a lookup & conversion? Would this be part of nearprotocol/ NEPs#3 ( near/NEPs#3 ) ? Would that be simpler than your proposed module system, @ potatodepaulo ( https://github.com/potatodepaulo ) ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub ( #5?email_source=notifications&email_token=ABS6YAWPXHZ4EO4YB6WYDM3RE25WHA5CNFSM4K2P5R7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENBQE7A#issuecomment-591594108 ) , or unsubscribe ( https://github.com/notifications/unsubscribe-auth/ABS6YAQTYLMGNFDCAD7IEFDRE25WHANCNFSM4K2P5R7A ).