Replies: 3 comments 11 replies
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
One of the things I like about Solid over other JSX frameworks is the native Solid approach. 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. Deconstructing has a cost and limitations which one could argue is why many React libraries are copying and bringing over native SolidJS utilities like I understand the argument of "change of compiler" for someone who is used to another framework and coming over to Solid without a full understanding of the reactivity difference. However, if there is one thing I know about @ryansolid and the Solid team in general - everything happens for a reason. Solid on a compiler level (what it does, not the outcome that is being referred to in the examples) is fundamentally not like the other frameworks that provide this simplicity. Fine grain reactivity comes with the need for "fine grain deconstructing". Even the I would argue against this request and am very pleased with the native API design. Solid is not perfect but I would argue against changing the compiler to match a more simplistic approach which I believe is a upstream issue of an industry code quality standard. Here is a similar example of
This example is not perfect, so I'm happy to learn how to improve it if there is room to grow. |
Beta Was this translation helpful? Give feedback.
-
|
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: Video: 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 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 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. |
Beta Was this translation helpful? Give feedback.
-
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 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. 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. 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. |
Beta Was this translation helpful? Give feedback.
-
@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) |
Beta Was this translation helpful? Give feedback.
-
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!
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.
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.
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. |
Beta Was this translation helpful? Give feedback.
-
|
@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 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 |
Beta Was this translation helpful? Give feedback.
-
It's pretty clear thank you! |
Beta Was this translation helpful? Give feedback.
-
|
@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.
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.
It's one of the top things I want to have in Solid. Because I like to do things like this: Long story short
const state = observable({
secondsPassed: initialValue || 0,
// Real memo
get secondsPassedFormatted() {
return this.secondsPassed + "s";
},
});
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. Using actions and pure JavaScript mutations often feels more natural. Why?
// Why does this syntax work? // But these don't: // Why does this merge data but only shallowly? // This looks fine but won't work if // 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. 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: 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! 😊 |
Beta Was this translation helpful? Give feedback.
-
|
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 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. |
Beta Was this translation helpful? Give feedback.
-
|
Resumability didn't make it into the plan? 🥲 |
Beta Was this translation helpful? Give feedback.
-
|
Or is "run-once SSR" a new name for resumability? |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
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:
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)
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)
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)
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
Beta Was this translation helpful? Give feedback.
All reactions