Proposal: call-through bindings (&identifier)

[ryansolid]

Call-through bindings

Status: design draft

Summary

Add an explicit binding form for values that should be invoked whenever the
binding is read:

const [&count, setCount] = createSignal(0);

setCount(count + 1);

This proposal calls &count a call-through binding. It is not specific to
signals or to any framework. It represents a zero-argument callable whose result
is exposed through ordinary reads of the local binding.

At runtime, each read invokes the callable. For static analysis, a read is treated
as an ordinary zero-argument call at that source location, including contextual
typing, overload resolution, and widening.

Conceptually, the example above lowers to:

const [_count, setCount] = createSignal(0);

setCount(_count() + 1);

Motivation

TSRX lazy object and array patterns defer property and index selection:

const &{ name } = props;
const &[first] = items;

They intentionally do not invoke selected values. Consequently, lazy array
destructuring does not make a tuple containing an accessor convenient:

const &[count, setCount] = createSignal(0);

// `count` represents a deferred `tuple[0]`, not `tuple[0]()`.

Automatically invoking functions selected by &[] would be unsafe. Setters, event
handlers, components, and ordinary function-valued data are functions too.
Invocation therefore needs to be expressed by the individual binding.

Call-through bindings also apply to APIs exposing accessors through objects,
standalone accessors, callback parameters, and target-specific control-flow
binders:

const { data: &data, pending: &pending } = query;

const &timestamp = readTimestamp;

function doubled(&value: () => number) {
  return value * 2;
}

Proposed syntax

Extend binding atoms with a call-through identifier:

CallThroughBindingIdentifier :
  & BindingIdentifier

In the initial version, a call-through identifier may appear:

• as a leaf of a const variable binding;
• as a leaf of a const for-of binding;
• as a runtime formal parameter in a function implementation; or
• in a target-defined binder that explicitly exposes a callable carrier.

It is not a general replacement for every ECMAScript or TypeScript
BindingIdentifier.

const &value = accessor;
const [&count, setCount] = tuple;
const { current: &current } = source;
const { nested: { current: &current } } = source;

function read(&value) {
  return value;
}

const read = (&value) => value;

