It's a concern we are aware of and one that I've looked at a number of times over the years most notably:

Writing:
The Quest for ReactiveScript(2021)
ReactiveScript Revisited(2024)

Video:
SolidScript?! Using Compilation for Syntax(2022)
Revisiting ReactiveScript: Reactive Compilation(2024)

The TLDR; though is it is there is no good universal solution. We are basically fighting the JavaScript language itself. For every way we bend it we point out some other inconsisency, break in the abstraction. I do wonder if this is something that can change in the future but in the meanwhile I think these sort of approaches get in the way of teaching people how to write code in the paradigm.

@kachurun
Just because this can work doesn't save you from needing to do the mental translation.

function NowItShouldWork(props) {
  const { cond = true, class: className, ...attrs } = $destructure(props);

  const classList = $memo(clsx('example', className));

  return <>{cond ? <A class={classList} {...attrs} /> : <B {...attrs} />}</>;
}

Why is there a $destructure here?.. what happens if I destructure elsewhere. Is it ok to wrap expressions in $memo in a function? When do I need to wrap things in a function? Why doesn't this work?

function customSignal() {
  let count = $signal(0)
  return count;
}

Honestly it teaches all the wrong things and in the end you need to have the right mental model or you will trip up elsewhere. You say the native Solid version is much worse but I don't think the label version simplifies things at all. Atleast the native version has clear behavior in terms of what to expect that aligns with JavaScript itself and how reactivity. Even the bug you are concerned with in Solid Labels could be interpreted either way as the proper behavior. There may be a time where this changes and I have been paying attention to work Vue and Svelte have done in this area. However, I haven't seen anything to suggest this is a good approach as of yet, and if anything I worry it ties our hands a bit moving into the future.

Nothing wrong with people using this in their own projects if they have a preference but hard to recommend in general.

@everton-dgn When I said streamline prop/attribute I'm referring to looking at how we have supported multiple typings, how we have weird conventions around custom elements, how there are multiple ways to set class that makes it hard to handle spreads. All stuff within the JSX itself. We are looking at optimizing some patterns around mergeProps/splitProps and performance improvements but categorically we will still depend on helper functions.

In general, we do understand this is a pain point for some developers but it also is an unsolved problem, one that honestly feels much harder to solve (if solveable at all) than everything else on that list put together. I've seen tons of suggestions over the years, and alternative proposals but nothing that covers the bases. Given what Solid values in terms of performance, and transparency, I'm not prepared to make half-baked compromises to satisfy aesthetics. If we are going to solve this, it has to be real.

@caseybaggz

Here is a similar example of WorkButLookWeird written in a way that I personally believe is more readable and uses less cognitive energy to interpret: Rendering a link or button with the same style...
I'm happy to learn how to improve it if there is room to grow

To me, it's extremely complicated and also breaks DRY principles. Also, you anyway destructure localProps, so it's not reactive anymore. Why do you need all of this Show with fallbacks? I never do something like that because it could be significantly easier with just a single Dynamic, isn't it?

I personally believe it is much easier because it forces you to understand what true reactivity is (a very good thing) and also tells the reader/maintainer (no matter their experience level) what the code is actually doing.

I would agree with you 100% if we lived in a perfect world. The truth is that if you have a product and you do something more serious than a todo-list from the framework documentation examples, then most likely you have a team that will face quite serious challenges in implementing business requirements. I'm 100% sure you understand this.
Each team member has different abilities and a different understanding of both your product and the frameworks on which it is built. And there can be 2-5 frameworks depending on how big and old the project is. Half of your team will probably not be so deeply immersed in how signals and reactivity work. It's sad, but most middle developers do not know and do not understand shit. And your job as a lead is to guide them, by any means necessary. Documentation, linters, calls, any format. And then the developers leave and take the knowledge with them, new ones come without knowledge, and everything starts over again. From my point of view, I want to work with a framework with a minimal learning curve, one that you don't need to learn anything to work with, it's enough to know how html/js/css works. And unfortunately, SolidJS is quite complicated in this regard. To start doing things, you need to learn a dozen hooks and keep in mind a number of utilities like splitProps / mergeProps. And stumble upon a dozen or so situations when seemingly absolutely working code suddenly doesn't work. And of course, change the paradigm of thinking and the fact that there is no central Update / Render, which is not a problem at all. But I just don't want to hear from developers that they spent half a working day on another stupid error due to destructuring or the absence of a function in the right place. But this is exactly what happens.

