Proposal: change entrypoint for Hook & Callback to export & add context

[WietseWind]

Currently a JS Hook looks like defined below, where Hook and Callback are defined as a non exported Function:

const Hook = () => {
 ///
}

const Callback = () => {
  ///
}

For the sake of preventing compilers to tree shake the entire function, in reality they have to be exported, but then the export makes QuickJS currently fall over.

Request 1

Pick up the Hook from a module exported function, so make this work:

export const Hook = () => {
 ///
}

export const Callback = () => {
  ///
}

Request 2

Then I'd like to throw in the triggering TX object, always, and take the compute for granted (as most JS devs will want to do something with the incoming TX anyway. To prevent them from always having to call the otxn_json anyway, I propose that JS Hooks both Hook and Callback get the triggering TX otxn_json as argument, always, and move the current args to the second arg.

export const Hook = (tx, reservedNumber) => {
 ///
}

export const Callback = (tx, emittedTxErrorNumber) => {
  ///
}

Here's an example Hook as I would like to work (if it works, it will trace the triggering TX JSON):

export const Hook = (tx, code) => {
  trace('triggertxjson', tx)
  trace('code', code || 'none')
  
  return accept('Sample Hook (End of Hook)', 123)
}

export const Callback = (tx, emittedtxerror) => {
  trace('triggertxjson', tx)
  trace('emittedtxerror', emittedtxerror || 'none')

  return accept('Sample Hook (End of Callback)', 1337)
}

[RichardAH]

To keep it consistent as possible with wasm hooks, how about we make the tx object a second optional parameter to the function?
hook(code, tx?)

[WietseWind]

Yeah that works too :) It's not really about the order of the params but more the fact that they have it at their disposal instead of having to separately call to fetch it.