The whitespace-sensitive spelling is &value. & must be lexically adjacent to
the identifier; whitespace, comments, or a line terminator between them make the
form invalid in a binding position. This matches the existing treatment of &{
and &[.

Parser and AST model

The parser should recognize &identifier only while parsing a binding atom. An
&identifier token sequence in expression position retains ordinary ECMAScript
parsing behavior and never becomes a call-through read or escape.

The smallest ESTree-compatible representation is an Identifier binding node
augmented with callThrough: true, parallel to the existing lazy: true
augmentation on object and array patterns. The runtime transform must consume the
flag before ordinary JavaScript is printed.

This remains semantically distinct from a lazy object or array pattern:

• A lazy pattern changes how a source member is selected and supports its existing
  member-read and member-write behavior.
• A call-through identifier changes how one bound callable is read and is
  read-only.
• A call-through identifier nested in a lazy pattern composes both operations.

Composition with lazy patterns

The existing lazy-pattern marker and a call-through leaf express separate
operations and may be composed:

const &{ current: &current } = source;
const &[&first, second] = values;

The outer &{} or &[] defers selection from the source. The inner &current or
&first invokes the selected callable on each read.

Conceptually:

current; // (0, source.current)()
first; // (0, values[0])()
second; // values[1]

The detached call is intentional: a callable obtained through a binding is invoked
without the lazy-pattern source as its receiver. Ordinary ECMAScript this
coercion still applies inside the called function.

For a mixed pattern:

const &{ current: &current, value } = source;

source is captured once. Every current read performs one property Get and
one detached call; a getter for source.current therefore runs once per read.
value retains the existing lazy member-read and member-write behavior, while
current is read-only. A computed key expression on a lazy path is reevaluated at
the point of each member selection, in path order, as part of that read.

Runtime semantics

Initialization

The initializer and ordinary destructuring operations run exactly as they do for
the corresponding non-call-through binding. The resulting callable is stored once.

const [&value] = createTuple();

Conceptually:

const [_value] = createTuple();

An enclosing lazy pattern remains lazy according to its existing semantics:

const &[&value] = createTuple();

Conceptually retains the tuple and selects index 0 for each read rather than
extracting it during initialization.

Reads

Every runtime reference to a call-through binding performs one zero-argument call.
Calls are not memoized or shared:

value + value;

Conceptually:

_value() + _value();

Each runtime read is also a distinct call for control-flow analysis. Narrowing one
read does not narrow a later read:

const &value: () => Item | undefined = readValue;

if (value) {
  value.name; // error: this is another call and may return undefined
}

Users who need one stable, narrowable result capture it explicitly:

const current = value;
if (current) current.name;

The rewrite applies in property access, object shorthand, JSX expressions,
closures, typeof, and other ordinary read positions:

value.name;
({ value });
() => value;
<Output value={value} />;
typeof value;

Lexical shadowing stops the rewrite:

const &value = accessor;

function nested(value) {
  return value; // the parameter, not the call-through binding
}

Control-flow narrowing

Call-through bindings do not change ordinary JavaScript control-flow analysis.
Plain if, ternary, and logical expressions see ordinary calls and require an
explicit snapshot when later reads must stay narrowed.

Compiler-owned TSRX control-flow constructs may provide stronger, construct-local
narrowing by preserving the value that admitted a branch. This is separate from
the call-through binding itself and must be implemented by the target's control
flow lowering.

For example, Solid can lower a bare call-through condition:

const &user = readUser;

@if (user) {
  <Profile name={user.name} />
}

through Show's narrowed accessor:

<Show when={readUser()}>
  {(narrowedUser) => <Profile name={narrowedUser().name} />}
</Show>

Source references to user in the admitted branch map to the narrowed accessor.
This preserves reactive reevaluation, non-null typing, and stale-read protection
without treating every call-through read as globally stable. Bare truthiness
conditions are sufficient for the initial integration; compound predicates and
discriminant narrowing require separate control-flow design.

Callable current values

The binding denotes the accessor's current result, including when that result is
itself callable. Calling the binding therefore invokes both layers:

const &handler = readHandler;

handler(event);

Conceptually:

readHandler()(event);

This distinction is why a call-through binding should not special-case references
that happen to be the callee of another call.

Defaults

Defaults select the callable before call-through behavior is applied:

const [&value = () => 0] = source;

The default follows ordinary destructuring rules: it is evaluated only when the
selected value is undefined, and the resulting callable is then invoked for each
read of value.

Under an enclosing lazy pattern, each read performs member selection, compares the
selected value with undefined, evaluates the default when needed, and invokes
the result. A lazy default may therefore execute more than once:

const &[&value = createFallbackAccessor()] = source;

Preserving this behavior requires the lazy transform to retain defaults on its
generated read path. The current implementation's loss of nested lazy defaults is
not adopted as language semantics.

Defaults do not normalize null. A nullable carrier throws when read unless the
author normalizes it explicitly:

const &value = maybeAccessor ?? fallbackAccessor;

Writes

Call-through bindings are read-only. It is a compile-time semantic error for any
assignment target to resolve to a call-through binding, including simple,
compound, logical, destructuring, update, and for-in or for-of assignment
targets. Declaration and per-iteration binding initialization are not assignments
to the source-level binding.

value = next; // error
value++; // error
value ??= fallback; // error
({ value } = source); // error when `value` resolves to a call-through binding
for (value of values) {
} // error

Mutation should remain explicit through the API that accompanies the accessor:

const [&count, setCount] = createSignal(0);
setCount(count + 1);

This differs from an ordinary lazy-pattern leaf, which may support write-through
member assignment. A zero-argument callable has no standard write protocol, so
this proposal does not infer one from a neighboring setter or API shape.

Broader examples

Accessor tuples

const [&count, setCount] = createSignal(0);
const [&selected, select] = createSelection();

setCount(count + 1);
select(selected ? null : "first");

Accessor properties

const {
  data: &data,
  error: &error,
  pending: &pending
} = query;

@if (pending) {
  <Spinner />
} @else if (error) {
  <ErrorMessage error={error} />
} @else {
  <Result value={data} />
}

Derived functions

function fullName(
  &first: () => string,
  &last: () => string
) {
  return `${first} ${last}`;
}

const label = () => fullName(readFirst, readLast);

Iterating accessors

for (const &current of accessors) {
  console.log(current);
}

Each iteration binds one callable. Reads of current invoke the callable selected
for that iteration.

Imported accessors

Local call-through aliases could make accessor exports convenient without changing
the module's public contract:

import { count as countAccessor } from "./state";

const &count = countAccessor;
console.log(count);

A direct import-binding spelling such as the following is deliberately left for
discussion:

import { count as &count } from "./state";

It can lower cleanly to an ordinary hidden import, but it expands the proposal
into module grammar and requires formatter, linter, and language-service support
at another syntax site.

Function-valued state

const &formatter = readFormatter;

// Reads the current formatter, then invokes that formatter.
const output = formatter(input);

Lazy selection plus invocation

const &{
  session: {
    user: &currentUser
  }
} = application;

<Profile user={currentUser} />

Target-provided accessor binders

A target whose control-flow primitive supplies an accessor could allow the same
binding form in that construct:

@for (&item of rows; key item.id) {
  <Row item={item} />
}

@try {
  <Content />
} @catch (&error, reset) {
  <ErrorMessage error={error} retry={reset} />
}

These examples are target-gated; they do not require every TSRX target to
represent loop items or errors as accessors. Each target-defined binder specifies
a carrier type. The call-through form is valid only when that statically exposed
carrier type is zero-argument callable. Targets must not add runtime callability
gates.

Static semantics

A conforming implementation should:

1. Require the carrier to have a call signature applicable with zero arguments and
   no reference receiver. A this: void signature is compatible; a callable
   requiring another explicit this type is not.
2. Type each read exactly as an ordinary zero-argument call at that source
   location, preserving contextual generic inference, overload resolution, and
   widening.
3. Do not carry control-flow narrowing from one read to another unless the host
   type system independently supports stable-call semantics for the carrier.
4. Report a type error for a non-callable carrier, a union containing a
   non-callable constituent, or a callable that requires arguments.
5. Reject every assignment target that resolves to the binding.
6. Apply rewrites by resolved binding identity, not identifier spelling.
7. Preserve temporal-dead-zone and lexical-shadowing behavior.

No eager runtime callability check is inserted. If runtime selection produces a
non-callable value, the read throws the ordinary ECMAScript TypeError.

The split between the callable's storage type and the source binding's read type
requires language-service support. Parser and compiler support alone would leave
editor types misleading.

Call-through syntax affects only an implementation's local binding. In emitted
declarations, & is erased and a public parameter retains its carrier type:

// Authored implementation
export function doubled(&value: () => number) {
  return value * 2;
}

// Emitted declaration
export declare function doubled(value: () => number): number;

Type-position references do not perform runtime calls. A type query for the local
call-through binding denotes the result of an uncontextualized zero-argument call;
a generic carrier may therefore produce its default or unknown result there.

TypeScript projection

The current type-only treatment of lazy patterns cannot be reused unchanged.
Removing & from a lazy pattern gives TypeScript a useful eager-destructuring
approximation, but removing & from a call-through binding would type count as
() => T instead of T.

The virtual TypeScript projection should model storage as a callable and every
source-level read as a call expression:

// Authored TSRX
const [&count, setCount] = createSignal(0);
const next = count + 1;

// Virtual TypeScript used for language intelligence
const [_count, setCount] = createSignal(0);
const next = _count() + 1;

Source mappings should map the authored &count binding to the callable storage
and each authored read to the corresponding call result. Hover and diagnostic
requests on a read expose that call site's result type, while signature help and
initializer diagnostics still see _count as the carrier.

Because the call expression remains at its use site, contextual generic inference
is preserved:

// Authored TSRX
declare function make<T>(): T;
const &value = make;
const text: string = value;

// Virtual TypeScript
declare function make<T>(): T;
const _value = make;
const text: string = _value();

Parameters and construct-owned bindings need equivalent scope-local projections:

// Authored
function doubled(&value: () => number) {
  return value * 2;
}

// Virtual TypeScript
function doubled(_value: () => number) {
  return _value() * 2;
}

This projection requires explicit source-segment mappings; merely teaching the
parser and runtime transform about callThrough is insufficient.

Initially excluded forms

Mutable variable declarations

Variable declarations containing call-through bindings should initially require
const:

let &value = accessor; // error
var [&value] = tuple; // error

An ordinary assignment could ambiguously mean replacing the underlying callable or
writing its current result. Neither behavior is implicit in this proposal. Runtime
function parameters and const for-of bindings remain valid, but later
assignments targeting them are still errors. let, var, for-in, and
assignment loop heads do not introduce call-through bindings.

Object shorthand

Call-through object bindings should initially require an explicit property:

const { value: &value } = source;
const { &value } = source; // error

The second form would need to define whether value is both the property key and
the local call-through binding, as well as custom handling before the parser
reaches a binding atom. The explicit form has ordinary object-pattern key
semantics.

Rest bindings

Call-through rest bindings should initially be rejected:

const [...&values] = source; // error

A rest operation creates a collection, not one callable binding, so invocation
semantics are unclear.

Exported bindings

Transparent call-through behavior cannot be preserved through an ordinary
ECMAScript named export:

export const &count = accessor; // error

An importing module would receive either the callable or one evaluated value; it
would not inherit the source module's lexical read rewriting. Exporting the
accessor explicitly remains available:

export const count = accessor;

An export list containing an existing call-through binding should be rejected for
the same reason:

const &count = accessor;
export { count }; // error

An export default expression is an ordinary read and exports one evaluated
snapshot:

const &count = accessor;
export default count; // evaluates the accessor once during module evaluation

Direct import bindings

The initial syntax does not include call-through import aliases:

import { count as &count } from "./state"; // not initially supported

Users can import the callable normally and create a local call-through alias. A
direct form can be considered separately after the module grammar and language
service behavior are understood.

Other binding positions

The initial version rejects call-through syntax in:

• function and class declaration names;
• native ECMAScript catch bindings;
• TypeScript constructor parameter properties;
• using and await using declarations;
• ambient declarations and overload-only signatures; and
• type-only function signatures.

These positions either have no runtime body in which reads can be rewritten or
carry declaration and initialization semantics outside this proposal. A
target-defined @catch binder is separate from a native catch clause and may
explicitly opt in when its carrier type is callable.

JSX component names

A JSX component name is not a call-through read in the initial version:

const &Page = currentPage;

<Page />; // error: a call-through binding cannot be used as a component name

Selecting a component reactively requires target-specific dynamic-component
lowering, not merely one call during element creation. Targets should use their
existing explicit dynamic-component facility, where Page appears in an ordinary
expression position:

<Dynamic component={Page} />

For Solid, this preserves the established reactive behavior of Dynamic while
still allowing the call-through prop expression to expose the current component.

Call arguments

This proposal only covers zero-argument invocation. Parameterized selectors remain
ordinary functions:

const selectUser = (id) => users[id];
selectUser(id);

Encoding arguments into a binding declaration would introduce a substantially
different feature.

Direct eval

Direct eval in a scope containing a call-through binding should be rejected:

const &value = accessor;
eval("value"); // error

Dynamically parsed source cannot participate in lexical read rewriting, and hidden
storage names are intentionally not observable. Indirect eval has no access to
the local binding and is unaffected.

Access to the underlying callable

Ordinary reads expose the callable's result, so some programs will still need the
underlying callable identity for subscription, registration, or interop.

The minimal proposal uses an explicit alias:

const [countAccessor, setCount] = createSignal(0);
const &count = countAccessor;

subscribe(countAccessor);
setCount(count + 1);

Possible future escape syntax could expose the callable through the call-through
name, but this draft does not propose one. Deferring the escape keeps expression
grammar unchanged and avoids committing to syntax before real identity-sensitive
cases are collected.

Syntax opportunity cost

&identifier is not entirely unclaimed syntax. TSRX already associates & in a
binding position with lazy or indirect access through &{} and &[], so a leaf
form belongs naturally to that family. Several other features could nevertheless
compete for the same spelling.

Scalar lazy or computed bindings

const &total = price * quantity;

This could mean that the initializer expression is reevaluated whenever total is
read. It is the strongest competing interpretation because it appears to be the
scalar analogue of a lazy pattern. It differs fundamentally from this proposal:
call-through initialization evaluates the initializer once, stores the resulting
callable, and invokes that callable on each read.

A computed binding would also need target-specific answers about tracking,
memoization, exceptions, and evaluation ownership. Call-through requires none of
those mechanisms; its runtime operation is an ordinary detached JavaScript call.

Writable reference bindings

let &name = user.name;
name = "Ryan";

This could preserve an assignable location and make later reads and writes operate
through it. Such a feature would align with the write-through behavior of ordinary
lazy-pattern leaves, but JavaScript initializers normally produce values rather
than persistent references. Receiver lifetime, computed-key reevaluation,
aliasing, and parameter-passing rules would all require new semantics.

The initial call-through proposal excludes let and var, but accepting
&identifier for call-through still establishes the meaning of the leaf syntax
and makes a later incompatible reference interpretation less coherent.

Generic dereference bindings

const &value = ref;

Rather than specifically invoking a callable, & could select a generic
dereference protocol that supports functions, .value cells, or target-defined
reference objects. This would be more extensible but would make identical source
depend on carrier type or compilation target. The call-through proposal instead
chooses one operation with existing ECMAScript semantics: zero-argument
invocation.

By-reference parameters

function swap(&left, &right) {
  // ...
}

Other languages use similar syntax for pass-by-reference parameters. Supporting
call-through formal parameters consumes that interpretation directly. TSRX would
need a new call-site and location model to support true by-reference arguments,
making this less aligned with JavaScript than call-through parameters.

Expression-position escape

An expression such as &count could eventually expose the underlying callable or
represent an address-of operation:

subscribe(&count);

This proposal does not consume expression-position &identifier; it is recognized
only while parsing a binding atom. An escape can therefore be considered
separately, although reusing the sigil should remain conceptually consistent with
the binding form.

Rationale for consuming the leaf form

Call-through is the most framework-neutral candidate:

• it lowers to ordinary JavaScript without a runtime protocol;
• it has deterministic initialization and per-read evaluation semantics;
• it composes with existing lazy member selection;
• it addresses callable accessors from any library rather than recognizing
  target-specific APIs; and
• ordinary call expressions provide an established static model for each read.

The principal trade-off is giving up the concise scalar-computed interpretation.
That cost should be accepted explicitly before implementation rather than treating
&identifier as free syntax.

Alternatives

Global getter-style narrowing

An implementation could treat repeated call-through reads like repeated property
getter accesses:

if (value) value.name; // accepted under getter-style control flow

That is attractive for accessor control flow, but a synthetic-getter projection
changes TypeScript behavior for generic zero-argument functions by losing use-site
contextual inference. It also grants an optimistic stability assumption that
cannot be justified for every callable accepted by this general proposal.

The initial version therefore retains ordinary call-expression control flow.
Target-owned constructs such as Solid's @if lowering may provide local
narrowing, and a future TypeScript facility for
stable calls could
extend narrowing without changing call-through projection.

Invoked binding elements

const &[count(), setCount] = createSignal(0);

This makes invocation visible, but places call-expression-shaped syntax in a
binding pattern. It also does not naturally provide a standalone declaration or
parameter form without spellings such as const count() = accessor.

@value

const [@count, setCount] = createSignal(0);

@ already introduces TSRX render blocks and control flow, and TypeScript uses it
for decorators, including legacy parameter decorators. Reusing it would create
both conceptual and parsing conflicts.

Automatic invocation in lazy array patterns

const &[count, setCount] = createSignal(0);

Inferring that count should be invoked from its tuple position is
target-specific and unsafe for setters and ordinary callable data. Existing &[]
semantics must remain deferred index access only.

Target-specific signal recognition

A compiler could recognize selected APIs such as createSignal, but aliases,
wrappers, user-defined factories, and cross-package APIs make callee-name
recognition incomplete. It would also move a framework-neutral binding facility
into individual target compilers.

Questions for discussion

1. Are const declarations, const for-of bindings, runtime formal parameters,
   and explicit target binders the right complete initial surface?
2. Is a raw-callable escape needed in the first version?
3. Should optional call-through be expressible in the first version, or should
   explicit nullish normalization remain required?
4. Which target-defined binders, if any, should opt in initially?
5. Does detached invocation with no reference receiver match the intended binding
   model?
6. Which compiler-owned control-flow constructs should provide branch-local
   narrowing before TypeScript supports stable calls?
7. Should named import aliases support a direct call-through spelling?
8. Is call-through the best use of the bare &identifier leaf, or should that
   syntax be preserved for computed or writable-reference bindings?

Prototype plan

Before requesting adoption:

1. Extend binding-atom parsing and AST types with an explicit call-through marker;
   confirm expression-position &identifier remains unaffected.
2. Extend the shared transform with a call-producing read path distinct from lazy
   member access and lazy writeback.
3. Implement the virtual TypeScript storage/read projection and source-segment
   mappings.
4. Add printer, Prettier, document-symbol, formatter round-trip, Tree-sitter, and
   TextMate grammar coverage.
5. Add runtime tests for declarations, destructuring, parameters, loop bindings,
   defaults, function-valued results, nested lazy patterns, mixed
   writable/read-only leaves, evaluation order, and shadowing.
6. Add negative tests for writes, mutable declarations, shorthand, rest, exports,
   direct imports, unsupported binding positions, JSX component names, direct
   eval, non-callable types, and expression-position &identifier.
7. Verify the TypeScript plugin and language server, including hover types,
   contextual generic inference, overload and widening behavior, independent-call
   control flow, target-local narrowing, diagnostics, completion scopes,
   declaration emission, and source mappings.
8. Update the formal grammar and lazy-binding specification.
9. Only after the semantics are accepted, add matching Oxc parser support.

[leonidaz]

Yeah I see that it may seem more elegant not having to using the call syntax.

It doesn't seem to conflict with any other TC39 proposals.

But at the same time if we take Solid, when I use count instead of the usual count(), I lose the code readability that I'm reading the signal value, especially the further lines it's away from the &count declaration. But it is an opt-in.

I def see that the current lazy & tsrx assignment doesn't bring any value to Solid's signals.

This syntax does make Solid look like React which may make it easier for people migrating from React to Solid to digest the syntax without caring how Solid works.

So, since it's an opt-in and essentially just a binding-level sugar for zero args calls, I don't mind having this in the tsrx syntax.

I guess my concern would be if we wanted to use & prefix for something else in the future.

[ryansolid]

But at the same time if we take Solid, when I use count instead of the usual count(), I lose the code readability that I'm reading the signal value, especially the further lines it's away from the &count declaration. But it is an opt-in.

It is the Svelte 5 issue. Because double still needs to be wrapped in a function. Semantic highlighting could help make call-through reads visible farther from that declaration.

This does not adopt React’s execution model.

const [&count, setCount] = createSignal(0);
const &double = () => count * 2;

This captures one snapshot:

const [&count, setCount] = createSignal(0);
const double = count * 2;

That can be intentional, so the language cannot reject it universally, but Solid-aware tooling could warn about likely accidental untracked reads.

The opt-in binding also gives Solid tooling a definitive symbol to trace. It can diagnose eager computations such as const double = count * 2 in component initialization without relying on API-name inference. Solid could enforce it through a strict diagnostic with an explicit snapshot boundary.

I guess my concern would be if we wanted to use & prefix for something else in the future.

Yeah I was thinking that too this morning. I've editing the proposal to explore some of those options.

[trueadm]

I'm a bit torn on this proposal. Whilst I can see why you'd want it, it poses a few hesitations from me:

• & now becomes syntax soup, where it's hard to really know if it means a lazy destructure or a lazy call
• &foo = 5 what does this mean?
• What if I assign or mutate a binding that was from const [&x] = something, x = 5 or x++?
• When calling a function with no arguments what does that mean for type widening and TS in general?

[trueadm]

To play devils advocate, you could offer something similar to Ripple?

import { createSignal } from 'solid-js/tsrx';

function Button() @{
  const &[count, setCount] = createSignal(0);

  <button onClick={() => setCount(count + 1)}>{count}</button>
}

Super easy for an agent to get right too, clear change in import, which they're very good at getting right now. In fact, a very capable LLM suggested this to me in response to this thread. You could even make it a compiler error to use &[] on a createSignal that is not from solid-js/tsrx, meaning an agentic would easily find its way through it – storing the fact to its memory.

[leonidaz]

it probably read my response lol. i like the sound of "very capable LLM" 😉

Yeah, this seems so far like the best idea with the import as far as a possible alternative solid-tsrx api and fully analyzable by the compiler to prevent misuse.

[ryansolid]

I don’t see this becoming a coherent system rather than a convenience limited to built-ins. 3rd parties will continue returning ordinary Solid accessors. Either every library publishes a TSRX wrapper, consumers wrap results in an adapter, or the compiler learns library/type-specific behavior.

It can "work" but it makes it a thing. Developers translate between two reactive representations wherever there is a gap. That split is larger than I think I’d want to introduce. Of all the options we've talked about today I think that is the least preferable from my perspective.

[leonidaz]

fwiw, all .tsx and .tsrx can be scanned by the compiler, including 3rd party libs, it's doable and we're doing it with Ripple and Octane. The compiler can identify source files vs compiled dist, imports, /** @jsxImportSource solid */, etc.

With .tsrx files people / 3rd parties should ship source vs compiled, to make sure they can get the latest compiler optimizations and avoid potential version mismatches.

The regular .tsx Solid code can also benefit from compiler optimizations, e.g. Octane has lots of those implemented, so I'd recommend shipping source .tsx for Solid going forward.

Obviously you'll do whatever you think is best for Solid but I wanted to lay out these options.

[ryansolid]

We already do ship source. But usually its source and client build. The assumption is people doing no build are client only. Shipping compiled down seemed prohibitive with the different outputs for ssr, Hydration, not to mention esm vs cjs. The no build constraint might tie my hands here.

But if I'm following the the destructure syntax works everywhere. Do you have a wrapper to make the 0 property getter more ergonomic or the expectation is custom primitives usually return objects with get 0 etc...?