Add support to retrieve the observable events from the contracts in a given Clarinet project

[smcclellan]

From Sabby:

As a user, I want the ability to discover all observable chainhook events in a given project so I can look at the list of events and create the chainhooks easily as opposed to manually defining each predicate by reading the docs, making errors in the process, and wasting so much time.

The rest of additional context is at https://github.com/hirosystems/platform/issues/546, and I am skipping it for brevity here.

Old ticket: https://github.com/hirosystems/clarinet/issues/1034

/cc @sabbyanandan

[hugocaillard]

The Sabby, Scott, for putting together this new issue with refined scope.

@sabbyanandan So we have two ways of handling this:

Include the events in the packaged deployment plan

The platform is already using this feature. Could be useful to know the events of a deployed contract (or a contract soon to be deployed).

Get the events from the clarinet-sdk

The platform isn't using the clarinet-sdk at the moment, but it could be a really great addition. It might be easier to use for contracts that are being edited. We could even imagine implementing it in the front in the future (or now if that makes sense, even though the SDK is meant to be used in node.js and not the front end at the moment).

cc @leahjlou @MicaiahReid @lgalabru

[leahjlou]

This is going to be really cool, I feel like it could go along with @lgalabru's suggestion during our demos last week about showing an inline tooltip in the code to highlight events and provide shortcuts for creating chainhooks, similar to the function calling tooltips:

Either approach (packaged deploy plan vs clarinet-sdk) could work, but we'd probably need to do more research on the clarinet-sdk/WASM approach if we want to go that route.

In the linked issue:

This new UI will feed on the clarity-events module, which will be compiled into a WASM module, and that will be usable in the platform then

This would depend on the clarity-events module being ready to run in the browser, whereas it sounds like presently clarinet-sdk is not intended for browser use. @hugocaillard I agree that it could be a great addition -- do you know what it would take to get it ready to run in the browser?

[hugocaillard]

do you know what it would take to get it ready to run in the browser?

Probably not much, a bit of refactoring and some webpack config, it's probably something like 2 days of work, but let's say it's an implementation details.

More importantly, don't expect clarity-events to output what you need out of the box. It currently outputs a list of events per function, sometime in a weird way (for print)

Map(8) {
  'add' => [
    Map(2) {
      'event_type' => 'print',
      'print' => Map(1) { 'data_type' => Map(1) { 'type' => 'uint' } }
    },
    Map(1) { 'event_type' => 'transfer_stx_event' }
  ],
  'call-multiply' => [],
  'get-count' => [],
  'increment' => [ Map(1) { 'event_type' => 'transfer_stx_event' } ],
  'transfer-100' => [ Map(1) { 'event_type' => 'transfer_stx_event' } ],
  'withdraw' => [ Map(1) { 'event_type' => 'transfer_stx_event' } ]
}

It'll be easy enough to change that, but we need to defined what would be the ideal format for your needs. Should we include at which line this event is fired for instance?

[leahjlou]

@hugocaillard Re: including the line, it will depend on the UX we want. But yes I think including the line would be awesome and would let us do some really cool things with the UX.

[hugocaillard]

@leahjlou

it will depend on the UX we want

Could we world on the UX first and then on the implementation? Usually, I'm willing to build features on clarinet in the most flexible ways so that it can open many opportunities for the other tools that rely on clarinet. But for this one, since it's a very specific need and it's already difficult to allocate time to it, I'd like to make sure that whatever we end up doing will be used

[leahjlou]

@hugocaillard Agreed, I think that makes the most sense.

@sabbyanandan let's nail down exactly what we want for the UX on this first, so that any changes needed on the Clarinet side will work for what we need. Will MAD or Ginny be working on this one, and can we follow up with them?

[sabbyanandan]

@sabbyanandan let's nail down exactly what we want for the UX on this first, so that any changes needed on the Clarinet side will work for what we need. Will MAD or Ginny be working on this one, and can we follow up with them?

I will draw some wireframes. And we will engage with MAD afterward.

And @hugocaillard, we don't need a strict UX flow nailed to get to the bottom of getting a list of observable event streams. All we need is a list of those things for a given contract, and that is all! How you present it and where is up to you, and of course, that is the implementation detail. As far as there is an API or if it is available in the deployment manifest, anything works, but preferably whichever is the easiest lift so we can put it out there and experiment rapidly. All the said, for now, please internalize the problem stated in the description, and attempt solving it.

[leahjlou]

@sabbyanandan Earlier in the thread, Hugo was asking if we need line numbers included in the returned data. We would only need that if we want to display contextual tooltips inline with the code in the UI. We may not need completely finalized designs, but I believe that we do need a general idea of what we envision for the UX so that the Clarinet team can accomplish the task in a way that solves our need.

[hugocaillard]

not need completely finalized designs, but I believe that we do need a general idea of what we envision for the UX

💯

And the line number thing is just an example of why we need to this general idea