The only problem here is that I have no idea how to solve this. As Ryan said, this is a fight with JavaScript. You can't just destructure, say, a number into a variable by reference. We don't even have native signals. Hence the need for all these functions and nested signals. I understand this. It's not worth saying that I don't understand how reactivity works or am still in the process of learning the framework, this is not true, but we are all now facing an important stage when there is an opportunity to discuss the future of Solid and perhaps somehow influence how it will look in the next couple of years and make it better.

Let's forget about labels and the idea of ​​making such changes to the code during compilation, after all, the source code written using labels is too different from the real code that is executed and it only adds an extra layer of magic. It's a bad idea, period.
But for example, I could imagine that props are wrapped in Accessors instead of Getters. i.e. they look like signals. This would make it a little more transparent why they are reactive at all, as well as the understanding that the value of the prop is calculated when accessing it. This would solve the problem of destructuring, but it would add visual noise in the form of () every time the prop is accessed. That's what's a little annoying about signals now.

Or vice versa, why not declare that using signals is not canonical and it is better to always use stores. Like in Solid2 for any local state it is recommended to create its own store instead of a bunch of signals and memos. Stores can be mutable and return a store directly instead of a tuple (setter can be imported if you really want, like some reconcile), and getters automatically become memos (this is what is really missing). Like mobx.observable. Then the behavior and syntax of stores and props will be identical and components will not be filled with dozens of () signal calls. Why not, why not discuss it.

Or maybe it's time to coat everything with decorators. It's already stage3 there. Well, I would definitely like to write '@memo get something() {}' like in good old mobx, inside a store (or any object).

Otherwise, I just don't see the point in making a major release if you're afraid of breaking or changing something. 2.0 should be a rethinking, a new chapter, a large-scale improvement taking into account the experience of using 1.0 by our large dev community.

Just because this can work doesn't save you from needing to do the mental translation.

@ryansolid Thanks for the answer. Yes, labels are a thing that is better not to use. $memo for example is broken (it obviously should just work as an alias and accept a function). $signal does not add convenience, only discomfort and potential bugs. You are 146% right. But I wrote only about $destructable, this is the only thing that I really use from labels. And of course I understand that each prop is simply wrapped in a function. Actually, this solves the original problem with which the discussion began and greatly simplifies the code. Although of course if you do not understand what is really happening during compilation, then using $destructable from the point of view of JS looks like a useless operation. I just thought that one of the options to solve the problem of props destructuring could be to teach the compiler to do work similar to $destructable, perhaps under some condition (for example, if this is destructuring of the argument of the component function, and not in the body of the component). In any case, this adds unnecessary magic to the way the code is executed, which is not very good, so I understand perfectly well that such a change will most likely never happen. However, I would like to have some alternative to mergeProps + splitProps, because in approximately every component you have to enrich props with default values ​​and separate local props from attributes and this is just a pain and I personally would rather keep in mind the features of $destructuble than describe 2 additional variables (raw/props/local/attrs)

I want to work with a framework with a minimal learning curve, one that you don't need to learn anything to work with, it's enough to know how html/js/css works. And unfortunately, SolidJS is quite complicated in this regard. To start doing things, you need to learn a dozen hooks and keep in mind a number of utilities like splitProps / mergeProps. And stumble upon a dozen or so situations when seemingly absolutely working code suddenly doesn't work.

I think you're gonna find that this is true for every framework. It's impossible to be productive with any framework without going over its learning curve. I would love to be proven wrong though!

But I just don't want to hear from developers that they spent half a working day on another stupid error due to destructuring or the absence of a function in the right place

Again, this is gonna happen with any framework. You're gonna spend days debugging effects and dependency arrays in React just like destructuring in Solid. You can't build a framework that has the capabilities of solid without its learning curve.
I don't think Solid should optimize for day 1 usage. I think it should optimize for day 2 onwards usage. Yes we should try to keep the learning curve as low as possible, but not at the expense of ergonomics for experienced developers. There are other frameworks that prioritize learning curve above all else, we don't need to be that.

Stores can be mutable and return a store directly instead of a tuple

Not a good idea in my opinions, read-write segregation is one of the most important lessons of React. It's how you build scalable applications. By disallowing unpredictable remote mutations. Angular has had this problem forever.

Otherwise, I just don't see the point in making a major release if you're afraid of breaking or changing something. 2.0 should be a rethinking, a new chapter, a large-scale improvement taking into account the experience of using 1.0 by our large dev community

It is a new chapter. It's a ground up rewrite, it's a breaking change, and it's a rethinking of fundamentals. I'd encourage spending some time with the new APIs.

