Skip to content

docs(js-sdk): complete encryptInput reference — positional signature + supported types (NOXFB-13) - #78

Open
edenbd1 wants to merge 3 commits into
mainfrom
docs/noxfb-13-encryptinput-reference
Open

docs(js-sdk): complete encryptInput reference — positional signature + supported types (NOXFB-13)#78
edenbd1 wants to merge 3 commits into
mainfrom
docs/noxfb-13-encryptinput-reference

Conversation

@edenbd1

@edenbd1 edenbd1 commented Jun 1, 2026

Copy link
Copy Markdown
Contributor

NOXFB-13 — encryptInput: référence complète manquante (signature + types solidityType)

Strongest signal of the Vibe Coding Challenge 2026 hackathon batch (7+ teams hit the signature, ~50% hit the types). Doc-only.

All facts verified against the SDK source (@iexec-nox/handle@0.1.0-beta.11, src/methods/encryptInput.ts).

Changes

references/js-sdk/methods/encryptInput.md

  • Add a Signature section + a prominent callout: the 3 arguments (value, solidityType, applicationContract) are positional, not an options object (✅/❌ examples).
  • List the 5 supported solidityType (bool, uint16, uint256, int16, int256) in a table.
  • Danger callout enumerating the unsupported types (address, bytes32, uint8/32/64/128, string, …) that throw a TypeError before any network call, with the real error message and the reason (the Nox Runner allow-list — not the SDK).
  • Document the exported SolidityType type and how to type variables with it.
  • Document the handleProof return type as a 137-byte (0x + 274 hex) string.
  • Replace every example that used an unsupported type (address, uint64, string) — no official snippet uses an invalid type anymore.

references/js-sdk/getting-started.md

  • Add a complete encrypt → decrypt example showing the positional call and destructured return.

Acceptance criteria

  • Full signature with TypeScript types
  • Return { handle, handleProof } documented (handleProof = 137-byte 0x HexString)
  • Exhaustive list of the 5 supported types
  • Explicitly states which types are NOT supported
  • import { SolidityType } from '@iexec-nox/handle' documented
  • Getting-started has a complete correct snippet with destructured return
  • No official example uses a type outside the 5
  • A new dev can pick a valid type without reading the sources

Validation

prettier --check ✅ · full vitepress build (type-checks every twoslash block) ✅

Refs: NOXFB-13 · absorbs NOXFB-24 · related NOXFB-22 / NOXFB-23

…ed types)

Document the full encryptInput signature and remove the ambiguity that
blocked hackathon builders:

- Add a Signature section and a prominent callout that the three arguments
  (value, solidityType, applicationContract) are positional, not an options
  object.
- List the five supported solidityType values (bool, uint16, uint256, int16,
  int256) in a table, and add a danger callout enumerating unsupported types
  (address, bytes32, uint8/32/64/128, string, ...) that throw before any
  network call, with the reason (Nox Runner allow-list).
- Document the SolidityType export and how to type variables with it.
- Document the handleProof return type as a 137-byte (0x + 274 hex) string.
- Replace examples that used unsupported types (address, uint64, string) with
  supported ones so no official snippet uses an invalid type.
- Add a complete encrypt -> decrypt example to the JS SDK getting-started.
Copilot AI review requested due to automatic review settings June 1, 2026 10:04
@vercel

vercel Bot commented Jun 1, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
nox-documentation Ready Ready Preview, Comment Jul 6, 2026 7:27am

Request Review

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Doc-only update to the Nox JS SDK documentation to make handleClient.encryptInput usage unambiguous (positional args) and to document the runtime allow-list of supported solidityType values so developers can pick valid types without reading the SDK source.

Changes:

  • Added an explicit encryptInput signature section and a callout clarifying the 3 positional arguments (and showing ✅/❌ examples).
  • Documented the 5 supported solidityType values and clarified that other types fail fast with a TypeError before any network call.
  • Added a complete “encrypt → decrypt” snippet to Getting Started that uses positional args and destructured return values.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 6 comments.

File Description
src/references/js-sdk/methods/encryptInput.md Adds signature + positional-args warning; documents supported/unsupported solidityType values and handleProof shape.
src/references/js-sdk/getting-started.md Adds an end-to-end encrypt→decrypt example using the correct positional call and destructuring.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +16 to +20
encryptInput(
value: boolean | bigint,
solidityType: SolidityType,
applicationContract: string // 0x-prefixed Ethereum address
): Promise<{ handle: Handle<T>; handleProof: `0x${string}` }>;
Comment on lines +169 to +170
Passing one throws synchronously:

and helpers instead of hard-coding string literals:

```ts twoslash
import { type SolidityType } from '@iexec-nox/handle';
Comment on lines +16 to +20
encryptInput(
value: boolean | bigint,
solidityType: SolidityType,
applicationContract: string // 0x-prefixed Ethereum address
): Promise<{ handle: Handle<T>; handleProof: `0x${string}` }>;
Comment on lines +169 to +170
Passing one throws synchronously:

and helpers instead of hard-coding string literals:

```ts twoslash
import { type SolidityType } from '@iexec-nox/handle';
Resolves conflict in encryptInput.md: keeps both the fromExternal
cross-link (this branch) and the concurrent encryption section
added by #88 on main, back to back.
Follow-up merge: local clone's origin/main tracking ref was stale
and missed #90 (isAllowed → viewACL cross-reference), merged into
main after #88. No conflict — different file.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants