Any comparison with Signal?

[NJUShane]

"Legend-State beats other React state libraries in both speed and memory usage. "
However，signal doesn't appear in the benchmark table。
I wounder if legend-state beats signal。

[chakrihacker]

Signals are not complete as far as I know and monkey patches the react, so it's not worth comparing at this moment

[jmeistrich]

Are you referring to Preact Signals? They haven't submitted it to the benchmark so I can't compare it: https://krausest.github.io/js-framework-benchmark/current.html. If they add it to the benchmark I'd be happy to add it to my saved screenshot. I see they've done a lot of optimization so I'd be surprised if their speed isn't comparable, but Legend-State is unique in the array optimizations so they won't be able to beat the optimized mode.

And to build on what @chakrihacker said, I don't really consider signals to be a comparable alternative since it seems to mainly be for reactive primitives and doesn't seem like a full solution for global state management (although I could be wrong about that).

[texastoland]

I came looking for a general comparison with alternatives. The differences that jump out at me:

1. API:
   1. Jotai: useState-like tuple
   2. Valtio: automatically unwrapped values (similar to Vue reactive)
   3. Signals: .value (similar to Vue ref)
   4. Legend: .get()/.set() pair (perhaps for better destructuring)
2. Deeply reactive objects and arrays:
   1. Jotai: no but supports deep mutation with Immer integration
   2. Valtio: yes
   3. Preact: no
   4. Legend: yes
3. Async:
   1. Jotai: special primitives
   2. Valtio: automatically unwrapped promises
   3. Preact: nothing
   4. Legend: special fetch hook
4. Context providers:
   1. Only Jotai has its own (simpler!) Provider (for multiple documents, users, etc.)
   2. But Valtio documents how any alternative should work with React context
5. SSR: only Jotai documents it but all support it
6. Utilities:
   1. Jotai:
      1. In-window devtools
      2. Persistence
      3. Caching
      4. Numerous integrations such as React Query
   2. Valtio:
      1. Redux DevTools,
      2. Undo
   3. Signals: nothing
   4. Legend:
      1. Tracing (debugging)
      2. Undo
      3. Persistence
      4. Transactions
      5. React query integration
      6. Various hooks such as useMeasure
7. Fine-grained rendering: only Legend is stable but all support it

Can you think of anything else? A feature matrix would be great!

[jmeistrich]

This is great, thanks! Where do you think we should put such a feature matrix? On the Why page in the docs? Or its own page?

A couple notes on your list:

1. get()/set() is for referential stability, so that you can pass a child observable as a prop. We tried automatically unwrapping in an early version but that made it very complicated to pass observables through props/context so we changed it to default to stable references with get()/set(). A tuple has the same problem - it's then an array instead of a stable reference. And we can't use value because that only really makes sense with no hierarchy - that would break any objects that have a value key. We also have an optional feature to use $ for direct access. Would it be helpful to describe all of that in a comparison table?
3. Legend-State also automatically unwraps promises in the constructor. And now because of you, as of 1.6.0 it unwraps them automatically in set() too. fetch is more about automatically calling .json() on the result and tracking loading states, but setting plain promises should be straightfoward without that.
4. Would there be value in our having a provider? We don't use contexts much so I hadn't thought about it. Are our docs about how to use in context clear enough?

[texastoland]

Where do you think we should put such a feature matrix? On the Why page in the docs?

Why? makes sense to me but Jotai gives an in-depth comparison to Context, Recoil (direct alternative from Facebook), and Zustand (indirect alternative from the same author). I think it's essential for any project to explain why choose it instead of established alternatives. IMO Legend has 3 "solid" answers:

1. Valtio and MobX are popular reactive state libraries. Legend offers a simplified API and aspires to provide more utilities (Jotai does this well).
2. If you add 2-way binding to reactivity that's basically Vue JSX. Legend delivers Vue ergonomics to React.
3. Vue isn't loved by React devs but Solid is. Legend provides some of the innovations and optimizations from Solid to React. By comparison Preact's implementation depends on React's internal API. Valtio and Jotai offer a safer JSX transform but it it's still experimental. Legend's solution is considered stable.