Re. "spending time with the new APIs", where and how can we do this while they're being worked on?

Props as accessors have some issues worth talking about perhaps

It's pretty clear thank you!

@ryansolid, I've read all your articles, and I can tell that you and the Solid team have already carefully thought through all possible solutions. That said, I still have some thoughts about what could be possible in 2.0.

Stores without read-write segregation can be incredibly dangerous as it is basically implicit two-way binding.

I totally get the concern here, but I wonder if this could be mitigated with a strict mode (or just always enforcing strict behavior). It doesn’t seem like a huge leap to make actions/mutations the only way to change store state. In fact, the setter itself could essentially be a batch/action.

Getters becoming Memos is what I did with the first draft of adding them to stores, but there was an issue with them being eager in 1.0, which basically prevented them from self-referencing. This could be considered now that they are lazy, but it would require deep traversal on set, which has a noticeable performance impact. It feels more likely you are looking for something like MobX's makeObservable, which can do things shallowly in a more fixed shape construction. This is a good solution for more specific data types, and nothing in our primitives prevents that. Maybe we can try looking at adding a proposal to Solid Primitives.

It's one of the top things I want to have in Solid.

Because I like to do things like this:
https://codesandbox.io/p/devbox/mobx-observable-state-forked-2mwsx9

const state = observable({
  secondsPassed: initialValue || 0,
  // Real memo
  get secondsPassedFormatted() {
    return this.secondsPassed + "s";
  },
});
const reset = action(() => {

state.secondsPassed = 0;

});
const increment = action(() => {

state.secondsPassed += 1;

});

Regarding the deep traversal concern and performance impact, maybe it could default to shallow updates but allow optional deep tracking? Or perhaps a decorator-like syntax could mark getters as implicit memos. Also, wouldn’t this ultimately be the responsibility of the user? If performance is a concern, developers can structure their stores accordingly to avoid expensive deep traversals. At least from my experience, I’ve never hit performance bottlenecks with MobX stores, even when relying on getters.

Another area where I find the current store API a bit tricky is the setter method—it has a somewhat complex signature, and it’s not always intuitive to remember how to use it, especially for deeply nested updates.
https://codesandbox.io/p/devbox/solid-createstore-1-forked-v4jytl

Using actions and pure JavaScript mutations often feels more natural.

setState(
  produce((state) => {
    state.a.b.c = 1;
    return state;
  })
);

Because of these quirks, I often default to using signals + memos instead. But while signals are great, they don’t feel as elegant as stores—everything ends up being wrapped in accessors, which makes the code a bit cumbersome:
https://codesandbox.io/p/devbox/solid-createstore-forked-9cldj3

This might not seem like a big deal in small examples, but in larger stores, it can become a real pain. And the downside of using memos is that I lose the ability to leverage reconcile for efficient array updates.

I really appreciate all the work you and the team have put into Solid — it's already an amazing framework. Just wanted to share some thoughts on what could make stores even better. Thanks for everything you do! 😊

Yeah hear you. Stores are also getting some love. While I've personally always liked the directedness of the path API in Store setters. The plan for 2.0 is for produce to be the default way we update stores. It's like actions except the ability to update is still controlled from the source.

Most of the other API choices like "a.b.c" type stuff is about performance (ie.. string splitting). Most of the early Solid APIs were microbenched a ton and that dictated things. I should also mention objects auto merge in the current Store API.. so people should be doing spreads like your example. It is unnecessary.

Like this is never necessary:

// This looks fine but won't work if prev contains a getter:
setState((prev) => ({ ...prev, count: prev.count + 1 }))

Instead:

// This is the same
setState(prev => ({ count: prev.count + 1 }))

// This is also an option:
setState("count", prev => prev + 1)

Although again in 2.0 it would just be:

setState(store => { store.count++; })

One of the cool things we do is look for a $PROXY symbol when wrapping/unwrapping so if people have custom store implementations... like shallow observable like things we can support those APIs and them be interchangeable. I haven't seen examples of this out in the wild(as it isn't exactly documented) but it keeps things pretty flexibility if someone wanted to make a library to do that.

Or is "run-once SSR" a new name for resumability?

No. It's still on a longer term plan but there are more impactful changes we can make before that. The async stuff and the change in rendering approach can serve as a better foundation.

Like Svelte, probably not, but View Transitions(like Astro) are something we are looking at. Although it might look at bit different from an API standpoint.

