The Road to 2.0

[ryansolid]

Hello everyone. I'd like to officially announce the beginning of our journey to Solid 2.0. We've done a lot of prototyping over the last few months and feel like we've gotten to a place where we can official start the process of developing Solid 2.0!!

For Solid 2.0 we are looking at features in a few key areas:

• Fine-grained non-nullable async
• Mutable derivations
• Flush boundaries
• Derived signals
• Lazy memos
• Automatic batching
• Immutable Diffable stores
• Self-Healing ErrorBoundaries
• Concurrent transitions
• Streamlined JSX prop/attribute handling
• Pull-based run-once SSR

If you don't know what all of these are that's ok. This will take several months to complete and include multiple phases, the first we just entered as of today. You will be able to track the progress on the #next branch of the repo and on npm.

Experimental (2.0.0-experimental.x) - COMPLETE

This is where are today where we have an idea of what the client-side behavior is and are testing and finding holes with our assumptions. This phase is largely self-guided and will break even significantly between versions. It's even possible for previously published experimental versions to break due to dependency updates. Consider only the latest release of all related packages as truth.

The goal of this phase is to re-implement the equivalent of all client, ssr, and hydration for non-experimental 1.0 features, as well as implement any new features we feel are core to the experience. This requires a lot of experimentation and benchmarking. We are being aggressive during this phase so it may even include breaking changes that will never get into the final release. It is possible there will be performance regressions. This is about capability.

Alpha (2.0.0-alpha.x) - SKIPPED

This is the next stage when we feel the core behavior is presentable. This is when we will be writing up the formal RFCs and asking for more community feedback in terms of designs. The project should work with its base features end to end at this point but there are still opportunities for APIs and behaviors to wildly change between releases. We will use the feedback from the RFCs to hopefully bridge any gaps.

The goal of this stage is to have important core projects (Router/Start), infrastructure, and examples working with the 2.0 stuff to vet that the approach handles all the cases.

Beta (2.0.0-beta.x) - CURRENT

When we are content with the design and proposed implementation we will run a wider beta so that ecosystem libraries can try the new stuff. This is also when focus will be put on migration efforts(code mods) and documentation. At this point the API should be mostly stable but it will be possible that some behavior changes need to be tweaked. The goal of this phase will be to have the popular libraries like UI Components such as Kobalte, etc... and agnostic projects like Tanstack working with the 2.0 updates.

RC (2.0.0-rc.x)

These will be release candidates ready for final release.

Timeline

Given that we are in the experimental stage timeline is not available currently. It is really going to depend on how much help and feedback we get and how well we are able to address it. I will continue to reach out and provide updates to the community as the process continues. If you want to get involved in the day to day. Come the #next channel in Solid's discord. That is where all the relevant conversations are happening.

And with that, I want say it is a really exciting time and I hope you all join us on this journey to push the boundaries of frontend at their foundations.

Best,
@ryansolid and the SolidJS Core Team

[everton-dgn]

What specific improvements are being planned for the handling of props, JSX attributes, and destructuring in SolidJS 2.0? Will this include simplifications for working with spread, binding, conditional logic, or destructuring directly within JSX?

[kachurun]

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)

[devagrawal09]

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.

[joodaloop]

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

[dominictobias-bullish]

I'm curious how Svelte allows destructuring and default assignment on props whilst also being an observable library? It seems they have abstracted the problem away with compiler magic? I know this has been explained ad nauseum, but I feel it's a bigger sticking point than people might think (if not the biggest) to adoption. Working with props in React is just so much more ergonomic, especially if you need to both split and merge, which is very common.

Other sticking points:

• For vs Index confusion - it is just not intuitive to me, again Svelte just has #each which is much clearer and analogous to Array map
• Sometimes needing to access observables as a someState() e.g. from createSignal, while not needing to for props or stores is inconsistent

[ryansolid]

@dominictobias-bullish Yeah Svelte uses its compiler. They have a syntax which makes components easily identifiable vs just other functions so they can localize their transform. I think it sets the wrong precedence. It basically lies about the capabilities of the system. If that is the biggest sticking point people are valuing the wrong things. I can't stop them from doing so, but I'm ok with them learning for themselves the hard way. At certain point denying the truth is just building a house of cards. Look at the whole class handling in Svelte 5. It might be ergonomic but it is representative of the slippery slope I'm talking about. Once you start lying you have to maintain that lie.

Yeah For vs Index is gone in 2.0. This is more of a historical thing. I For had an API that basically prevented Index from working with it, or explicit keyed. This was just because I assumed everyone would want to do referential keyed by default early on. I found a few cases where that wasn't the case so I built a new primitive rather than contaminate For. I was literally counting every nanosecond, and byte of code at that point. Honestly adding like 6 LoCs to cover both cases is trivial.

The accessor vs function thing is just JavaScript. Might be worth reading this to understand a bit why both should exist: https://www.reddit.com/r/solidjs/s/9hJ75MIpnh

[ryansolid]

@kachurun Thinking on what is possible and not being concerned initially with migration is exactly how I approach this. This isn't about fear of change.

The problem with this stuff is it isn't a new problem, and in so many of the "solutions" aren't new. Many even predate Solid itself. So much so I find myself explaining why certain things don't work repeatedly. I'm happy to have the conversation over and over in hopes we gleam something new from it. We discuss this stuff on the discord all of the time.

