I think having a formal API generated from the codebase would be very helpful; sometimes it's hard to find which methods are available, what are they called or what types of values are accepted (I'm thinking about all the possible way to call setState).
I found myself looping over the files in https://github.com/ryansolid/solid/tree/master/documentation until I found the answer

Given it's a typescript codebase, https://typedoc.org could be helpful, even if it's not the most flexible generator (it looks something like this on a project of mine: https://framp.me/frappe/docs)

My background is mainly React and derivates (from Classes to Fn/Hooks) + a fair amount of elm + very little vue.
My surprises:

• createState works only with an object, I was expecting to createState('string'): I had to enter in the mentality of using a signal over state
• state is a Proxy over signals: I keep thinking of state as a simple object while it's instead a Proxy (which led to my question here #166)
• createEffect doesn't support explicit dependency tracking: using createDependentEffect instead works fine - I wonder if there is a specific reason to have both functions though?
• No hook rules: this is definitely positive and freeing, no solution needed
• importing CSS works out of the box in the example generate by create-solid and it's not mentioned in the styling documentation (https://github.com/ryansolid/solid/blob/master/documentation/styling.md)
• coming from Next.js and CSS Modules, I'm used to work with isolated css and it would be nice to have support for that (it can be something like import { myClassName } from './App.css' which will be a className generated at compile time)

I probably would have described the system starting from reactivity and introducing the simpler primitive and then building up to state.
I'll try to come up with some tutorial / writing on this and get back to you.

I know there's an open issue about SSR & SSG, but a more detailed documentation about it and how to set it up would be really nice. I think that's going to spark a lot of interest, especially if you manage to get it close to Marko/Svelte rendering.

@framp this is great stuff. The state naming is an interesting thing in the post Hooks world. See I started calling that beforehand because I was trying to emulate React Class Components state object. But now people are used to useState. That's a good point. I'm not sure I'd call signals state because that is just as confusing being functions. But it brings up a good point.

createEffect being separate is mostly for code size. It is the most used reactive primitive and is used everywhere in the views. The number of times I've wanted createDependentEffect are fewer but they do exist.

Yes I need to document create solid better.. It is just a fork of Create React App. I just pointed at CRA docs because that all applies but it's worth talking about that. For instance adding module.css as the extension I think does CSS modules out of the box(https://create-react-app.dev/docs/adding-a-css-modules-stylesheet/). The problem is there is so much in CRA that I don't know how it works. Of course I should just make that a lot clearer.

Thank you so much for this feedback.

@amoutonbrady .... hah.. you got me. This is purposefully cryptic right now since I'm making breaking changes even in patch versions. I shouldn't be but I don't want to bump the minor version to infinity while I work on this. I know how to get Marko/Svelte performance but it comes at real cost given the scenarios I want to support. I almost have to start over and build up again to get there. Basically they render a static string with no reactivity on the server this makes advanced patterns very limited. But there are different sorts of solutions once you accept that. I'm still profiling the cost of reactivity. So far seems I can get Vue like performance, but have to make a call whether that is good enough.

I can't really talk about what the experience of someone with no experience in other frontend frameworks would be, since I'm not that person, but as someone who has mostly only worked with React as well, coming to Solid when I see things that are named "Effect" or "State", I would really want to know either exactly how they differ to React effects and state, or if they are substantially different, it would be nice if they were named something else entirely.

I think the problem with the current explanation of Solid State in the README is that it isn't 100% clear exactly how effects or state work in Solid.

For example, React hooks execute every single render, or if you add state variables into the dependency array, only when those state variables get updated. In Solid's README if you read the provided example code one might be able to deduce that the effect only executes if state variables used inside are set through their setters, but it would be good if this was stated explicitly in the explanation. Also, it still leaves a few questions unanswered, like "so does the effect ever execute if state variables inside are not set?", and "if one uses a specific path inside the state object, does the effect only execute if that path is updated? Or just whenever the setter is called?". Whichever is the case, a more explicit explanation would be nice.

You also don't explain:

• memos, which are mentioned as being the other kind of "computation", aside from effects
• what you mean by "subscribers" in Each setState statement will notify subscribers synchronously with all changes applied.

The two linked introductory articles are a bit better, but explain by showing some amount of the implementation, which can be insightful, especially in this case where the underlying implementation isn't hugely complicated, but can also be confusing to some people. Generally speaking as well, while talking about implementation detail can be fine if it is explained clearly why they make things work they way they do, it introduces one more thing that a new user needs to understand, and is only useful if it helps them understand how to use the library, or helps them understand why the library is good/superior.

I also understand if the introduction on State is merely meant to motivate, not explain, but in that case I would expect a more thorough explanation on both State and Effect somewhere else in the official documentation (and not an article written on another site). And also, if the goal was to motivate, personally speaking, I don't see from the provided examples how the library is all that different to React, and if I was a beginner it wouldn't really occur to me why Reactivity is even that important in the first place. It's only through digging through other parts of documentation and the two articles that any of it clicks into place.

The Reactivity.md document starts by talking about Signals, but I hesitate to actually read about them, because 1. I'm not sure whether it's actually necessary to understand them, and 2. the actual explanation for what signals actually are seems to mostly be a very heavy two paragraph section titled "Accessors Reactive Scope" which should really have more code examples to demonstrate what you mean by things like "reactive scope" and "can be nested as many levels as desired". If signals are just implementation detail then I don't really want to read about them.

@louisch Thank you this cuts to the heart of it. I've had difficulty explaining the reactive update model without going into implementation. Any wordy explanation sounds like vague generalizations or like I'm selling magic. This always detracts from having a simple message.

I do see a couple commonalities here:

1. Use of terms used in React even if React doesn't own the term (Effect, Memo) is generally confusing. I did choose them intentionally for familiarity, especially State. At minimum need disclaimers like the Suspense side.
2. Unclear the role of State vs Signal. Emphasizing state initially undermines learning core concepts.
3. More detail on mechanism of reactive rendering. And how it builds on top of reactivity basics.

@ryansolid I think you should include this example shared state between multiple components

also how to use createEffect without running into issues

@junaid1460 did you remove another example? I actually liked that one. Since it showed something that I took for granted. Computations re-track dependencies on every execution. If you ever hit branching logic that doesn't depend on a reactive stat the other branch will never evaluate and the branch itself won't since it isn't being tracked. I think the execution cycle of reactivity tracking could be better explained.

As for the CodeSandbox example has a lot going on so I'm unclear what precisely you are trying to demonstrate. Generally I recommend following React-like patterns even if it is unnecessary. I find that code organization easier to understand the basics like props and eventually context. Again perfect example of where I'm assuming React knowledge.

It is possible to hoist out signals and state, but you don't want to do so with effects and memos since they will never be released. For that reason I strongly suggest following the Context pattern. I have examples about how that works and docs. But maybe I need a more of.. writing your first app etc.. Or like after a writing your first Component, a next steps.

I'm thinking this mostly boils down to having good tutorials. The examples are ok, the docs definitely have holes, but as much of it is they go too deep in areas a beginner doesn't care to as of yet. I need the documentation to be complete but there should be a path for people who don't care for those details. I introduced state early to let people coming from React try easy stuff almost as a drop in.

Yeah, kinda changed it. with making two components almost similar except for one line. I was trying to explain how tracking works. May be you could include a simple example in a best practice doc

Also there's some other pattern like

passing JSX element directly in props might cause duplication

like for example

function Test({array, index}:{array: any[], index: number })  {
    return array[index]
}

function Root({index}: {index) {
    // Avoid this
    <Test array={[<MyBigComponent></MyBigComponent>, <i></i>]} index={index} />
}


function Test2({array, index}:{array: any[], index: number })  {
    return array[index]()
}


function Root({index}: {index) {
    // do this
    <Test2 array={[() => <MyBigComponent></MyBigComponent>,() =>  <i></i>]} index={index} />
}

This looks very minor issue, but this might cause mem leak while using external libraries like monaco or Pickr, also too many subscriptions to state if element uses state. I think a good dev tool for chrome can notice these issues and notify. May be I'll try to build one.

Is the confusion that all dynamic props are lazily evaluated? And:

<MyBigComponent />
// roughly equals
MyBigComponent()

Because I don't see an issue in the first case if that is what you are going for. Can you explain why don't do this? I also notice you use a lot of destructuring which shouldn't be a problem here but could lead to missing reactive triggering. I'm thinking that something even more fundamental is missing in the docs and following that assumption we've gotten out here somewhere.

Maybe there is a bug here that I'm missing as I expect the first scenario to be fine. Maybe my heuristic for dynamic wrapping is incorrect in these component cases? I feel like I'm missing part of what is trying be achieved here. Using onCleanup should regardless of how inefficient the rendering is (redoing work etc) should still release any side effects.

I have migrated a project from react to solid, I noticed this with a tab component, during change, updates were triggered in two createEffects, out of which one is visible and another was just invoked by this <MyBigComponent />.

Haven't tried solid yet, but read a few articles by @ryansolid & documentation pages in this repo. Solid looks like a very promising project and I really want to see it gaining more traction among developers.

With that, I'd strongly recommend the project to have its official website with documentation before/with going v1.0. If you're already planning on that, please disregard the rest of this comment. 😅

As silly as it sounds, presentation matters. A lot. A nice, clean website to go with the documentation will attract new users and help to retain current users. This is especially true for those who are not as knowledgeable/interested in the underlying technologies but still curious about what the next big thing might be or simply looking for some great off-the-shelf tools to build applications with.

A link to the project website also looks much better than to its GitHub repo when spreading the word. Unfortunately, https://github.com/ryansolid/solid just doesn't give off an impression that this is more than an experiment.

Nothing too crazy--something as simple as https://recoiljs.org/ should suffice in my opinion. You already have all the materials.

Best of luck to you!

@bobaekang I agree completely. It is already in the works. I hope to get it in place soon. It is probably the biggest outstanding piece for 1.0. I wouldn't mind stabilizing on SSR a bit more and a bit of cleanup around Resource APIs for Suspense. I think starter templates could be improved too.

I appreciate the feedback.

@bobaekang I agree completely. It is already in the works. I hope to get it in place soon. It is probably the biggest outstanding piece for 1.0. I wouldn't mind stabilizing on SSR a bit more and a bit of cleanup around Resource APIs for Suspense. I think starter templates could be improved too.

I appreciate the feedback.

@ryansolid could you please drop a link to repo here. I'd like to take that up.

Right now it's a private repo. I will likely change when I have something to show.

Can you elaborate on reconcile in documentation/state.md?
Specifically, how does using reconcile differ from just plain setState? What concrete use cases are there for reconcile? User login? Can you provide some examples of the resulting state after setState with and without reconcile?

Does store.get('users') in the example return an array of objects with at least an _id field which is to be used as the key for diffing?

Just started looking at Solid (having found it via interest in Svelte). I'm most familiar these days with React (and Redux), but have used a bunch of approaches/tools over the years (including good ol' VanillaJS).

Solid looks very interesting, especially as I've hit some performance bumps recently with React in a side project. I know I can work around them, but I keep having this feeling that browers and JS are incredibly powerful these days and we are actually getting in our own way with a lot of our 'solutions'. So Solid's focus on being fast resonates a lot!

Regarding docs, some general points that would help folks like me jump in are:

• A tutorial. Side note that I think Svelte really did a good job here.
• A clear opinion on recommended approaches to common problems (whilst leaving the door open to other approaches).

Right now there is a ton of information that I've read through about Solid that's got me excited about it. But I also notice that I haven't yet tried playing with it because I dread having to make a bunch of decisions (even which 'starter' to use). Reducing those decisions by providing a strong opinion would help a lot here.

I looked over the realworld and hackernews source. I think it would be amazing to document the decisions made (and accompanying rationale) when implementing those - could be the basis of the tutorial? Are they recommended patterns for Solid usage?

By the way, the general explanation of why (along with the what and how) in the current docs/articles is very useful and something often overlooked in docs. Distilling these down into a summary of the tradeoffs made could be helpful to folks evaluating potential fit for their projects.

Lastly, a tie-in with an existing service can be a boon to adoption and visibility. I saw #100 and think that getting an article on their learning section could be a good idea. They are also a good example of real-world articles that get you into their product by showing how it works with other common products (like Auth0).

Really like the idea of having a tutorial/tour page of Solid's features.

• https://svelte.dev/tutorial/
• https://tour.golang.org/

@martinpengellyphillips Yeah I did try to streamline at least getting started. The challenge is everyone has their own opinion. I have Create Solid App. And truthfully the fact that I wouldn't use my own starter probably says something. In general, I've found the process on tooling has generally been I suggest something and everyone points out how they have a different use case. This is a problem with the JS ecosystem in general. There is no one size fits all here. For larger projects people have more patience for bloat. I find most early adopters would rather start pretty minimalist so something like Create Solid is way overkill. But it also isn't there for them. I pictured most people would just start there as documented.

I tried to write an article for how to build TodoMVC but I feel it fell short. The real challenge is answering "why" without getting into very specific details of the reactive system. From my perspective most libraries gloss over this a bit. They just go, this is how you do blank which I think is probably sensible from an intro perspective if why makes the explanation 4 times longer.

Personally I think the single best way to try SolidJS without any commitment is modifying one of the over a dozen examples from CodeSandbox I link off the readme. That's how I learn. That's the poor man's version of tutorials. Which really just brings us back to the tutorial/guides which keep coming back in these comments. I'd love to be able to do something like that. But it starts with getting a REPL setup. Something nice that shows code running, as well as compilation output. That is pretty much the requirement to make those tutorials effective. I've had Solid compile in the browser before using Babel Standalone but this needs to be much better. With that I think the rest of this comes. I'm not sure if there are existing editor tools that can be used? I know Svelte built theirs from scratch.

I could make an issue around creating a REPL. It's just one of many things that will take some doing. As much as I'd like to do stuff like this to promote the library. I've resigned myself to prioritize things that only I can do at this point and things that others could help with like say Routing, creating a Website, or creating a REPL I'm going to leave out there for now. If anyone wants to help would be super appreciative. Otherwise I will get there eventually.

@ryansolid I hear ya!

I could make an issue around creating a REPL. It's just one of many things that will take some doing.

I personally don't think you need a REPL tutorial (it's a nice to have).

What I was thinking more about was some clearer sense of "Ryan's sitting down to start a new project with Solid - what do they do?". And I think that, as the creator, you totally get to give your opinion without worrying about satisfying everyone elses 😄

And maybe you don't use starter templates and just spin things up from scratch. If so, I'd say that in the intro/tutorial because it helps establish the culture ('lean and mean', 'back to basics', 'understand your tools', ...) and it also avoids folks spinning the wheels too much on 'am I doing this as intended?'

And truthfully the fact that I wouldn't use my own starter probably says something.

I totally clocked that and it was a stumbling block for me getting started because I wanted to know why doesn't Ryan use this? Can I do what they do instead?.

Personally I think the single best way to try SolidJS without any commitment is modifying one of the over a dozen examples from CodeSandbox I link off the readme.

I think that's a good way to try bits of Solid, but for me it's not a hook to use Solid. I need to build something with it and see how the pieces fit together. And that means I need low friction on getting started on my own project. As an aside, CodeSandbox is typically slow so not a great compliment to a project that focuses so much on performance 😉. Also, some of the examples (e.g. form) seem slightly broken and there is a lot to go through up front.

BUT, to stay true to my earlier point, if you think lots of examples via sandboxes is the way to go, then just stating that clearly will help folks get in the groove.

In the meantime, I'll take a punt at converting one of my existing apps to Solid and let you know how it goes.

I'm not sure if I've missed this, but one topic that may be worth covering is how to generally approach the integration of 3rd party vanillaJS libraries with Solid (e.g. libraries for animations, drag-and-drop, etc.).

This is a topic that has been in the back of my mind while thinking about (and very much wanting) to use solid for an upcoming personal project. I don't know if I've overlooked or just failed to understand something, but there could be other dumdums like me that are also unclear as to what to consider and how to approach trying to use existing vanillaJS libraries with Solid.

That's fair. I think I assume too much React knowledge and don't provide any guides for this as it is a bit outside of what the library does. In one sense it's really simple, which is why it gets missed I think since:

// this is an HTMLDivElement
const div = <div />

In that it is pretty easy to do Vanilla JS since you just get a reference to the element and do what you would with it. You can also get refs via the ref bindings https://github.com/ryansolid/solid/blob/master/documentation/rendering.md#refs.

If you need to cleanup when your component is destroyed you can add an onCleanup call to clean up any side effects.

Albeit I don't have great examples. This thread might be of interest: #39 I'd be interested in more concrete examples as a source for guides.

As kind of the culmination of the long chain of questions I had in #215, I think this line:

While you don't see them, everytime you write an expression in the JSX,
the compiler is wrapping it in a function and passing it to a createEffect call.

in the Reactivity docs could use a bit more elaboration. Reactivity in Effect and Memo are very clear, I've been basing my understanding of reactivity off of S, so those read to me just as S computations... But it's a lot more opaque when it comes to JSX, I think (Which is an issue I think I also have with Surplus). I originally interpreted this as meaning of "an expression in [the] JSX" as "a JSX expression" as in "All JSX is compiled to a createEffect call", which lead to the assumption that anything inside the body of a Component function would therefore be reactive, but from the conversation we had and the article you linked, I understand that's not the case. I'm assuming now that "an expression in JSX" is what the curly brace interpolation thing is called, and I guess I just never picked up on that. So, does this mean that any function that's ultimately invoked within JSX bracket whatevers is reactive? Does this apply universally, like in props and such? I think it would be useful for people who are prone to making way too many assumptions, such as myself, to explicitly lay out where the boundaries of reactivity are.

EDIT: I think I might just be parroting what louisch said above.

Also, when you say all dynamic props are lazily evaluated, does this mean that something like

<Component someProp={getSignal()}/>

Is not reactive, unless I were to use someProp within the Component? Or is the rule specifically to not do this, and pass getSignal to be called within Component?

@Myrdden Yeah it's all good. It just means they can be better. I made a lot of changes thanks to @louisch comments. But you bring up such an obvious thing yet not obvious to me since I am in it all the time. Those curly brace things are called JSX Expressions in the spec and the AST parsed. I actually named the underly DOM Expressions after this concept but it is in no way obvious since in JSX from a JavaScript perspective everything is an expression.

To answer your first question yes. Component execution bodies themselves are untracked, but every expression which can be reactive inside a JSX Expression is reactive. The compiler uses syntax analysis to determine this. Things that call functions or access members (like array or object property access) are treated like they are reactive. Function declarations, literal values, and simple identifiers that can never be tracked are not (it's a little bit more complicated than that but that's the message).

Second question. With components the compiler instead of wrapping each prop in createEffect only wrap these in functions and mark the property as dynamic. A dynamic property creates a getter on the props object at Component creation time. The reason you want to do that is to universalize the API. You could pass the getSignal which as a function could be accessed reactively with no extra wrappers, but it would be the child's job to decide if they had a signal or a simple primitive value. That is unacceptable from my perspective. So you are better to resolve it in the binding like your example and then props.someProp will only run getSignal() when you access the property, and if you bind with a non-reactive value like with a string value props.someProp will still hold the right value. So it's universal. But this clever little trick prevents creating excessive intermediate reactive primitives, unifies signal and POJO interfaces, and removes the need for an isSignal operator or any sort of special consideration for the Child Component based on what is input. There is a chance the child ends up wrapping a non-reactive expression in downstream JSX expression and it never updates but the cost is minimal unless it is the only expression for that whole template. But short story, don't worry about that.

Still I've struggled to explain this. Lazy evaluation is necessary so that access happens inside a reactive context as desired. But I understand it isn't clear what that means since I sort of hide it behind property access.

Neat, that totally cleared it up for me. My takeaway is basically that the assumption can be made that anything inside of Effect, Memo, or a JSX Expression is reactive, but I think that did a good job explaining why.

One more question, how exactly does destructuring work? Is it just "never use it with reactive things"? I understand that ({someProp}) => ... will break reactivity, but will (props) => const {someProp} = props; ... do so as well?

Actually, while we're at it, it might be useful to have a list of potential pitfalls documented somewhere...

Honestly I think this is the by far the biggest one. It's all variations on this topic of reactive context and reactive property access and tracking. All reactive libraries fundamentally work the same but since I don't do this at a Component scope it causes a lot of confusion. Unfortunately it is the thing that makes this approach interesting from performance standpoint. Why it is able to do the 1:1 updates that no other library even Reactive ones like Svelte can do.

It's much easier to just say never destructure. But the truth is for something to be reactively tracked we need to call a function. We can hide that function behind a getter or a proxy but we need to call a function while the reactive context is executing. So nothing is wrong with destructring as long as you are in the right place. Destructuring is accessing properties on an object and assigning them to a value. A value can not be reactive. So it matters where you access that property, so a destructure tracks like any other reactive access. But if you do it at the top of your file no one is listening.

I looked at Vue 3 docs for suggestions of how to explain this as they have the same problem in their setup function. But they just point to a helper that sort of destructures into a bunch of refs(signals). But it's verbose and expensive. I guess I could write simple function wrappers with explicit keys but it stops looking like destructuring. It becomes sort of self-defeating when the goal is to keep things terse. I could do it with a proxy maybe and keep the syntax tight. It wouldn't work in a rest parameter.

Like:

const {someProp} = toSignals(props);

// now someProp is a function and reactive when called.
someProp()

The request has come up a couple times now. Any thoughts on something like that? A bit more ergonomic perhaps than p.someProp?

We do have some other helpers like splitProps that I use for common cases where you want to spread portions of the props to different children and want to retain reactivity.

Personally I'm happy with "never destructure reactive props or else they'll break". I usually tend to use use p.someProp anyways, I just wanted to be clear on the behaviour. That said, I suppose a helper wouldn't hurt if one is really committed to destructuring.

Hello, another question... Maybe this goes in it's own ticket? Not sure.

I recall you saying somewhere, I don't remember where, that <Component/> is the same as Component(). If I assume this is universally true, will I run in to any issues? For instance, if I have:

const Component = () => <p>hello</p>;

const App = () => <div><Component/></div>;
// versus
const App = () => <div>{Component()}</div>;
// or even something like
const App = () => wrapDiv(Component());

will these all function exactly the same? Or is there some other logic to <Component/>?

EDIT: Forgot that I, as a programmer, posses the ability to look at other people's code. So I'm seeing createComponent when <Component/> is compiled, and this looks to be wrapping props as dynamic, and also memoizing the component itself? <div>{Component()}</div> just ends up as () => Component(), so is all of that work necessary as a JSX concern, and that tracking happens automatically given the expression is wrapped in a tracked function, or is there actually work being done in <Component/> that isn't with {Component()}?

I'd assume the answer to this is yes, but I figured I'd be thorough and ask.

Yeah I might even remove createComponent in the future out of the JSX output. Props are the difference. Effectively this is what is happening if I were to do it at compile time.

// consider:
<Component prop1="static" prop2={state.dynamic} />

// becomes:
sample(() => Component({
  prop1: "static",
  get prop2() { return state.dynamic }
}))

Does that makes sense?

Generally, ignore the memo it's for a special case in which the component returns a function. But I'm intending to solve that a different way in the future to avoid unnecessary wrapping.

@jeff-hykin Yeah it's super tricky with JavaScript. It goes beyond the templating since you can't intercept just a value read. Which either sticks you on Solid/Vue path or Svelte (which is locked to the template). There is research being done to get around that but it is complicated. Generally speaking I think being explicit as much reasonably possible is probably the solution. One thing that I push with Solid is to always call the function on the signal and not just treat it like count since the second someone goes to format it change it then they need to add that. I used to have this issue always with Knockout and Vue is more of the same. I'd make using just count as you put it break everywhere if I could (it does on attributes) but for inserts it's also the mechanism for dynamic inserts so technically they allow functions. The problem with being explicit on dependencies is in the templates themselves. Unless you are taking a course grain approach no clean syntax to set deps per binding. I had these sort of issues with doing RxJS based templating. In the end I went back to automatic since it keeps things clean. Compiler analysis does auto wrapping of potentially dynamic values so you can just use it pretty naturally in the JSX.

Solid early days used a syntax to denote reactive values. It took me a while to find something that wouldn't break TypeScript but unfortunately Prettier killed it pretty badly. I used inner params {( state.value )} to denote reactivity. In some ways I miss the power of that system since it was so explicit but people still kept messing it up. Honestly just allowing { state.value } just makes more sense .. otherwise you end up introducing extra function syntax like {$(state.value)} etc.. It's a bit of a rabbit hole where this can go. Now that TypeScript supports namespaces you might be able to use that like $:class={}. They only added namespace support in February of this year which has been a real constraint. Of course you'd still need difference syntax to denote react/static children perhaps.

I'm hoping too documentation can help. I've been wrestling with this stuff for about 5 years now and gone through many permutations but reasonably happy where I am now. But stuff like destructuring is probably always going to be a problem until we can do cross module analysis through compilation. And basically invent our own reactive language like Svelte that goes beyond the components. I might do that one day.

Oh that's really interesting, the {()} and {$()} are similar to syntax I was considering. But I think my approach might be a bit different than expected.

My thought was having a Reactive class for all reactive values.

let Hello = ({ name }) => {
    name instanceof Reactive; // true
    Reactive.get(name); // "world"

    let count = createReactive(0);

    const doubleCount = reactive`@count * 2`;
    doubleCount instanceof Reactive; // true
}

The template would be able to identify the special syntax (e.g. @count) at compile time, hoist all the reactive parts to the top, and use them to identify the dependencies/effects without executing the rest of the function/expression. Registering the effects could be something like Reactive.onChange(name, ()=>stuff). The limitation is that reactive values need an identifier, they can't be the output of a function (e.g. @(getName())). This makes them kind of shallow, but that actually might encourage good design practices with reactive values being defined above the JSX. It also simplifys the syntax to one character instead of something like {$(count)}.

On the flip side, if a reactive value was accidentally used in the template (e.g. count + 1) it would basically never produce the correct output. The current system would frequently produce the correct output, it just wouldn't update properly. But with a reactive class it'll almost always result in null or nan which would at least be a red flag. This also means there is no need for an untrack function, the Reactive.get(count) would already get the value in an untracked way.

With babel-macros the template work can be done at compile time, but I think templated work could also be inefficiently done at runtime just like other methods in Solid.

@jeff-hykin Compile time reactivity with compiling in the dependencies is one of the first things we tried for the next version of Marko(I also work on eBay's JavaScript framework). There are a few performance cliffs and we ultimately went more Svelte-like. The short of it was we were taking on a lot of the overhead of runtime reactivity and not getting all the benefits. It is infinitely more challenging admittedly to get cross-module reactivity with that but we've developed an approach.

The idea of fail-dangerous is interesting to me. See in the past fail-dangerous in a reactive system meant triggering crazy ping ponging of updates. Basically over-rendering was a problem. Now that we've done everything possible to prevent that we have the issue of losing updates. I do agree that though that proxy style hiding of reactivity does cause this to go undetected where as a special symbol or even signals (whose special syntax is() at the end in that perspective) will NaN out if you mess it up is preferable. This is a difficult tradeoff for consistency. With Solid I made the choice to not call out reactivity and let functions just fly because I wanted it to be seamless from inside the component whether the consumer passes a literal, a simple value, or a reactive one. And I didn't want the overhead of always wrapping expressions. This actually has considerable performance implications.

The only place we can really shave for more performance at this point is making fewer subscriptions and short of some compile away reactivity system that works cross-module anyone would be hard-pressed to find better performance. It would be possible to do a 1 for 1 proxy with say the DOM to do better, but that approach wouldn't scale to shared data or scheduling updates. So given the focus on performance, I like the set of tradeoffs made here.

Re-reading the comments though a lot of good thoughts. Especially around async. We've been looking at that a lot. The funny thing is while on paper a lot of those limitations seem bad. In practice it's hard to even come up with reasonable expectations of how they should behave. Like if you had an async function why would you want to track after it returns. Would that update cause it to start all over again? Or from that point etc.. I think you could make it do something but it actually doesn't fit the mental model anyway. I guess it's still a gap to get to the point where it is obvious that if you have a condition in a tracking function it too has to be trackable so that the different branches can execute. When done this gives more granular reactivity than any compiled solution can do.

I think that has been the challenge. Even when explained the implications are a bit of a slow trickle. But I think your list is a good starting point and I will use that.

I'm not sure what cross-module reactivity means, but I'm glad to hear some form of compile time tracking and fail dangerous have been explored.

In terms of a feature, would manual/explicit effects for a function be considered bloat, or could it potentially be part of Solid.js if I worked on it as a PR? Seems like it could allow for slightly less overhead (no initial function call, and effect events don't need to be triggered with each call), and could maybe be used internally within the Solid codebase.

The sleek black magic "it just works... well at least most of the time" is fine for projects with tight teams that can explain the caveats and pitfalls, but both @aminya and I (@aminya leading the way) see Solid.js as the best framework for the Atom Editor. And with the motto of "the hackable editor", it kind of needs to be designed in a way that doesn't require intimate knowledge of a reactivity system that has many caveats. So yes, this method of explicit requirements definitely would not be syntactically sleek, but I think it would make it more maintainable with a lower skill requirement.

Technically I guess it's possible as-is.

const dependencies = (...args)=>args.forEach(e=>e())


const conditionalDoubleCount () => {
    dependencies ( getCount);

    if (condition) {
         return getCount() * 2;
    }
}

Just seems like a bit of a runtime waste with the extra function calls.

I'm a bit confused with the comments on async, so maybe I'm missing the point with the following comments.

If tracking/effect system was perfect then I'd say async itself already has the correct behavior except for the final level; the Dom. For example, lets say you had a reactive variable weather.temp that was always a promise. Don't treat the promise as a special value. It's just an object like any other. A reactive function like doubleTemp = () => 2* await weather.temp would want to know when a value was updated. So let's say onClick:() => weather.temp = api.getTemp(). Whenever there's a click, the object changes to a new promise. Since there was a change, then doubleTemp gets run again. We don't even need to pay attention to the await. Same goes for a wrapper like quadrupleTemp = () => 2* await getDoubleTemp(). The getDoubleTemp always returns a promise. Onclick the temp object is changed (coincidentally to a new promise), the doubleTemp is executed and returns a new object (coincidentally a promise), then quadrupleTemp runs and returns a promise. Whoever gets that promise can do whatever they want with it, await it or not. When some code awaits it, then quadrupleTemp waits on doubleTemp who waits on weather.temp.

The only thing is the final output, like the DOM needs to await the promise before changing. And with JSX that would probably require a placeholder element with display:none until the first execution has finished.

Now... That's all if implementation wasn't an issue. Given the current effect system, I have no idea how to practically keep track of effects while awaiting values.

One of the issues I have had is that by default, the child components are not reactive when a parent changes the props that are passed to that child.

The workarounds I have learned through experience are the following. Using these two workarounds I have been able to use Solid like React, but I am not still clear why I need to do these things, or why Solid isn't able to handle these automatically (at least partially).

1. Use createComputed when a prop is passed from a reactive parent:
2. Either use createState or pass false as the second argument of createSignal. This makes the child reactive.

export function Child(props) {
  const [getSomeProp, setSomeProp] = createSignal(props.some_prop, false)  // pass false to createSignal

  // update the local copy whenever the parent updates
  createComputed(() => {
    setSomeProp(props.some_prop)
  })

}

In addition to better documentation, we probably need some Eslint rules that help us write correct Solid code. I have been using the recommended preset of eslint-plugin-react with react/react-in-jsx-scope disabled, but still, this doesn't cover the corner cases of Solid.

In terms of a feature, would manual/explicit effects for a function be considered bloat, or could it potentially be part of Solid.js

There is an on helper(it supports arrays too). https://github.com/solidjs/solid/blob/main/documentation/api.md#on. I made a modifier since realistically you could want this behavior on any computation. But yes that is all it does. Calling everything in the same manner. I think it's fine since there is a much greater waste if you force the end-user to denote every expression as a computation, especially over component boundaries.

What's weird about that example is why the condition isn't a signal. That's one of the strengths of this sort of granularity. When the condition is false we don't even subscribe to count. If you update it every 100ms, no extra work is being done when the condition is false. Static dependencies don't solve that which is one of the challenges I've hit for compiled reactivity.

I'm a bit confused with the comments on async...
Ok I see... yeah a sort of hybrid of using the reactive system to deliver promises. That would be a pain for the compiled output the same way Observables are. Atleast Observables could stay fixed. Mostly that the expressions would need to be written a different way for promises.. ie.. if promise then it. Which we wouldn't know until runtime and autotracking doesn't know until it is running so I don't think there is a way to do this without bloating every binding. Like Solid outputs:

createEffect(() => el.setAttribute("title", state.maybePromise))

So it naive approach would need to be

createEffect(() => {
  const value = state.maybePromise
  if ("then" in value) value.then(v => el.setAttribute("title", v))
  else el.setAttribute("title", value)
})

Obviously could wrap in a helper especially since I'm missing promise cancellation here. createResource just handles this all sooner and leaves you with a signal. It does push you towards Suspense which I suspect doesn't feel flexible enough.

@aminya

One of the issues I have had is that by default, the child components are not reactive when a parent changes the props that are passed to that child.

We are still missing each other. You really don't want components to be reactive. Ever...

I think I'm missing some scenario or something you are trying to do. Is it 2-way binding? Resetable forms? Like why a local copy of state/signal to just wrap a prop when you could use the prop. Or a derived value. The problem is if possible you more than a single source of truth there will either be synchronization or indirection on read. Indirection on read might actually be a good reusable pattern as it could avoid creating additional computations. But it sounds like right now you are in a place where you are trying to work around the system and I'd like to understand why.

Not sure if relevant, but for context I've used the pattern of local state/signal which is updated when parent passed prop changes. The two use cases I had were forms (passing in new initial values post submit, whilst still allowing the form to edit values locally until submission) and drag and drop (local copy of ordering to avoid updates interfering with an in progress drag).

I use createEffect for updating the local copy when passed prop value changes.

@aminya

One of the issues I have had is that by default, the child components are not reactive when a parent changes the props that are passed to that child.

We are still missing each other. You really don't want components to be reactive. Ever...

I think I'm missing some scenario or something you are trying to do. Is it 2-way binding? Resetable forms? Like why a local copy of state/signal to just wrap a prop when you could use the prop. Or a derived value. The problem is if possible you more than a single source of truth there will either be synchronization or indirection on read. Indirection on read might actually be a good reusable pattern as it could avoid creating additional computations. But it sounds like right now you are in a place where you are trying to work around the system and I'd like to understand why.

For me, the components are a unit of code-reusability. A component allows me to make a package like solid-simple-table, and others only need to use it in their components and pass data into it.

When a component is used inside another component, the default assumption should be reactivity from the parent. I am assuming that Solid cannot perform multi-component analysis to detect this, and that's why we can't fix this automatically.

If I had a prop which I didn't need to be reactive, then I would simply destructure it.

  // static props:
  // destructure the props that are not tracked and are used inside the loop
  const {
    headerRenderer = defaultHeaderRenderer,
    bodyRenderer = defaultBodyRenderer,
    getRowID = defaultGetRowID,
    accessors,
  } = props

react-table switched to hook-based package in version 7, but that approach doesn't make sense to me (it is much more difficult to use than a simple component). We shouldn't need to make everything (even the package) a hook.

@martinpengellyphillips Thanks for the example. In the past (where I didn't have state at my disposal) I did similar synchronization. Generally not using a computation, but manually on the submit action or as an exposed API, but the same idea. Mostly that in my case I couldn't always guarantee that the value from above would change. Like if you are just resetting the props from the parent might not change.

This pattern of exposing an API isn't an obvious pattern and I haven't seen it as much as of late. If you pass in an object as a prop the consumer can write APIs to it. ref's can also be used this way albeit inconsistently. It might be because of React's tendency to re-render everything. But basically passing reset back up to the parent so they can call it. Alternatively the parent can just pass in a reset signal designed to always update (equals false). This isn't much different than I picture @aminya is doing in terms of having to set stuff to false except it isolates it from the data.

I suppose another approach is always to deep clone the starting data on reset and pass it in. That would guarantee updates.

@aminya

One of the issues I have had is that by default, the child components are not reactive when a parent changes the props that are passed to that child.

When a component is used inside another component, the default assumption should be reactivity from the parent. I am assuming that Solid cannot perform multi-component analysis to detect this, and that's why we can't fix this automatically.

By fix you mean simulate top-down rendering? Even with perfect analysis that wouldn't be the direction here. Props coming in are reactive and the child can react to them. I don't understand where the idea the child isn't reactive coming from. As best as I can tell the false in the original example is likely because the same value is being set. It's not changing so it's not notifying by default. Not unlike if your component was wrapped in React.memo. Is it top-level component tracking you are after? That would be disastrous without a temporary data format. Even something like Svelte which is very component centric doesn't just re-run the top-level component you need to wrap the expressions behind $: labels. It's just a different model and probably needs to be treated as such.

The problem is to make a component that when the parent changes the props passed to it, it updates the rendering. For example, if the parent adds a new entry in the data, the table adds a new row.

solid-table.zip

• parent-false-child-false-has-createComputed ----> the only working combination. When data changes in the parent, the data of the child are updated too and rendering happens
• parent-false-child-false-no-createComputed ----> only updates if I click a sort button
• parent-false-child-true-has-createComputed ----> only updates if I click a sort button
• parent-true-child-false-has-createCompute ----> only updates if I click a sort button
• parent-true-child-true-has-createComputed ----> nothing happenss
• parent-true-child-true-no-createComputed ----> nothing happens (Solid's default settings)

Here is the code of the parent:
https://github.com/aminya/solid-simple-table/blob/c7b08336e22778c99ade7f6e1b4c4f7ada47a860/demo/variable-rows/index.tsx#L18-L26

Here is the code of the child (which is supposed to be a reusable component):
https://github.com/aminya/solid-simple-table/blob/c7b08336e22778c99ade7f6e1b4c4f7ada47a860/src/SimpleTable.tsx#L18-L23

If you would like to play with the example: pnpm install && pnpm run demo.variable-rows

By false/true I mean changing the notify option in createSignal.
createSignal(props.rows, notify)

By createComputed I mean setting the props inside a createComputed in the child.

(Coincidentally getting back on the topic of improving documentation)

I think there's a point of confusion here @aminya @ryansolid. If I'm understanding correctly, for a single instance of a component, the render function is only ever called once, and then Dom is mutated only by using effects right?

So one part of @aminya's code basically has

function TableComponent(props) {
    return <table>
       <For each={props.columns}>
            {(column) => /*stuff*/}
        </For>
    </table>
}

Since <For> is built in we would expect it to mutate/update it's children when props.columns changes right? (When the parent changes props.columns)

@ryansolid fyi, for my form example it's not actually a reset as such. It's a bit special to my needs, but on submit the parent handles formatting the data to a nicer display version. And then I just reuse the form for display. It's an unusual live edit form and display situation.

But this is actually what I like about solid. I end up building just what I need. I'm not tempted to try and find a formik library and then make it do what I want.

That said, is there a gotcha with my approach here that I'm unaware of?

I guess I could pass in a copy from parent that is then directly mutable...though I recall some issue with merging state like that 🤔

@aminya @jeff-hykin
I see. The problem is with the set call. And admittedly due to a more recent change. Mostly I wanted to address inconsistencies between signal and state, and I looked around at competitors like Vue and MobX and saw their defaults were only notify on change so I followed suit.

My new tutorials show this off a bit but you also see this in most of list examples like TodoMVC. Essentially the main reason things aren't updating is because you are setting the same array.

const rows = getRows()
rows.push({ file: "New file", message: "New message", severity: "info" })
setRows(rows) // still the same array... solid has no knowledge anything has changed

Now you can always notify by turning the equality check off like you have been doing. But you basically have to do that everywhere. Generally the approach is:

setRows([...getRows(), { file: "New file", message: "New message", severity: "info" }] )  // different array

Now you won't need those false and everything will update by default.

The reason for the computed is that you are accessing the value in an untracked context.

// This initializes a new signal with the current value of props.row... no dependencies are made
const [getRows, setRows] = createSignal(props.rows, false)

createComputed(() => {    setRows(props.rows)  })

There are many ways to do things here so I can't point you at a specific solution. But once you choose to make new local state or signals you need to keep it in sync with a computation. But you could just use it directly like @jeff-hykin example. You could use createMemo for some derived values.

If synchronization is desired, the thing I'm thinking is if it would be possible to make a primitive to handle this clone reset scenario, but I don't think it would be generic for all cases. Like if it were simply signals (no state).. I could picture a sort of writable clone...

function createClone(fn) {
  const [s, set] = createSignal(); 
  createComputed(() => set(fn());
  return [s, set];
}

// use like
const [getRows, setRows] = createClone(() => props.rows);

I don't know just spitballing. Many options here. And missing pieces. Like how do changes get back up to the parent. Etc.. Usually a single source of truth is better. But I acknowledge that sometimes better for the child to handle sort of temporary(editing) state rather than just have it reflect back to the parent immediately.

@martinpengellyphillips
Only snag is if the initialValue doesn't change. Setting it again won't retrigger. If it is consistently retriggering as desired for your scenario I don't see a problem.

My new tutorials show this off a bit but you also see this in most of list examples like TodoMVC. Essentially the main reason things aren't updating is because you are setting the same array.

const rows = getRows()
rows.push({ file: "New file", message: "New message", severity: "info" })
setRows(rows) // still the same array... solid has no knowledge anything has changed

Now you can always notify by turning the equality check off like you have been doing. But you basically have to do that everywhere. Generally, the approach is:

setRows([...getRows(), { file: "New file", message: "New message", severity: "info" }] )  // different array

Oh, I see. Is this the same for createState generated states?

Can't we add a counter inside the set functions that detects the numbers that a function is called and if it is incremented, then it means a new diff check is required? If we could, then we can trust the user that is calling setRows, and perform a diff check. I think the counter can be a simple boolean that changes between false and true every time setRows is called. Holding a copy of a boolean value should be very cheap.

Yes but createState is nested so you can opt to do a nested update. Like you could just set the index at the end of the array to effectively push on the new item without cloning.

In general we do not diff data. In fact diffing the signal would make no sense since the only thing that could notify is the signal itself and we can't account for all the different downstream ways it could be used. Like say we diff we know it has changed, but the downstream just gets the data and doesn't know what has changed and would need to diff again. So we did that diffing for basically no value because presumably who ever is doing the setting could make that determination. If we wanted to always notify we could that is what the false flag is for. But if we guard by default you'd need to propagate this along the whole chain which is not a guarantee you can make as a generic API which guards by default.

Basically, the defaults make a big difference here, and when consider that effectful changes can have real side effects (we run cleanup every time they re-evaluate) restricting notification is important. An equality check in the computation is too late it needs to happen at the point that the upstream signal decides whether to notify.

So when trying to decide between guarding by default and not I landed on guarding because it is the easiest the explain and it basically removes the opt in aspect of this. When designing slightly more complicated things we'd be pretty aggressive guarding and then have to instruct the end user that we guard like this so pass in unique data. Now it's just universal. Basically well written re-usable libraries for performance reasons will be guarding for most things. And as people started writing more libraries it became harder to hide that detail or deal with the inconsistency. I sometimes opt into notify always but it's in local scopes. Like triggering something. For external facing APIs I feel notify on change is the only way to be consistent.

It does occur to me though that the result is a little strong-armed even if it is a clear message. But Vue and MobX are the same defaults. Sure you don't experience this as much because they rely a lot on the proxies, like Solid's State object. So maybe that is just the solution here. Their state is mutable though so I bet people don't even realize it. But generally don't grab reactive data and mutate outside of the reactive system and expect it to update. It's possible in dev mode that I should be returning readonly proxies that warn people trying to mutate this data.

But generally don't grab reactive data and mutate outside of the reactive system and expect it to update

Dang 😢 that's my favorite feature of Vue. I can do something as jank as JQuery a dom element, assign element.data.name to some debugging value, and the whole system reacts like normal.

To be clear if you are using a Vue proxy it isn't what I mean by outside the system. Vue's reactivity isn't doing any sort of deep diffing. It is very similar to Solid's. I default to readonly proxies but there are the ability to make mutable ones. By outside the reactive system I mean taking non-wrapped values and updating them and expecting them to change. For instance holding reference to the initial value being passed into a reactive initializer and updating it. In other cases I mean shallow reactive values. Vue I believe wraps deep by default so you probably never see this. But Solid SIgnals are shallow by default. If you are looking for Vue like behavior use createState or createMutable.

I'm still definitely struggling with knowing when a component will update (and especially what will fail to trigger an update). The differences between createState and createSignal also remain somewhat opaque to me.

@jcuenod I'm hoping the tutorials address that pretty well. I think we need more interactive examples to appreciate it since even explaining it doesn't really make sense when I say shallow versus nested tracking and what that means. You can give them a try here: https://dev.solidjs.com/tutorial/introduction_basics. There are some bugs in terms of navigation and loading race conditions but maybe this will help. (If it doesn't load refresh)

@ryansolid I hadn't seen https://dev.solidjs.com yet. It looks great! Yes, I have noticed some loading bugs but (other than that) I like it. I think you need to explain "tracking scopes" (at least, when I encountered the term, I didn't know what it means in practice, even though I can guess its definition).

Just saw this issue. Referencing #504

Does Solidjs support Generators in the event lifecycle?

Good call on the interopt. Bringing other libraries into Solid is pretty easy but the opposite matters completely on the mechanisms of the host framework. For client side its mostly just a ref and render call but for Next or SvelteKit, anything with SSR there isn't a definitive answer.

As for generators no. The lifecycles are a bit fake anyway. Its all just reactive subscriptions. Tracking in generators doesn't really make sense to me and unclear what we'd be yielding to. I guess the settling of the reactive system. Not sure. Probably worth some thought. I wonder if introducing them core would create potential issues for concurrent rendering.

@ryansolid I don't know if you looked into the effection library, which uses generators to have Structured Concurrency, but it got me excited about using generators to solve some issues I've been having. Composing concurrent microtasks seems pretty natural with generators. It also performs well, better than async await & is memory efficient over large iterators.

Stuff when I started:

• component props using getters to track usage rather than function calls. Reactivity was pretty easy to figure out for the most part after reading the reactivity guide, but it seems to be missing examples with props.
• createEffect can contain onCleanup. this should probably be part of the useEffect examples, how to clean up stuff after the effect is done. Also maybe useful to note that createEffect can contain other createEffects and stuff like that.

@btakita I imagine this would be a larger change. MobX has things like flows which use generators to create actions. I can see in places where there are side effects doing that sort of thing. But Solid's own primitives are based on a queuing system so I don't really see how it would play nice.

@pfgithub
A good chunk of the rendering guide is on props(https://github.com/solidjs/solid/blob/main/documentation/guides/rendering.md#props). I didn't use an example in the reactivity side as I viewed them more as artifact of components and less reactive fundamentals but maybe that is where it would be expected?
Yeah I think I don't make that obvious. onCleanup says you can put them anywhere but doesn't really give an example of that. I used to highlight the nesting but hmm.. I don't know how much of that is reference as much as by example.

Did by chance you see the tutorials on https://dev.solidjs.com? I was hoping they would supplement the docs sufficiently.

@ryansolid That makes sense. Thank you for the explanation.

I am running into wanting to add an interface to the props of a component. Have not seen any examples. Perhaps something about Typescript types would be good to document.

I agree we collecting some stuff in the Discord. I'm just uncomfortable writing it myself. I do not feel confident in my knowledge of TypeScript at all. Some people have contributed some very powerful typing to Solid but I feel after almost 3 years on TypeScript it still hasn't clicked for me.

@ryansolid Just wanted to say that video yesterday was excellent for explaining the reactivity system. I think the interview format made all the difference, making the video an order of magnitude better than the current reactivity guide linked in the readme.md

Linking that video in the documentation under something like "how does Solid know what to update?" would fill the biggest documentation hole for me (and would fully address my original message on this thread)