I think many (all?) of them were covered in Ryans stream two weeks ago
https://www.youtube.com/watch?v=xnmvxWEK25I

The stream has chapters now so you can hopefully find what you need with the help of those.

Things like that should never be landed in the core functionality of any framework - it just doesn't make any sense. Just implement some sync logic between your store and [whatever you want to store your data in]. I don't see any restrictions on why it couldn't be done with a couple of lines of code.
Just ask CGPT for this, it creates something like this for you (with localStorage):

import { createStore, produce } from 'solid-js/store'
import { onCleanup } from 'solid-js'

export function createPersistentStore<T extends object>(
    key: string,
    init: T
): [T, (fn: (prev: T) => void) => void] {
    const stored = localStorage.getItem(key)
    const initial = stored ? JSON.parse(stored) : init

    const [state, setState] = createStore<T>(initial)

    const save = () => {
        localStorage.setItem(key, JSON.stringify(state))
    }

    // Intercept all setState calls
    const wrappedSet = (fn: (prev: T) => void) => {
        setState(produce(fn))
        save()
    }

    // Listen to storage changes from other tabs
    const sync = (e: StorageEvent) => {
        if (e.key === key && e.newValue) {
            setState(JSON.parse(e.newValue))
        }
    }
    window.addEventListener('storage', sync)
    onCleanup(() => window.removeEventListener('storage', sync))

    return [state, wrappedSet]
}

You might be looking for this instead
https://primitives.solidjs.community/package/storage

I appreciate that @devagrawal09 . That's the one I actually mentioned above. In my web projects I resort to using the session helpers start provides out of the box.

Storage API itself doesn't translate well across JS runtimes. This deserves a userland implementation, not a built-in one.

Depending on your requirements, you might not even need a router. We should aim for solid-cli to cater for more different scenarios.

Router is a very high level library compared to the underlying reactivity and rendering engine. It brings a lot more opinions around app structure, data fetching, cache invalidation, search params, and server rendering. It's a separate concern from how you write your UI components. We want to encourage the community to innovate and find the best patterns in routing separate from rendering. Solid router exists as a first class citizen of the ecosystem, but it's also a template that you can follow to build your own routing library to your exact specifications. It also allows the core of solid to build the best composable patterns that make it easy to build your own router, which would not happen if the router was assumed to be part of the core framework, because it would discourage the use of internal APIs that make it easy to build your own opinions on top.

Look at it this way - solid being fully router agnostic is what allowed an easy integration with tanstack-router, which is a state-of-the-art library for the typescript ecosystem.

Look at it this way - solid being fully router agnostic is what allowed an easy integration with tanstack-router, which is a state-of-the-art library for the typescript ecosystem.

@devagrawal09 Would you recommend TanStack router over Solid router?

It's tough - both are very very similar to each other, and there isn't really anything that one can do that the other cannot.
Tanstack router is very light on data caching and revalidation capabilities, but it more than makes up by integrating deeply with tanstack query.
Tanstack query can do all the fancy stuff solid router can and more. Very soon tanstack start will support single flight mutations as well, and that point tanstack (start + router + query) is just a better version of solid (start + router).
If you're starting a new project, I'd definitely recommend tanstack router if just for its typesafe api.

There are other design considerations. Nothing definitely precluding but a lot of work in Solid Router went into designing in a way that would support future partial hydration-based solutions. Things that impact API shape. Things like form and anchor based event delegation, the use of props.children for outlets.

I think the other consideration here is that Tanstack Query while more featured also assumes a lot more, and is heavier. The primitives underlying both solutions should the same in the future but the shape of the API has impact on composability. Again it was because Solid Router pieces largely looked as building blocks and potential core inclusions where Tanstack is a framework agnostic product.

I think the type safety is very compelling, enough that I'd seriously consider it for projects. But I do wonder if the solution of using these all together is too opinionated to be flexible enough to serve as the minimal basis. This seperates the design philosophy of the projects. Solid Router and most core libraries asks what is the least we can ship with that gives people all the functionality or the ability to build all the functionality they can need. Tanstack more asks what should a full featured solution look like.

It is a very challenging problem. I can see a path now that gets us there but it is about 3 steps removed from the current work. First we shape our different compiled outputs to generate the same graph, next we add reactive graph serialization(precursor for resumability as well), then we implement reactive graph restoration during hydration, and then we do something similar for HMR.

Most of the newly added methods seems to be unnecessary in Solid.

totally agree, was just an example to illustrate that render APIs can change between major versions of mainstream libraries, would like to know more about solidjs 2.0