Solid's approach while novel from a popularity standpoint when I started was not that unique. Tools tried decorators + classes (very popular circa 2015). Tools tried purely Signals. Solid was actually created largely with the expectation everyone would use stores, and evolved from there. However we did something right to get this far. Obviously I'm biased as these are opinions I've formed using Signals the past 15 years.

More than happy to look at specific concerns. Props as accessors have some issues worth talking about perhaps: https://www.reddit.com/r/solidjs/s/9hJ75MIpnh
Stores without read-write segregation can be incredibly dangerous as it is basically implicit 2-way binding(see 2-way Binding is a 2 way street). That being said making the mutable setter the default is in the plan for 2.0.
Getters becoming Memos is what I did with the first draft of adding them to stores but there was a 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 noticeable performance impact. It feels more likely you are looking for something like MobX makeObservable that can do things shallowly in 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.

There is a non-compiled destructure helper in Solid Primitives that returns functions. If that is preferred way of setting defaults we can talk about. Something like:

const { cond, class: className } = toAccessors(props, { cond: true });

But that doesn't help with rest params as having an object of accessors won't spread properly. So still 2 helpers needed. It isn't all that different than mergeProps. If props is a proxy so does the returned object need to be to support changing shapes.

[kachurun]

Props as accessors have some issues worth talking about perhaps

It's pretty clear thank you!

[kachurun]

@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

Long story short

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.

Why?

// Why does this syntax work?
setState("a", "b", "c", value)

// But these don't:
setState("a.b.c", value)
setState("a/b/c", value)
setState(["a", "b", "c"], value)

// Why does this merge data but only shallowly?
setState({ b: 1 })

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

// And how do you update something deep inside? Make a full clone of the object and then reconcile? Sounds like an extremely hard deep traversal.
// Exactly! You just need to learn one more helper!

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! 😊

[ryansolid]

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.

[PeterDraex]

Resumability didn't make it into the plan? 🥲
I'd trade all of these for it, as it improves UX and not just DX

[PeterDraex]

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

[ryansolid]

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.

[everton-dgn]

@ryansolid Do you have any plans to improve animation support in Solid? Something like Svelte’s API, which makes declarative animations easy and integrated, or even something similar to what Astro offers?

[ryansolid]

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.

[tslocke]

If you don't know what all of these are that's ok.

Any pointers on where to learn?

[oskbor]

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.

[caseybaggz]

I know this convo is old and stale by now but I was thinking today that it would be really nice for createStoreto have optional caching built in. I know we have the storage primitive but I got spoiled building a Tauri app last year (i.e. no browser refreshing).

Like, if we could pull off an API option that just allows us to do the same thing as the primitive without the promises/issues around the template2 rendering...would be very nice:

interface PermissionsStore {
  workspaces: Record<Workspace['id], Workspace['role']>
  repositories: Record<Repository['id], Repository['role']>
}

const [store, setStore] = createStore<PermissionsStore>({
  workspaces: {},
  repositories: {}
}, {
   cache: true,
   storage: 'session'
})

Ran into this today going back into browser land.

If there is already a way to do that which I'm ignorant of...please enlighten me! 🙏

[kachurun]

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]
}

[devagrawal09]

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

[caseybaggz]

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.

[lxsmnsyc]

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

[varunpereira]

1. Setup would be easier if we got rid of root prop in Router component. Rather have it like before where we put our app as a child of Router component.
2. Installing would be easier if we had the router package in same solidjs package.

[atk]

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

[devagrawal09]

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.

[PeterDraex]

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?

[devagrawal09]

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.

[ryansolid]

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.

[paulm17]

Since a new release is being seriously discussed. I'd like to know the thoughts of HMR.

I came across this thread: #2419

Will HMR be seriously tackled and resolved? So that it matches React?

Many thanks!

[ryansolid]

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.

[chrswk]

I'm considering using SolidJS (just client side use of "Core" and some Solid Primitives) for a long term project. When the time comes to update the code from 1.x to 2.0, where do you expect (at this point in time) the required migration effort to land on a scale from "two core method signatures changed" vs. "due to conceptual changes in how things should be done in 2.0 you need to rewrite large swaths of code"?

I watched parts of the excellent Signals 2.0: The Future of Signals stream and (from my currently very limited knowledge of SolidJS) it sounds like 2.0 will land more on the "simpler" side of that spectrum. Obviously there are things one can already do to make this easier, eg. from what I've gathered using produce with stores, etc. Are there any other tips that would make the migration easier?

Thanks
Chris

[Atulin]

I'm loving Solid so far, especially when used to author webcomponents. Whatever changes v2 may bring, my wishlist is pretty short all things considered:

• Don't bloat the size too much, I'd rather my bundle size not double just because of a migration to v2, no matter how many cool new things it adds
• Don't break the webcomponent support, I would hate having to either stick to an unsupported version of Solid or having to migrate my webcomponents to something else

[ryansolid]

Thank you. Both of these are definitely top of mind. There will be some size increase because of changes to the fundamental reactive system. Most features are very treeshakable but async ones are not. But unless your application is literally hello world it won't impact your bundle size percentage wise in any sort of noticeable way.

[avarun42]

Are we still in the "experimental" stage today? Are there any more recent updates?

[3xau1o]

can we expect universal rendering 2.0 breaking changes? React 19 added changes to the reconciler, changes can be expected for evolution @ryansolid

[lxsmnsyc]

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

[3xau1o]

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

[cosoc]

