Comments (9)
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
from clarinet.
@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.
from clarinet.
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
from clarinet.
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?
from clarinet.
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?
from clarinet.
@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.
from clarinet.
@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?
from clarinet.
@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.
from clarinet.
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
from clarinet.
Related Issues (20)
- Support unit tests written in Clarity - `#[test]` HOT 2
- Use Stacks node v2.5 for the local testnet HOT 2
- calling `getMapEntry` in Clarinet SDK for non-existent entry returns error instead of `Cl.none` HOT 3
- Can't find variable `simnet` when running tests using `bun test` HOT 3
- Deployment plan misses dependency HOT 3
- Doubling down on security analysis HOT 2
- Handle Clarity 3 HOT 1
- Consolidate regtest and devnet functionality
- Generate a typescript client lib for contracts
- unable to trigger deployment error HOT 6
- How to pass in the default.testnet-plan.yaml - list 5 (optional principal) parameter HOT 2
- Creating a new Clarinet project in the local folder breaks devnet HOT 1
- Add electrs docker container to devnet start HOT 1
- Add advance_stacks_tip and advance_burnchain_tip in simnet
- create `clarinet platform` commands HOT 2
- running clarinet in the background HOT 3
- Mainnet Execution Simulation HOT 7
- Include tx cost in transaction receipts HOT 1
- Make it available for NixOS HOT 3
- Update devnet to work with sBTC HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from clarinet.