Legend should also directly show how it integrates with core React features:

✔️ Async in general
✔️ Context (doesn't re-render)
✔️ Other state libraries (only React Query)
❓ SSR (for Next.js)
❌ SWC plugin (Vite and Turbopack don't use Babel by default for speed)
❌ Suspense (essential IMO)

[texastoland]

so that you can pass a child observable as a prop

That's brilliant! I forgot to include 2-way binding in my list. The live examples are currently broken BTW (missing import?) 🪳

FWIW I consider destructuring a feature too. I've tinkered with Solid and currently Vue and it's a foot gun in both frameworks.

We also have an optional feature to use .$ for direct access

OMG that's genius 😍

Legend-State also automatically unwraps promises in the constructor

Whaaa! So I compared your implementation with Valtio:

• First thing to note is I love how much more straightforward your proxies are 🧠
• Valtio throws the unevaluated promise for Suspense but:
  • will stop resolving promises in the next version
  • because React will stop suspending thrown promises
• I also love how you replace the resolved promise with its value or { error } but:
  • Have you considered how to support use for Suspense?
  • I have ideas but don't think it's possible without the original promise reference
• Valtio's promises currently resolve at any depth but Legend only unwraps createObservable (root) instead of getProxy (props) right?

as of 1.6.0 it unwraps them automatically in .set() too

f076cd1 🚀

fetch is more about automatically calling .json() on the result

Do you know about ofetch? It's the most minimal (3.1KB gzip) fetch wrapper I'm aware of, a core dependency of Nuxt, battle-tested for your use case (https://github.com/unjs/ofetch/blob/41c3b56002ed0d5fbecf2ed329be34ffa8fbe5f6/src/fetch.ts#L189-L202), plus other standard enhancements like throwing HTTP errors 👀

and tracking loading states

I noticed this 1 😁

Would there be value in our having a provider?

I couldn't think of any tangible benefit no 🙊

Where do you think we should put such a feature matrix?

This was arguably the important point so I'll replay separately!

[jmeistrich]

I fixed the live examples on the docs. Thanks for catching that!

The current implementation of unwrapping promises does it while setting, and setting is optimized to not navigate the entire hierarchy so we can't check for promises everywhere. But we could think more about that. We have not tested or designed for Suspense yet - we should probably do that before going deeper on promises 🤔

I have not heard of ofetch. We don't really use fetch much ourselves. We're aiming to have a big library of helper observables and hooks, and that could be good one if you want to submit a PR for it?

[texastoland]

My bad for breaking the thread 😅 I forgot we're in a discussion instead of issue.

We're aiming to have a big library of helper observables and hooks, and that could be good one if you want to submit a PR for it?

YAAAS 🚀

setting is optimized to not navigate the entire hierarchy so we can't check for promises everywhere

I understand why but from a DX perspective I (naively?) expect any observable state record:

// my style preference
const state = observable({ value, api: { promise } })

To be functionally equivalent to its decomposed state values:

const value_ish = observable(value) // same as state.value
const promise_ish = observable(promise) // same as state.api.promise

We have not tested or designed for Suspense yet - we should probably do that before going deeper on promises

Moved to #162 (comment).

[jmeistrich]

Thanks for all the info! I'll refer back to this when trying to make Suspense work 😀

[texastoland]

I was checking Valtio and realized they solved it the exact same way:
https://github.com/pmndrs/valtio/blob/9e6868c8e60f6c0057cb2d314e0f4cff22d42b8e/src/vanilla.ts#L273-L284

[jmeistrich]

@texastoland I think I may have gotten Suspense to work with a little hook. I made an issue for it so we don't overwhelm the original discussion to much. #162