太棒了，我觉得solid以后会是前端框架看齐的标杆。

[foreturn]

Nice!

[dennypenta]

if I want to use solid2 experimental tag, where is the docs I should rely on? can't see a version switcher on the website.
shall I run docs server locally to read new API?

[atk]

You could try solid-js@next, but the experimental version is highly experimental and prone to break/change a lot at the moment.

[SDAravind]

Any update on solidjs v2 release candidate in 2026 Q1?

[sanguogege]

2.0 beta is out now,

[thanhdatvo]

@sanguogege Cool! How could we access 2.0 beta? Could you provide us more information?

[Shinigami92]

https://www.npmjs.com/package/solid-js/v/2.0.0-beta.0
Looks like just set the version in you package.json to 2.0.0-beta.0

[ryansolid]

More info here: https://github.com/solidjs/solid/releases/tag/v2.0.0-beta.0

[mathieuprog]

It’d be great to get solid-router working in 2.0, since it's hard to use 2.0 for projects without it

[teleskop150750]

Now, after dividing the effects into two phases, should I duplicate the conditional logic in the calculation function and the application function?

// 1.x (single function effect)
createEffect(() => {
  const enabledVal = enabled();
  if (enabledVal) el().title = name() + count();
});

[ahzvenol]

I was able to come up with this within seconds of looking at the original snippet. I understand that it might require "extra thought" in the beginning, just like it requires extra thought to learn how to derive data using signals for someone who has never used signals before. But once you're over the learning curve it should come to you pretty naturally.

Perhaps it is true that after learning, it can become easier to handle, but it still introduces extra friction without a clear, proportional benefit. This is perhaps the central issue of the current debate: Vue 3 and Svelte 5 both adopted automatic dependency tracking in their major updates to simplify their mental models. Solid used to be the leader in this regard, yet it is now moving in the opposite direction.
A framework's evolution should ideally make code more concise and concepts easier to grasp. Instead, this shift increases learning overhead and cognitive load. What is the fundamental necessity that justifies asking developers to accept this regression in ergonomics?

Not sure what you mean? Do you have examples of edge cases not handled here?

An empty string is treated as false, causing the code inside the if block not to run. This may not occur in this specific use case, but in other cases it could. To avoid passing enabled(), this approach takes a detour, making the code less clear and its correct execution dependent on specific business logic.

This simplification sacrifices robustness. Once the logic is corrected by passing the condition explicitly, the API's verbosity brings us right back to the complex code in my example.

Single variable cases can actually be simplified to createEffect(s, s => ...), reducing the boilerplate.

I missed that. Perhaps a slightly more complex example would better illustrate the issue, and the complexity builds up quickly as the code logic grows.

[devagrawal09]

Vue 3 and Svelte 5 both adopted automatic dependency tracking in their major updates to simplify their mental models. Solid used to be the leader in this regard, yet it is now moving in the opposite direction.

The first function of createEffect still tracks deps automatically. The only difference is that there is now a second function where you actually perform the side effect. We're not losing the ability to track dependencies. We have simply moved the side effect to a separate function.

A framework's evolution should ideally make code more concise and concepts easier to grasp.

The way we achieve this in Solid 2.0 is by removing the need to use createEffect for a majority of the use cases that you might have needed effects for today. You will find yourself reaching for effects a lot less than before once you have a grasp of the new system. In the grand scheme this makes everything simpler and more concise by eliminating effects from your codebase.

What is the fundamental necessity that justifies asking developers to accept this regression in ergonomics?

The RFCs dig into this in a lot more details, but the tl;dr is that since signals can throw if there is unresolved async work, single function effects can have unpredictable execution. Splitting the pure from the effectful is the only way to guarantee that the side effect only runs once and runs completely.

An empty string is treated as false, causing the code inside the if block not to run.

This would be an issue in the original snippet as well though, so what you're describing is not an issue with the effect api, but a logic issue in the implementation. All I did was rewrite the exact same behavior from the example snippet using the new API. You would address this issue in the exact same way in both versions - adding an explicit check for the empty string like so enabled() === "" || enabled()

Perhaps a slightly more complex example would better illustrate the issue

If you can come up with some I would be more than happy to demonstrate how to easily convert them to the new API without causing extra complexity or verbosity.

[ahzvenol]

The first function of createEffect still tracks deps automatically. The only difference is that there is now a second function where you actually perform the side effect. We're not losing the ability to track dependencies. We have simply moved the side effect to a separate function.

Perhaps I wasn't clear enough. Specifically, splitting createEffect into two phases makes the side-effect code unable to rely on the branching information within the pure function. This is why the code above requires passing the condition, and it also results in the need to pass variables between functions instead of using them directly.

I usually consider dependency tracking in the single-function createEffect to be truly automatic. In contrast, the split-phase API feels more like a way to declare a dependency array because the side effect cannot be run within the tracking function itself. This is similar to the relationship between Vue 2's watch and Vue 3's watchEffect, whereas the expectation for a reactive framework is that tracking should happen implicitly through usage.

The RFCs dig into this in a lot more details, but the tl;dr is that since signals can throw if there is unresolved async work, single function effects can have unpredictable execution. Splitting the pure from the effectful is the only way to guarantee that the side effect only runs once and runs completely.

I recall seeing some discussions about this in the past, but I don't remember the specifics now. The Reactivity & effects section in the beta announcement only briefly mentions the change without elaborating on the specific cases. If you have any relevant links or would be willing to explain, it would be very helpful.

