@wagmi/svelte

[ByteAtATime]

This draft PR is a WIP implementation of reactive Wagmi hooks in Svelte.

Notes

Reactivity

In order to make return types reactive, I have opted to return a function. It's the function that then returns the value. While it is a little unintuitive, it works perfectly with $derived.by:

const { data, isLoading } = $derived.by(useEnsName(...));

Design consideration: should we use React-style .current instead of returning a function?

Why?

Unfortunately, simply returning a primitive from a function doesn't make it reactive. The workaround is to return an object with a getter:

const reactiveReturn = () => {
  // ... do stuff

  return {
    get count() {
      return count;
    }
  }
}

However, I find this a little ugly when used, especially because it cannot be destructured:

const countObj = reactiveReturn();
countObj.count // repetitive?

---

Similarly, a similar problem occurs with parameters: if a reactive object is directly passed into a function, it won't be reactive:

let counter = $state(69);
const output = useCounter(counter);
                       // ^ State referenced in its own scope will never update. Did you mean to reference it inside a closure?

Happily, this isn't the only framework that has this problem (SolidJS shares a similar problem). In both frameworks, the workaround is to simply pass in a function as a parameter:

let reactiveAddress = $state("0x...");
$derived.by(useEnsName(() => ({ address: reactiveAddress })));

Design consideration: In the RuneParameters type, I have defined it as (() => T) | T. In other words, it accepts either a reactive function or a non-reactive object. Will this lead to confusion?
Edit: Now we can only pass in a function. This makes it easier to compose types and reduces confusion for users.

Design consideration: should the return types and parameters include the function or not?

• Including the function -> actual return types/parameters
• Excluding the function -> easier to be composed in types (currently, you would need to use ReturnType<UseChainIdReturnType> or ReturnType<UseChainIdParameters>)

Testing

So far, I don't see a way of testing the Svelte package without adding the dependencies to the root. For now, I'm simply running vitest in the package instead of adding it to the Vitest workspace -- I will look into it in the future.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 0de269a

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

💥 An error occurred when fetching the changed packages and changesets in this PR

Some errors occurred when validating the changesets config:
The package "@wagmi/svelte" depends on the ignored package "@wagmi/test", but "@wagmi/svelte" is not being ignored. Please add "@wagmi/svelte" to the `ignore` option.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
wagmi	❌ Failed (Inspect)			Nov 1, 2024 5:12pm

[socket-security]

New dependencies detected. Learn more about Socket for GitHub ↗︎

Package	New capabilities	Transitives	Size	Publisher
npm/@sveltejs/adapter-auto@3.3.0	environment	+1	84.9 kB	svelte-admin
npm/@sveltejs/kit@2.7.2	environment, eval Transitive: filesystem	+17	1.53 MB	svelte-admin
npm/@sveltejs/package@2.3.6	Transitive: environment, filesystem	+12	1.3 MB	svelte-admin
npm/@sveltejs/vite-plugin-svelte@4.0.0	Transitive: environment	+5	697 kB	svelte-admin
npm/@types/eslint@9.6.1	None	+2	253 kB	types
npm/eslint-config-prettier@9.1.0	None	0	20.8 kB	lydell
npm/eslint-plugin-svelte@2.46.0	filesystem, unsafe Transitive: environment	+23	3.71 MB	ota-meshi
npm/eslint@9.13.0	environment Transitive: eval, filesystem, unsafe	+61	10 MB	eslintbot
npm/globals@15.11.0	None	0	176 kB	byk, lo1tuma, nzakas, ...1 more
npm/prettier-plugin-svelte@3.2.7	environment	0	1.5 MB	dummdidumm
npm/svelte-check@4.0.5	Transitive: environment, filesystem	+9	5.43 MB	dummdidumm, orta, svelte-language-tools-deploy
npm/svelte@5.0.5	None	+16	4.63 MB	svelte-admin
npm/typescript-eslint@8.11.0	Transitive: environment, filesystem	+34	8.13 MB	jameshenry

View full report↗︎

[socket-security]

🚨 Potential security issues detected. Learn more about Socket for GitHub ↗︎

To accept the risk, merge this PR and you will not be notified again.

Alert	Package	Note	Source	CI
Obfuscated code	npm/svelte2tsx@0.7.22	Confidence: 0.91 Location: Package overview	packages/svelte/package.json pnpm-lock.yaml	⚠︎

View full report↗︎

Next steps

What is obfuscated code?

Obfuscated files are intentionally packed to hide their behavior. This could be a sign of malware.

Packages should not obfuscate their code. Consider not using packages with obfuscated code

Take a deeper look at the dependency

Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support [AT] socket [DOT] dev.

Remove the package

If you happen to install a dependency that Socket reports as Known Malware you should immediately remove it and select a different dependency. For other alert types, you may may wish to investigate alternative packages or consider if there are other ways to mitigate the specific risk posed by the dependency.

Mark a package as acceptable risk

To ignore an alert, reply with a comment starting with @SocketSecurity ignore followed by a space separated list of ecosystem/package-name@version specifiers. e.g. @SocketSecurity ignore npm/foo@1.0.0 or ignore all packages with @SocketSecurity ignore-all

• @SocketSecurity ignore npm/svelte2tsx@0.7.22