xrplf / xrpl-hooks-ide Goto Github PK

Design details defined in: #22

• #48
• Enable test tab name editing (needs design) [nice to have thingie]

• Display feedback from static analysis inline (code)
• Display feedback in console log (reference line number)

To start with, we can implement either, or both depending on the complexity of the implementations.

Just like in the editor area, but reusable enough to be used for various use cases like in test page, etc.

• Setup NextJS for the project
• Setup basic project styles & needed style component frameworks

Currently the client uses workspace at /tmp/c , and server puts project header files there (they must be on disk). For this setup, the /tmp location is problematic: it's auto-cleaned on development desktops after every reboot and occasionally even inside the xrpl-hooks-compile docker image. It should be changed to /work/c .

You can create new faucet accounts by making POST calls to https://hooks-testnet.xrpl-labs.com/newcreds. That endpoint is now throttled so that you can only make 1 request / 10 seconds. We need to ask Xrpl Labs to disable throttling from certain IP addresses so that we can call endpoint as many times as possible.

• Download open C-files (if multiple files supported)
• Download test.json files (?)

TODO:

• Specify what the download archive should contain

Current status:

• We focus on using https://xrpl-hooks.readme.io/ (domain may change, lets parameterize it) as the end point, opening the documentation links in new windows.
• Exploring displaying readme.md as rendered markdown in a tab (can be switched between markdown / rendered, rendered being the default?)
• Show diagnostic documentation on the right hand side (from clang-tidy), when clicking "Read more" from the language server pop-up. These mini docs can also contain links to the XRPL Hooks Documentation that will open in a new window.

We should make header files, at least hookapi.h, maybe all of them read only. You shouldn't be able to modify them since they are included on the compile server.

These files at least should be read only if included in gist:

• hookapi.h
• sfcodes.h
• hookmacro.h

• Save current Hook C-file locally
• Save created account hash & key pairs locally

NOTE: localStorage saving of secrets is not something we can do in production version of the Editor, and we probably need the cloud saving and encrypting the keys.

At the moment when we're deploying a hook we are signing and sending following transaction

const tx = {
      Account: account.address,
      TransactionType: "SetHook",
      CreateCode: arrayBufferToHex(
        state.files?.[state.active]?.compiledContent
      ).toUpperCase(),
      HookOn: "0000000000000000",
      Sequence: account.sequence,
      Fee: "1000",
};

Now we're using hard coded HookOn value but it should be user defined. My initial idea is that when user clicks the deploy button a modal window opens where user can select on which transactions the hook will trigger:

Documentation how to calculate HookOn values

• https://github.com/XRPL-Labs/xrpld-hooks/#sfhookon (How to calculate HookOn value)
• https://github.com/ripple/rippled/blob/89766c5f218e49f038e30aee05c1be9216f78bf5/src/ripple/protocol/TxFormats.h#L59 (TxFormats)

Later on when the hook deployment will be "parameterized" the same modal would be useful. User could define for example the savings account address or the percentage of savings hook.

Initial idea for the UI:

in response to various commands - for example, after selecting a hook library function name, the user can right-click to open a local menu with a command Peek Definition (in Peek group). Executing it leads to an error popup:

Apparently it also breaks code parsing:

The hook file continues after the call but does not show...

• #24

For example, executing "View Problem" on an empty source file complains about 25 problems:

In fact, there are 2, and the count is actually fixed by executing "Go to Next Problem":

• It should warn of duplicate filename.
• If file extension is not provided, it should apply default extension.
• Maybe warn of unsupported file extension??

• User can select a "blank template (with essential imports) or a Hook template to edit
• Selection is done when using the editor for the first time, or when clicking the "plus" sign next to files

Errors are unhandled and seen in console only.

Say Ctrl+Alt+N for new file, Ctrl+Shift+C to compile and so on. Probably a backlog as shortcuts needs to be discussed and shortcuts collision to be avoided.

• Show the size of the compiled WASM file and a profiling the size (red, orange, green)
• Enable showing the WASM as WAT file optional

TODO:
We need to specify the profiling specifications for WASM file with XRPL Labs (what is small, what is average, what is large)

• #12
• #13

User should be able to delete hooks from account. Things to consider:

• Deleting current hook (the one you have just deployed or written yourself)?
• Deleting hooks you've added earlier, how to delete some other hook that isn't the one you're about to deploy?
• How does the UI flow go in these cases?

For example View Problem (Alt-F8) doesn't work on Ubuntu (Windows key has to be used instead) nor on Mac (requires Fn key). They should be replaced with something that works as advertised, ideally something standartised.

• #14
• #27

For example on an empty source file, the first missing entry points error fits right over the editor pane border, which shows through, giving the appearance of crossing the error out:

Confused me for a long time, what the difference between the first and second error is...

• Show transaction ID -> Link to block explorer (f.e. https://hooks-testnet-explorer.xrpl-labs.com/tx/1C21488C023317365F72F148BB6FE1014EF05D5136E8CEC566FD07B52D8A083D) which opens in a new window.

• #15
• #18
• #20

• Enable user to create a faucet account (or multiple)
• Enable user to see information of the account in a modal window (hash, balance, secret)
• Assign a unique (random) name for each account
• Create a faucet account when starting the editor, if there is none (or guide the user to do this manually in the wallet window)

Account window:

Account information:

like /filename.c. It isn't clear how that's converted into workspace URL, but even in case it's successfully passed to Language Server, it shouldn't be - Language Server shouldn't operate on user-specified absolute paths... File names should stay in the workspace directory, IOW not contain '/'.

• User should to be able to fetch correct files from Github Gists (if those are public)
• User should be able to save files to Github Gist and share link to other users

This is confusing after a user fixes a compilation error, which stays in the log:

For better feedback (and to behave analogically to other C/C++ IDEs), the log should be cleared before every compilation.

• Have a dropdown to select the account, and subscribe to its debug stream.
• design concept of the debug stream with @jonijuup
• #104
• #105
• Clickable stuff in logs, like accounts and maybe transactions.

Currently, Hooks Editor constructs source file URLs (used by the Monaco editor & Language Server Protocol) by interpolating file names into file://work/c/${file.name}, producing URLs where work should be interpreted as authority (per RFC 8089). This is (theoretically) incompatible with the Language Server, which expects the source files in its local /work/c directory (IOW interprets work as part of the absolute path) and works in practice only because the clangd Language Server parses URLs of the form file://work/c/filename.c (the least used & most obscure format specified by RFC 8089) incorrectly. The URL construction string should be changed to file:///work/c/${file.name}, producing correct URLs parsed the same way by both client & server.

The change described above had already been proposed (in b2c6aa7 ), but rolled back (in d85cc71 ) because it broke Wasm compilation. The cause of that problem was the IDE failing to identify the source file in comparing editorModel.uri.path against /c/${state.files[state.active].name} - when the path includes work, the comparison fails and the IDE sends an empty source to the compilation service, which produces non-empty but invalid Wasm from it. This must be fixed together with changing the URL format.

• Send compiled WASM file to selected XRPL account
• Display response in the deploy section console

because it's possible (indeed desirable) that a user looking at an error will fix it, in which case the displayed error message becomes outdated:

Ideally, the error list could be updated and the inset removed iff the new list is empty, but since the list arrives asynchronously from the Language Server, that's probably non-trivial to implement.

• Dark theme
• Light theme
• Add C language highlight for the editor
• Add theme switch button to UI

After typing filename, Enter key should create file directly.

• #17
• #19

• Enable multiple different tests
• Predefined tests (?)
• Could tests be configured in the Hook itself, on some level?
• Bundling relevant tests with example Hooks (how?)

• Build basic UI theme with Stitches
• Build generic components (Buttons, Headers, Links, Icons)

• #21

• Find React version of Monaco editor
• Start using it

• #2
• #3
• #5

Ability to view and edit transactions as json.

Basic development log component which shows (probably) both, language server errors and compile errors.

We need to implement Github login so we can store the project files on Github Gist. We should probably use something like next-auth for this.

We need to build language server which supports C language so that we can show proper errors and warnings before compiling code.

The UI / concept.
More info on #22

Unfilled:

Filled:

The basic idea:

1. User selects the transaction type, and other fields are populated based on that (we can start with just ttPayment for first testing version now, but a ready feature should have all the transaction types)
2. After user has filled the fields and selected the "to" and "from" account, you can make a test transaction and see a log from both accounts what happened and did the hook trigger as it should've triggered.

• Additional feature would be to add other "tests" using the "+"-button, but we can start with having a one test and add the multiple test setup later
• We can use the same (or similar) account component as we're using in the "deploy" section (adding accounts, looking information of an account in modal)