This would be an issue in the original snippet as well though, so what you're describing is not an issue with the effect api, but a logic issue in the implementation. All I did was rewrite the exact same behavior from the example snippet using the new API. You would address this issue in the exact same way in both versions - adding an explicit check for the empty string like so enabled() === "" || enabled()

The original code was structured like this, with the enabled variable separate from the data assignment:

createEffect(() => {
  const enabledVal = enabled();
  if (enabledVal) el().title = name() + count();
});

Your version was like this:

createEffect(
  () => enabled() ? name() + count() : null,
  (title) => {
    if (title) el.title = title;
  }
);

I think you might have overlooked something: in the original code, an empty string for the title would not interfere with the conditional check

[ryansolid]

I get the concern and it definitely requires a little bit more thinking. Things that funnel down to a single side effect generally are still pretty straight forward. Obviouslyl I can picture scenarios that are trickier. I'm sure you can too. We will need to think about patterns we can generalize here.. one suggestion was that we pass the effect through obviously not needed for your simple case (some variation on Dev's approach seems fine).. but to illustrate.

createEffect(() => {
  if (enabled()) {
    const title = name() + count();
    const ele = el();
    return () => ele.title = title;
  }
}, (effect) => {
  effect?();
})

But you probably would probably just do what Dev did even if it meant the element overtriggered in most cases. I'm not going to say it isn't more of a pain for these sorts of things but the design is inevitable.

I've written about it some more here. Really worth a read if you want to know why. I don't propose this stuff on a whim. I understand the consequences all too well. But I'm also not god, and don't define physics.
https://dev.to/playfulprogramming/two-react-design-choices-developers-dont-like-but-cant-avoid-d6g

[teleskop150750]

I would try using a nested effect for simple cases.

[ahzvenol]

First of all, thanks for all the work on Solid 2.0. I’m very excited about the new version, but I have a few concerns about some of the upcoming changes.

1. The single-function createEffect

The single-function createEffect works very well in practice. Automatic dependency tracking covers most use cases, and frameworks like Vue.js and Svelte also provide primitives based on automatic dependency tracking.

Switching to the new split-phase API feels cumbersome, also making patterns like tracking B or C depending on A harder to express and nested reactive logic less clear than with automatic tracking.

If there are scenarios the single-function createEffect can’t handle, the two-phase version could be offered as an opt-in, similar to how on(...) is used today, only when explicit dependency control is needed.

A quick GitHub search shows roughly 51.2k usages of createEffect, but only 1.3k of createEffect(on(...)), meaning explicit dependency control is needed in well under 5% of cases. The common case shouldn’t be penalized for the edge case.

2. “Values update after flush”

I’m also concerned about “values update after flush”, which introduces inconsistent state reads, as writing to a signal does not immediately affect subsequent reads and forces developers to treat reactive values differently from normal variables, breaking the intuitive mental model of Solid 1.x.

Frameworks like Vue.js and Svelte also batch updates internally, but their reactive state values are immediately visible upon assignment, with asynchrony limited to effect scheduling or DOM updates rather than delaying the state reads themselves.

The concise and coherent design of SolidJS is a key reason I appreciate and use the framework, and I hope it does not become conceptually and practically cumbersome like React. For most frontend applications, absolute peak performance is rarely the primary constraint, while Developer Experience and productivity are equally important.

[ryansolid]

It feels unlikely. The compilation needs to serve a purpose otherwise it is basically lying to the developer. The biggest issue with these sort of transforms is they obscure the actual behavior in a way that doesn't prevent you from still needing to know that behavior. Which is unfortunate because it can trip up people learning or force things down further abstractions to try to mask the reality(see Svelte's use of classes). All to save writing 2 characters or allow destructuring.

[ahzvenol]

Perhaps the changes to createEffect aren't as bad as I initially thought, and the community will eventually provide fair feedback after the 2.0 release. Regardless, at least an equivalent migration of the code to 2.0 is feasible. But regarding read-after-write inconsistency, I hope we can do something here. It truly breaks some things, and I don't know if there is a way to patch it.

I have always been following how to achieve consistency between reactive variables and plain variables, which is a broad focus in the community. Svelte has done a lot of work in this area, Vue once experimented with $ref, and the .value requirement of ref is often discussed. Solid also has some community compiler plugins, and even this thread is still discussing how to make reactivity simpler. I understand the difficulty of simplifying reactivity and was satisfied with the state of 1.x, but 2.0 is heading in an unexpected direction.

I checked Discord today and found that my use case is similar to Brendan’s. We both want to treat reactive objects as plain objects, where we don't care whether a variable is reactive when using it. If reactive reads do not immediately reflect the latest value, code that relies on this expectation would not work. I am also concerned that deferred reads will lead to subtle, hidden bugs, requiring constant attention to avoid writing incorrect code. This is a long-term hidden risk, and it becomes even more troublesome considering the need to migrate existing code.

[ryansolid]

Yeah it's hard. The long term risk was always the approach you've taken. The expectation that reactive variables are unrecognizably different than plain variables was never something that could be true. It was a convenient side effect of syncronicity in some cases but never a general rule that could be followed. I've been aware of this since before I even created SolidJS. I tried to impress these values on our API design but people keep on pushing on that direction. At a certain point the curtain drops.

I've written about this a decent amount in my hackmd's the last year. But I've finally published an article that clarifies this a bit more: https://dev.to/playfulprogramming/two-react-design-choices-developers-dont-like-but-cant-avoid-d6g

[kachurun]

For me all of this feels unnecessarily complicated. Solid 1.x is complex. React is complex. Svelte is complex. The complexity is different in each case and comes from different reasons, but in all of them the mental model feels broken.

I also don’t understand why everyone keeps reinventing MobX over and over again, when the result is usually not better.

In reality, to build a reactive application of any complexity you only need four primitives: observable (signal/store), computed, action, and reaction.

Any function executed inside a component should effectively behave like an action, meaning that all state updates inside it are automatically batched. Changes to observables should be applied immediately, but effects should run only after the action is finished. Computeds should be lazy.

In Solid 1 I never understood why createEffect is so uncontrolled or requires the awkward on() syntax. It behaves more like a high-level mobx.autorun. What I want instead is control: I want to explicitly specify the dependencies of my effects. At the same time I don’t want to think every time about which comparer it will use. I would expect shallow comparison for arrays by default. So I just expect like mobx.reaction. If Solid 2 behaves like that, I actually really like that direction 👍.

The second thing I never understood in Solid 1 is why updates are applied to the DOM immediately and I have to manually batch changes.

When I write code like this:

setLoading(false)
setItems(['foo', 'bar', 'baz'])

I absolutely do not expect that between these two operations the framework might execute a huge amount of code, like rendering of the entire application due to loading == false, and it suddenly starts mounting everything in between these two lines. That seems completely insane.
Yes I know batch() exist, but automatic batching with an optional flush, like in Solid 2, makes much more sense 👍.

But personally, I would even expect that values can be read immediately (as @ahzvenol suggested), but the actual effects, rendering, and DOM updates happen only at the end of the action. Whether that happens after actual action/batch done, inside requestAnimationFrame, a render cycle like React, or some other scheduling mechanism is not that important for the developer’s mental model. Update happens sometime, just wait for it or call flush() manually.

The interesting question, of course, is how the framework should determine where an action boundary ends.

Here is an example of how MobX behaves. Just imagine that console.log('Render') in the reaction represents a real component render in the DOM OR the code inside a createEffect():

const count = mobx.observable.box(1);
const double = mobx.computed(() => count.get() * 2);

mobx.reaction(
  () => [count.get(), double.get()], 
  ([count, double]) => console.log('Render', {
    count,
    double,
  }), 
  { fireImmediately: true }
)

count.set(2);

mobx.action(() => {
  count.set(4);

  console.log('Inside action', {
    count: count.get(), // 4
    double: double.get(), // 8 <-- recomputed immediately
  });

  count.set(8);
})()

mobx.action(() => {
  count.set(8);
});

// Logs:
// Render {count: 1, double: 2} <- Initial reaction
// [MobX] Since strict-mode is enabled, changing (observed) observable values without using an action is not allowed. 
// Render {count: 2, double: 4} <- First change not in action, warn above
// Inside action {count: 4, double: 8} <- Manual log, computed recomputed
// Render {count: 8, double: 16} <- After action complete
// Last `count.set(8)` doesn't change the state so we wont have any logs here

So the effect runs only after the action completes, while individual signals and computed values are available immediately. For me it’s hard to imagine a more intuitive model than this.

[kachurun]

For me it’s not entirely clear why a framework needs to be this declarative.

In practice, what I really want is simply to render the UI from the current state, without all the complexity around asynchronous orchestration. For example, I never really understood why I should use createResource together with Suspense. I did try to use them, but the behavior always felt unpredictable. The code may end up shorter, but it becomes harder to understand.

I’m talking about real-world situations. For example, imagine you have:
a list of pages
a list of folders
a separate list of deleted pages
another list of some other entities
an active folder
sorting of folders
sorting within folder (including manual sorting)
filters and search of pages inside folder

Trying to assemble all of that inside a component or provider and juggling createResource together with a bunch of computeds on top becomes quite complex and not very pleasant.

In fact there is no way Suspense will work as expected. Here is a very simplified example:

function Example1() {
  const [number, { refetch }] = createResource(fetchNumber);
  const double = createMemo(() => number() * 2);

  return (
    <div>
      <h3>Suspense inside (you will never see loading state)</h3>
      <Suspense fallback={<p>loading...</p>}>
        <p>{double()}</p>
      </Suspense>
      <button onClick={() => refetch()}>refetch</button>
    </div>
  );
}

In the end I usually throw all of this away, create a proper MobX store with actions and flags, and replace Suspense with Show. This is more or less what I end up doing every time, which is why I personally consider createResource not very useful.

Something like this somewhat strange but working example instead. In practice the store would be on Mobx and either moved into a proper SSOT store or wrapped in a provider rather than living inside the component:

function Example2() {
  const [store, setStore] = createStore({
    loading: true,
    number: 0,
    get double() {
      return this.number * 2;
    },

    async fetch() {
      setStore("loading", true);
      setStore("number", await fetchRandom());
      setStore("loading", false);
    },
  });

  onMount(store.fetch);

  return (
    <div>
      <h3>With store</h3>
      <Show when={!store.loading} fallback={<p>loading...</p>}>
        <p>{store.double}</p>
      </Show>
      <button onClick={() => store.fetch()}>refetch</button>
    </div>
  );
}

Yes, this is more code, but it gives much more control. In real applications that level of control is usually more important than saving a few lines.

It seems that @ryansolid is trying to address some of these issues in Solid 2, and on one hand I’m very happy about that. On the other hand, I’m a bit afraid to imagine how many complications this introduces inside the framework itself. The issue where a signal value cannot be read until the current action finishes (in MobX terms) or until the next cycle (render cycle? in React terms) is just one example of such problems.

In a sense, many of these problems exist because SolidJS tries to handle this category of problems in the first place. In my mental model it’s not strictly necessary for the framework to support this async things and to have stuff like createResource or Suspense at all.

Personally I would be perfectly happy if the framework focused mainly on working with the DOM and avoided trying to do too much. Ideally it would provide convenient stores (for example where getters automatically become memos, functions become actions/batches, etc.) and a simple, predictable model for working with the DOM. For example, I’m actually happy that the strange attr: directives are gone.

From there I can build applications of any complexity on top of that foundation.

But Ryan is the artist here, and ultimately it’s his decision how the project evolves.

[kachurun]

Found the time to read all RFCs and build my opinion and early review and comments.

It's a great job, guys, and I really like the overall direction of Solid 2.0. The strongest part of this release, in my opinion, is the broader effort to simplify the API surface and remove redundant concepts. Solid 1.x had too many places where the API felt more fragmented than necessary. Solid 2.0 seems to be moving in a much healthier direction.

What I like the most:

First of all, I like the DOM and API cleanup. I really like the removal of things like use:, attr:, bool:, and for sure class and classList now work the same as clsx, that's great! In the same spirit, I would even prefer removing on: as well and keeping camelCase handlers as the single event API. Users could always bind event handlers manually in some specific use cases. Or some syntax with object and like delegate options could be used: onClick={ { delegate: false, handleEvent(e) { console.log("Weeeee!") } }.

I also like the renaming and cleanup around helpers such as mergeProps → merge and splitProps → omit. The new names are shorter, clearer, and more general-purpose. But since omit now exists as a general helper, it would also make sense to provide a symmetric pick helper. What do you think? In many cases, selecting a subset of keys reads more clearly than excluding the rest.

The unified For API is also a great improvement. Having both For and Index was confusing and felt unnecessary. A single For with explicit keyed behavior is much easier to understand and aligns better with how list rendering works in other frameworks. Repeat seems nice as a convenience, but I am less convinced it belongs in core. It feels simple enough to live in solid-primitives, not in core.

I like derived writable state. Allowing a signal-like primitive to be derived from a function is a very appealing idea and removes a lot of boilerplate for “derived but locally writable” cases. Also, it's great that createComputed was removed. But the docs should be clear about how it will work. For example, if I write a local value through the setter and then the source function re-runs, my expectation is that the derived computation wins and resets the local value, right?

Related to that, the change with derived signals makes the boundary between signals and memos less obvious than before:

const memo1 = createMemo(fn);
const [memo2] = createSignal(fn);

So if signals can also be function-derived, then why do we even need to have createMemo in the API, except as just sugar syntax? Or will it actually behave differently?

The async changes are great if they work as I expect. Removing createResource is a very good decision. Just letting createMemo return a Promise feels elegant and significantly reduces the API surface. So we could do it with signals as well. I also like the name Loading over Suspense. Suspense carries too much React baggage and leads people to assume React semantics. Loading is simply clearer and more honest.

One question I would really like clarified is whether async memo composition works through the graph now and whether this code will finally work:

const count = createMemo(async () => await fetchCount());
const double = createMemo(() => count() * 2);

return (
  <Loading fallback={<p>loading...</p>}>
    <p>{double()}</p>
  </Loading>
);

If the reactive graph correctly propagates suspension here so that double() also suspends until count() resolves, that would be extremely powerful and would make async composition feel truly first-class in Solid. If it does not work, then I don't understand why all of this effort was made.

I also like the idea of automatic batching and microtask scheduling overall. In general, I expect rendering and effects to happen once the graph settles, not eagerly after every setter call. However, the fact that a signal read immediately after a setter still returns the previous committed value until flush() is called feels very unintuitive to me, and this is probably the most controversial part of the whole proposal from a DX perspective. A signal conceptually feels like a value container, so after calling setCount(1) I naturally expect count() to return 1 immediately, even if reactions are still batched. This is how MobX behaves, and that mental model is much easier to understand. React's delayed state reads are already a major source of confusion, but at least in React there is a visible explanation in terms of component re-execution and closures. With Solid signals, the value looks like a direct mutable container, so “the setter was called but the accessor still returns the old value” is much harder to justify intuitively. I suspect this will generate a lot of questions from developers.

I understand the motivation behind renaming onMount to onSettled. It better matches the new async and scheduling model. But from a developer perspective, onMount is a very clear and useful name for a very common case: “run this when the DOM is mounted and I can touch it.” In many real situations, I need that hook for focusing an input, measuring layout, initializing a third-party library, scrolling, and so on. I do not care whether the reactive graph is “settled”. I care that the DOM exists. Because of that, I think removing onMount is questionable. At the very least, keeping onMount as an alias for ergonomics and migration would make sense.

The split createEffect API, on the other hand, looks excellent. Separating the tracking and computation phase from the side-effect phase feels very logical and gives much better control than before (if not use on()). It also makes the behavior more explicit and should reduce accidental dependency capture.

I also really like removing createComputed because the distinction between createComputed and createRenderEffect has always been one of the confusing parts of the API. I am ready to swear very few people can explain those differences confidently, and having several very similar primitives just creates more questions.

The store changes are also very strong. Draft-based store updates by default are a huge DX win, and writing updates like this:

const [store, setStore] = createStore({ ... });

const handleClick = () => {
  setStore(s => {
    s.user.name = "John";
  });
};

is far more natural than path setters. One thought I had, though, is that if updates are already batched by microtasks by default, it becomes tempting to ask whether stores could eventually support direct mutation as the primary model, more like mobx.observable(), rather than requiring a setter at all? I understand there are probably runtime and consistency reasons not to do that, but from a DX perspective it is very attractive:

const store = createStore({ ... });

const handleClick = () => {
  store.user.name = "John";
};

The derived store APIs createProjection and createStore(fn) were one of the hardest parts of the RFCs to understand. They seem to solve very similar problems, so it is not entirely clear why both are needed. If one is mainly about keyed reconciliation and the other about a more general derived store shape, that distinction should be explained much more explicitly. Right now, they feel like two overlapping APIs where users will immediately ask which one they are actually supposed to use and when.

The unclear part of the proposals for me is the whole action and createOptimistic and createOptimisticStore area. Right now, this part feels much less clear and much less compelling than the rest.

First, the generator-based action() syntax is unusual for most developers.
Second, the semantics of createOptimistic are not clear enough from the examples in the RFCs. For instance, in this example:

const [name, setName] = createOptimistic("Alice");

const updateName = action(function* (next) {
  setName(next);
  yield api.saveName(next);
});

it is not obvious what should happen after the action completes. Does the value revert back to "Alice" because the optimistic transition ended? If not, then how exactly does this example differ from a normal signal?

This area of the RFC actually feels more like optional syntactic sugar for optimistic UI than something that clearly belongs in the core framework. Or at least it needs clearer documentation so that its value can be properly evaluated. Right now, this is the area that feels most like something I would expect to come from solid-primitives rather than from the core runtime.

So overall, my impression is very positive. Keep going, guys, and thank you for your efforts! 🎉

[kachurun]

Thanks for the detailed explanation, Ryan.

Regarding optimistic updates, I think what’s still missing is a clear example of a typical problem this is trying to solve.

For example, anyone who has built an admin panel has probably written something like this (in any framework):

const [user, { refetch }] = createResource(() => api.fetchUserProfile());
const [saving, setSaving] = createSignal(false);
const [optimisticName, setOptimisticName] = createSignal<string | null>(null);

const displayedName = createMemo(
  () => optimisticName() ?? user()?.name ?? ''
);

async function saveName(next: string) {
  setSaving(true);
  setOptimisticName(next);

  try {
    await api.updateName(next);
    await refetch();
    toast.success('Profile updated');
  } catch (err) {
    toast.error(err.message);
  } finally {
    setOptimisticName(null);
    setSaving(false);
  }
}

Or something like this:

const [user, setUser] = createSignal<User | null>(null);
const [saving, setSaving] = createSignal(false);

function refetch() {
  setUser(await api.fetchUserProfile());
}

async function saveName(name: string) {
  const current = user();
  const oldName = current.name;

  setSaving(true);
  setUser({ ...current, name });

  try {
    await api.updateName(name);
    await refetch();

    toast.success('Profile updated');
  } catch (err) {
    setUser({ ...current, name: oldName });
    toast.error(err.message);
  } finally {
    setSaving(false);
  }
}

refresh();

With optimistic, this could look like (if I understand correctly):

const [user, setUser] = createOptimisticStore(() => api.fetchUserProfile(), null);
const [saving, setSaving] = createSignal(false);

const saveName = action(function* (next: string) {
  setSaving(true);

  setUser(user => {
    user.name = next;
  });

  try {
    yield api.updateName(next);
    refresh(user);
    toast.success('Profile updated');
  } catch (err) {
    toast.error(err.message);
  } finally {
    setSaving(false);
  }
});

The questions that come up here:

• Does calling refresh() trigger api.fetchUserProfile() again, or is it meant to commit/finalize the current optimistic state?

• If it does refetch (I think it does), what if I don’t want to refetch because I’m confident the backend won’t return anything new, and I’m okay with mutating the local state directly? So I ready just commit/finalize optimistic value at some moment and make it just current value.

• If it’s the latter, then how do I explicitly force a reload (i.e. call api.fetchUserProfile() again)?

[kachurun]

I also have a question about the difference between createStore(fn)[0] and createProjection(fn). Are they literally the same thing or not?

At first, I assumed the difference was that createProjection performs reconciliation, while createStore replaces the value entirely (at least when returning a value from the function). But this line confused me:

createStore(fn, initial?, options?) is the derived-store form; it’s effectively “projection store” creation using the familiar store API.

This makes it sound like createProjection is basically just:

const createProjection = (...args) => createStore(...args)[0];

I don’t think that’s actually the case, but I’d like to better understand what the real difference is.

[ryansolid]

setting with await doesn't work because await happens outside of the reactive system so it doesn't really know. But generally at the resolution of an action you are going to set some state.. either the result, or something to trigger invalidation and refetching. So optimistic version is likely:

const [user, setUser] = createOptimisticStore(() => api.fetchUserProfile());
const [saving, setSaving] = createOptimistic(false);

const saveName = action(function* (next: string) {
  setSaving(true);

  setUser(user => {
    user.name = next;
  });

  try {
    yield api.updateName(next);
    refresh(user);
    toast.success('Profile updated');
  } catch (err) {
    toast.error(err.message);
  } 
});

refresh is simply a force recalc. Has nothing to do with action/optimistic etc.. so it will refetch. But happening inside the action means that the action waits for the results of that refetch before completing. And yes you can just mutate it locally instead if you want and the action will complete basically immediately after because there will be no more async. However to do that you will need to make your source writable..Ie seperate from the optimistic:

const [userSource, setUserSource] = createMemo(() => api.fetchUserProfile())
const [user, setOptimisticUser] = createOptimisticStore(userSource);

// now you can refresh the userSource or overwrite it whenever you want.

The source could be projeciton itself I suppose but maybe that is overkill as the optimisticStore will do the diffing anyway.

I also have a question about the difference between createStore(fn)[0] and createProjection(fn). Are they literally the same thing or not?

They are.. Basically like how you can pass functions to signals to make them derived you can pass functions to stores to do the same.. Projection is to Store as Memo is to Signal. So you can be like why have Projections when you has Stores.. and the answer is the same as why have Memo when you have Signal.

[kachurun]

Thank you, Ryan, it all makes perfect sense. It didn’t occur to me that the source could be a memo or a derived signal (I assume that was just a typo in your example above) 👍

However, after looking at the actual implementation, I ended up with almost the opposite questions from the ones I had initially.
I noticed that createSignal(fn) === [createMemo(fn), setter] as mentioned before, while createStore(fn) === [createProjection(fn)].

That leads me to two very similar questions:

1. What is the actual purpose of createSignal(fn) if it is essentially a less convenient version of createMemo?
   Or does the setter in this case not overwrite the signal permanently, but only update it temporarily until fn is recomputed? If that’s the case, then this is probably the main feature I’m looking forward to in Solid 2.

2. createStore(fn) === [createProjectionInternal(fn)]. So why do we even need a public createProjection if it doesn’t provide anything fundamentally different and we can just use the familiar createStore instead?
   I see a potential issue here with additional cognitive load for developers, who now need to keep another API in mind. It also means another page in the docs, and in real codebases both variants will likely appear side by side and cause confusion. In practice there’s no behavioral difference and it’s purely stylistic.
   For example, even in the migration guide, createStore is used, even though createProjection would arguably look cleaner there and avoid extra destructuring.

It would be much more intuitive to me to simply know that, similarly to signals, a store can also be created from a derived function, instead of remembering additional APIs.
A possible counterargument here is that createStore also includes a setter, so creating it in some case is unnecessary and I agree with that, but I don’t think this would have any meaningful performance impact in real-world applications anyway.
Developers will likely stick to what they are already used to, which will most often be createStore.

Do you think it might be better to avoid expanding the public API unless there’s a clear need for it? I might be biased towards keeping APIs minimal, but curious how you see this trade-off. In general, I tend to believe that adding functionality is much easier than removing it later. New methods can always be added in any Solid 2.x release, but they can’t really be removed until Solid 3.

Happy to be wrong here, I’m sure you’ve already thought through the trade-offs in much more detail, just trying to understand the reasoning better 🙂

[ryansolid]

1. Yes that is exactly what it does. It is a temporary override that is overwritten by recompute.
2. Same as 1. Like these are symetrical. createMemo => createProjection, createSignal => createStore. createProjections mutable derived internals are a whole different category of reactivity, and createStore like createSignal happens to have the ability to adopt that if you pass a function.

I'm biased to towards keeping things symmetrical. The same reason you'd use createProjection is the same reason you'd use createMemo. You could argue createMemo is not necessary now that createSignal exists, and go for it, but for the same reason createProjection exists. This isn't adding something that will be removed it is just building a core building block and then recognizing that derived stores can leverage mutable computation the same way derived signals can leverage immutable computation.

For the way I teach concepts this is foundational. It completes the matrix.

                 IMMUTABLE
                     ▲
                     │
                     │
         Signal      │       Memo
                     │
                     │
─────────────────────┼─────────────────────
 WRITABLE            │             DERIVED
                     │
         Store       │       Projection
                     │
                     │
                     ▼
                  MUTABLE

[tiru-r]

@ryansolid solidjs 2.0 will support mobile development? (https://lynxjs.org/) check this vue-lynx (https://vue.lynxjs.org/) you have seperated everything more like a modular approch? Then the way web and mobile app renders different .

if we can get solid js support for lynx then it would be amazing part because other js based frameworks are too complicated!! If you can separate the core and make it more modular then it will open new opportunities to produce better developer experience. Then import thing is it has to be come from the design first

The way lynx works is really interesting because they are using dual thread architecture

[ryansolid]

I mean Solid 1.0 supported mobile development. Everything is modular. We have NativeScript and Tauri starters. We've had the capability to do universal renderers since 2021, and have ones for Television UIs, WebGL, Terminal, PDFs etc...

I am not aware of any Lynx integration but the limitation there isn't a technical one. Just requires people to put focus there like they have for things like Tauri and NativeScript in the past. A quick google search turned up:
https://gist.github.com/doeixd/b604a69f7d8772b7f68eb6e93a526025
https://www.npmjs.com/package/@lynx-example/with-solidjs

If there is enough interest I'm sure people will work on it.

[tiru-r]

Interesting! Native script is single thread based and tauri is based on web views but lynx is more powerful than react native.https://gist.github.com/doeixd/b604a69f7d8772b7f68eb6e93a526025 interesting