Road to 1.0

[ryansolid]

As you know I've been gearing up for a 1.0 release. I feel like I've addressed most of the major topics at this point and I just want make sure there aren't any things that you all feel need addressing. Once I flip modes I will be working more on documentation and the website and will halt most Solid development outside of starter stuff and bug fixes for the next couple months.

I feel I'm mostly ready to lock that down, so I'm looking for suggestions or feedback. Any APIs that are awkward or have weird naming now is the time. I'm pretty happy where things are about stuff like createState and createComputed still give me pause. The way setState merges objects might not be intuitive. I am not comitting to changing things as I'm reasonably happy where things are but I definitely appreciate any honest feedback to see how I can approach categorizing and if any of these things are vital enough and breaking to make the 1.0 release.

So please respond to this thread with anything that comes to mind to this nature. I will be putting together RC release for next week if nothing major comes up. I appreciate your time and consideration.

Some other matters of related business:

1. Growing the Team
   We also are looking at growing the team of core maintainers for Solid. Feel free to reach out to me if you are interested in helping out. While the core library can be daunting at times there is still plenty of tertiary stuff to do around integrations and the website and help with bug reproductions etc... Especially as the library gains some more steam after 1.0 release. I suggest getting involved in our Discord as a start if you haven't already. I already see community leadership forming there and will be looking to formalize that a bit more in coming months.

2. Moving to GIthub Org
   We are planning to move off my personal github to an org. Unfortunately just about every variant of Solid/SolidJS is taken. So I've registered solidui. Maybe not the best thing but the best I could find. If there is no good reason not to make the move we will be doing so over the next little while.

UPDATE: We got solidjs as the github org!

[amoutonbrady]

This is exciting! I've been following for quite a while and I've seen things evolve. What a ride.

As I've been part of the most recent decision, there's very little I can bring to the table in term of API design. Going through the API documentation, it strikes me how the core API is down to 8 primitives. It feels like there's so little to learn to get tremendous power.

That being said, there's one little thing I'm not entirely sold but that probably because I've never had a use case for it or I just didn't know it was the solution for that use case. I'm talking about the initial value for createEffect/ createComputed/ createRenderEffect. I get where it goes, I just feel like it's a bit off in the sense that besides this initial first value, what should user expect to have in that callback function parameters? Again, probably just a "ah" moment that has yet to come.

createMutable kind of feel like it should be part of a solid-extra package. It doesn't really adhere to Solid core principles and as outlined many times before, can be a footgun if not handled properly.

createRenderEffect is a bit confusing when put against createComputed (before render) and createEffect (after render). I guess it sits in the middle.

createResource reaching a stable API, it should probably be part of the core API as the way to manage async data in my opinion.

In any case, I can't wait for what's coming. This will be a lot of fun!

[ryansolid]

Thanks.

1. The reason for createEffect being like that is it removes a closure which reduces memory overhead. I use this a ton in the internals of the renderer. I do get how storing temporary state in an effect for no apparent reason is sort of weird. But you can see it being useful for things like diffs. Basically I can use this as a way of holding the previous state while mutating the outside world. Next execution we we can diff our new value against that and then only perform the specific updates again. While it isn't exactly like a memo that is being read from the outside but it still helps inform the next side effect. In an effectful accumulator it might save you from creating an unnecessary memo. That being said it being there doesn't really hurt anything if you don't use it.

2. Yeah createMutable is a bit of a mess. Didn't have a good place to put it as of yet. But that's a good point. It is a really powerful tool to help people bridge the gap between MobX/Vue and Solid and but it's not really great thing to be doing. I can picture it helping with some sort of data external of the reactive system scenarios but produce modifier can do most of the lifting. It is actually the key to our JSX-lite integration for similar reason. Having it is important but I don't really want anyone using it.

3. Yep it sits in the middle. Most importantly it is what ensures refs are present by the time createEffect runs. I needed a way to order these so there is a prioritization concern in general execution, but more than that they run immediately instead of being queued on creation so that we can do things like Suspense. I don't know if end users should be using them for most things but they really have their own behavior that borrows from both. The thing is all rendering in Solid is a side effect. So maybe this is clear: createComputed(before render), createRenderEffect(is render), createEffect(after render).

4. createResource is probably getting pretty close now to that place. I worry about introducing too many primitive ideas but I think with the latest change it is pretty good to be seen as a special signal type. I was intending to move it up in the API reference. Probably need to re-organize that section. Funny thing is with onMount hook I wonder how many people actually use createEffect that often.

In any case thanks for the feedback.

[amoutonbrady]

Thank you for the clarifications.

All of those make sense and I do think that most of those can be addressed via doc and examples.

[trusktr]

Based on what I've seen in the chats, seems some things are still changing. F.e. type definitions are one thing. My advice would be to wait for X amount of time without any breaking API changes (additions and fixes would be ok) before 1.0.

F.e. may arbitrarily decide that you will wait 3 months without any breaking changes, and finally publish with 1.0 with the intent that 1.0 will stay around for a while.

But then again, there are libs like Three.js that can break in any version release (for the better), and users have to either stay at an old version or keep up with the changelog (does a good just documenting how to migrate from version to version) . And Threejs has many users and stars despite non-semver versioning and random (documented) breaks.

[ryansolid]

The thing that I don't think is as clear is I was aware of all the breaking changes coming up was pushing them off because I was working on features and accelerated them recently because I was anticipating 1.0. I had years to think about them and was basically working down a list until I got there. Resource API was the last real unknown one and I view that as an addition. Work on attributes and namespaces has been years in the making. The subtle renaming, better handling of spreads, all things that I knew I wanted to do another pass over. So in my head, we've been stable since September. I know I broke a bunch of stuff throughout the fall but that is what I was doing for 1.0 prep.

That being said there are areas that will continue to improve. Dev mode is one of those things.

I think TS is another issue. TS is volatile. Like jsxImportSource would have happened whenever it happened. I'm pretty sure breaking TS on minor versions just has to be an expectation.

[lzm0x219]

I want to apply to join, can help translate Chinese documents and promote in China.😯

[ryansolid]

That's great. I think I need to refine the English documentation a bit first but definitely would help a lot. Thank you.

Let's talk as things progress.

[lzm0x219]

👌🏻

[TheComputerM]

I feel that having a framework like nextjs for solid is very important in its adoption.

[ryansolid]

For sure. We've seen a trend as of late for more involved starters. That being said creating those are an effort in itself and will take months. I've already started on that effort. I will have something to show shortly and open it up for help/contributions.

[rturnq]

I'm with Alexandre, I think this is really exciting. From my point of view, the API has really tightened-up over the last six months and stabilized for the most part - TypeScript not withstanding. If I were to consider re-evaluating anything at this point it would probably be the default behavior for signals and memos to always notify. It's really minor, but I feel that more often than not you only need to notify when something has changed, so it just becomes extra wasted work.

It seems like as good a time as any to create release candidates while finishing up the initial pass on the starter kit and getting the website ready. Once those are done it should be evident if there is a need for any breaking changes.

[ryansolid]

Yes. This is another one that I've thought about a lot and I've mentioned coming back to. I dislike the inconsistency but it also helps beginners who gravitate towards mutation. Perhaps being strict on immutability from the start is just better. I did attempt this change in the past and it broke a bunch of my internals. I doubt it will affect the end-users much other than possible API change. But I suspect it is just changing the defaults.

I agree if I'm going to do that this is the time. Really this and setState object merges are the only behavior consistencies that really stick out to me. If I'm going to make this change there will be one more version before RC. I'd love to hear more people's thoughts on this behavior. I know this has tripped many people up expecting this behavior automatically. And the inconsistency is really apparent in things like rendering forms.

I should also audit MobX and Vue to see what they do. (I don't care that much about Knockout as that is ancient and I already know the answer there. They do equality checks only on primitives by default and notify on all objects).

[pavulon]

I was also surprised by this, mainly because docs for createEffect state that it runs after a dependency change, not on every notification from dependencies (I guess?)

[ryansolid]

That's fair. That is a language thing. Like the dependency being the signal rather than the value of the signal. Certain systems always notify, and I think some probably always check. This is probably the last thing if no one else has issue with setState.. maybe I'm the only one. The problem is what we have there is a really good compromise, unlike with this signal notification thing, there isn't a good way to make setState consistent if we want to maintain the top level object (React class format) behaving the way people would expect.

[ryansolid]

I'm sold on this change MobX does comparison check by default. This reduces the opportunity for certain types of infinite loops. I made the change and immediately 1/3rd of my tests failed.. but I just needed to change the Loop helpers. After that, the bugs were just my infinite loop checks were passing instead of intentionally failing.

Initial benchmarking shows the impact to be non-existent.

This will be in 0.26.0.

[ilyaryabchinski]

I've been following the project for not so long time but noticed that there is no documentation deployed, can I help with this thing using some SSG tool, or have you already started the development of the docs website?

[amoutonbrady]

Hey! We do have something in the pipeline but to be perfectly transparent with you it's not been actively worked on in the last couple of months. We have the design direction but the tech stack went a bit in all directions.

Ryan is working on a general starter that should be unveil pretty soon and this will most likely be the base of the website. Once this is out the website should follow pretty soon after.

That being said, I know @davedbase (which has lead the movement on that front) has been on the lookout for some people to help with tutorials, documentation structure and all.

Feel free to join the discord if not already to get in touch :)

[ilyaryabchinski]

Hey! Thanks for the information! I'll join discord soon and drop a message there 🙂

[julienrf]

Hello,

Thank you for your work on Solid.js!

As a TypeScript user, here a couple of things that I find a bit annoying. I hope this is the right place to discuss them.

There is no clear distinction, at use-site, whether a property access is going to be reactive or not:

const Component = (props: {
  foo: string
  bar: string
}) =>
  h('ul',
    h('li', () => props.foo),
    h('li', () => props.bar)
  )

Are foo and bar reactive properties? It depends how they are passed from their parent component:

const Parent = () => {
  const [state, setState] = createState({ foo: 'foo' });
  return h(Component, {
    foo: () => state.foo,
    bar: 'bar'
  })
}

Here, it turns out that only foo is reactive, not bar.

I believe it would be clearer if the reactiveness of the props were visible in their signature:

const Component = (props: {
  foo: () => string
  bar: string
}) =>
  h('ul',
    h('li', () => props.foo()),
    h('li', props.bar)
  )

Here it becomes clear that foo is reactive, but not bar, so there is no need to wrap the access to bar in a closure, and there is less risk to forget wrapping the call to foo() into a closure.

Relatedly, although TypeScript has a static type system, it is easy to pass the wrong props to a component. E.g., nothing prevents me from omitting the required props foo and bar:

const Parent = () =>
  h(Component, {
    quux: 'quux'
  })

I wish we could check that the second argument passed to h matches the input type of its first argument (here, Component).

[ryansolid]

I see yeah types and HyperScript is a whole other thing. Everything is geared towards the JSX which is completely different output, smaller, more optimized etc.. The problem is that from JSX perspective the end user doesn't need to worry about this and the types reflect this. Realistically I'd probably need different types.

We do autowrap the props object as accessors so the end user doesn't need to worry about it. So in this example:

const Component = (props: {
  foo: string
  bar: string
}) =>
  h('ul',
    h('li', () => props.foo),
    h('li', props.bar)
  )

The component author decides what to wrap but it doesn't change how you interact with the prop coming in. props.foo is aways accessed like that. You don't call it props.foo() even when you passed in the function. In this case they care that foo is reactive so they wrap it. But they don't care whether bar is so they don't. But if they did they could. And it would be up to the end user to pass reactive or not. I did this so prop access is homogenous. You don't know how someone is going to use your component. Design it to your needs.

The alternative is everything is always functions and need to wrap bar always. Or having the component author having to detect if it's a function or not. This just leads to a bunch of extra stuff that shouldn't matter. It's more pronounced here that HyperScript makes you aware of this wrapping. But in the normal JSX flow of things it feels really natural.

So this brings up a good point about the HyperScript and Lit versions as they are really just designed for easy use and I wasn't really expecting anyone who used them to use with TypeScript since at the point you are handling TS, JSX is better in every imaginable way from Solid's perspective. Using these in actual build environments don't feel very 1.0 to me, nor really are my focus. Maybe I should move these to separate libraries just to make that distinction.

[chris-czopp]

In my view Solid already feels stable at least for me as a pure JS user. It's not a V-DOM implementation hence the trade-off is that we need to do certain things more thoughtful (wrap state props, use components or Dynamic). Definitely we need better docs, specifically explaining the concepts and why we need to do things certain way. There are things which made me scratch my head which I'm fine with but I believe should be explained:

1. Although a component is a function, it's not safe to just call it. You have to either use its custom tag or Dynamic

2. In my components, I pass reactive props as functions and the safest is to not to assign their call results to local vars but call them in JSX where you intend to interpolate them. Otherwise the transpiler gets confused.

This confuses the transpiler:

<Dynamic component={getSlot({ id: actionResults.getUiStateLive.openedMenu })}/>

but this works:

<Show when={actionResults.getUiStateLive.openedMenu === 'projectExplorer'}>
  <Dynamic component={getSlot({ id: 'projectExplorer' })}/>
</Show>
<Show when={actionResults.getUiStateLive.openedMenu === 'componentList'}>
  <Dynamic component={getSlot({ id: 'componentList' })}/>
</Show>
<Show when={actionResults.getUiStateLive.openedMenu === 'settings'}>
  <Dynamic component={getSlot({ id: 'settings' })}/>
</Show>

4. When interacting with a DOM node in ref, I often needed to use setTimeout(<my code interacting with a node>, 0)

5. In HyperScript if one of child elements is reactive, then you need to wrap all of the children in a function.

That's it from what I had on top of my head. I really appreciate the simple API and the flow control components. I would also explain the difference in thinking when using V-DOM vs Solid. E.g. with Solid, a component is called just once which is awesome but you can't just drop console.log at the top of your function body to debug its props. On the other hand, it makes building complex apps more predictable since we don't need to worry if something gets called 100 times. I really believe Solid is a "The Tesla of UI JavaScript libraries" 🚀

I'd be happy to help in forming the docs and covering the edge cases I've encountered so far.

[chris-czopp]

Thanks for clarifying these, my point was just to give few examples which weren't so obvious to me as a user. Re 2/3:

2. I mean that cutting ref to a prop which comes from a state breaks reactivity (and it's totally fine).

I don't do this:

export default ({
  getSomeProp
}) => {
  const someProp = getSomeProp()

  return <span>{someProp}</span>
}

but do this and it always works as expected:

export default ({
  getSomeProp
}) => {
  return <span>{getSomeProp()}</span>
}

3. When I wanted to render a component dynamically based on a prop which comes from a state:

<Dynamic component={someDynamicComponents[someState.someProp]}/>

it seems that the transpiler had trouble in updating just DOM of the component, instead it has been updating its whole parent. To me, it's fine as along as the docs tell me to not to do it. However, If you think it's a bug I can create an issue with all the details.

[ryansolid]

Yeah 2. is definitely a thing. I try to explain in the docs in a number of places and give examples in the component section, but if you can think of a better way to explain this I'm open. It seems people don't expect this to the degree that when I explain they still don't really get what I'm talking about.

3. Oh... You are expecting a diff here? Dynamic is basically like Show, you switch the component, you re-render, which means you re-render everything. I you want to update just the props update just those and don't change what you pass to component. Ie the other arguments to dynamic. I didn't picture this expectation, thanks for explaining. You can see viewing this from the perspective how everything else in Solid works it is obvious it would work this way but maybe someone coming from React would expect different. I wonder how Svelte's behavior is here.

[ryansolid]

Actually is this a matter of preserving the children passed into Dynamic? We might be able to do that. I have an idea. Sorry Dynamic might not be working to expectation mostly that I've never really had much use for it in meaningful way. I think I can maintain the children even under component change by hoisting them into the Dynamic component itself. Which I think is legit thing to do conceptually. Only trick is other stuff like renderProps won't get the same treatment but I think that is more expected.

[chris-czopp]

Re 3, diffing would be perfect but what I observed was rather unexpected because it wasn't replacing DOM of the Dynamic but its entire DOM component.

Given this example:

const someDynamicComponents = { ... } // object of functions returning JSX

export default ({ someState }) => (
  <div>
    <div><Dynamic component={someDynamicComponents[someState.someProp]}/></div>
  <div>
)

It was re-rendering the whole tree (div div Dynamic). I'm guessing the problem is with reactivity of someDynamicComponents[someState.someProp].

Re 2, I think people will eventually get it, just keep repeating it and maybe try different medium. On the project we've been developing we did short videos like this: https://www.youtube.com/watch?v=UXlkcEGzOkU&t=1s Ignore the content as it's outdated. We were relaying on V-DOM and recently we've been migrating to Solid (I don't miss V-DOM at all). If you'd be interested in producing this kind of videos we have a component (also Solid) which "plays" what's in a JSON config. We basically recorded a full-screen browser and then did very little of cutting.

[ryansolid]

That's weird something else is going on. Destructuring the props in the component signature could be a problem as someState itself will never be reactive. But nothing should ever cause the whole thing to re-render. There is no observer wrapping components. I dropped that in playground to look and no problem with compiled output so if there is a problem here it's likely in the code calling this component.

I'd be glad to look at a reproduction. But what you are describing should never happen.

[zhaoyao91]

Glad to help with more about Chinese introducing, using for shadow dom app, style solution, etc as we are working with solid widely in these areas and very happy about this project.

One discussion here: as our projects are more of shadow dom apps embedded in other main apps, so no global effect is very import ant. We would like to disable event delegation for our app, but currently we have to update both compile options and runtime options, which is not convenient. could this be collected into one place? related issue

[zhaoyao91]

I cannot join the discord since it somehow requires me verify phone but my +86 phone are not acceptable by it.

[ryansolid]

I see yeah. It isn't easy unless we had a way of injecting the config build time that the runtime could use. But that would require something to exist that the runtime reads from. A solid.config.js of sorts I guess since we couldn't rely on a typical runtime config function. This is interesting since the compiler isn't Solid specific so we'd need a way to configure a config file as plugin setup and maybe bury it in the preset.

I think this could be a cool feature if there are enough things like this. The problem as you know is that sometimes the event delegation is wanted across web component boundaries. I know that isn't yours or even @trusktr use case, but every time I've used Web Components that has been what I was looking for so it isn't simple as having separate delegation roots automatically in these cases. There is a tension there.

In my opinion this will be a feature add that won't be breaking backwards so we can look at potential post 1.0 in maybe a minor release.

As for discord that is unfortunate as it really is the easy the easiest way to get a hold of us directly. Not sure. You can send me a DM on Twitter or email if it makes sense and I can forward things along. I actually don't handle that portion as much as others do. @davedbase does.

[lzm0x219]

I cannot join the discord since it somehow requires me verify phone but my +86 phone are not acceptable by it.

我的好像没问题啊

[zhaoyao91]

我的好像没问题啊

well, you may have a noble vip phone :)

[lzm0x219]

我的好像没问题啊

well, you may have a noble vip phone :)

hhaha~

[ryansolid]

Had a few really good suggestions from the Discord.

1. Type Aliases like Effect<R, Args extends any[] = []> = (args: ...Args) => R just so that by looking at the type (of e.g. createResource createEffect createComputation etc. that the thing reacts/re-runs on signal changes
2. Named tuples: createSignal<T>(...): [get: () => T, set: (t: T) => void]
3. Add JSDoc style comments to help with automatic API reference docs

[zhaoyao91]

API idea: context.use()

as we already created a context object by createContext, we could just add a function use to it instead of importing and using useContext(someContext), which could also be considered as counterpart of context.Provider.

[yacinehmito]

Small DX feedback: typing JSX.Element is a bit annoying.
One cannot benefit much from autocompletion in one go, as VSCode cannot see inside namespaces until they are imported.
So, I would type JSX, autocomplete to add the import automatically, then type .E, then autocomplete again.

Also, when doing so, the import ends ups being the following:

import { JSX } from "solid-js/jsx-runtime";

Whereas I would rather have:

import { JSX } from "solid-js";

Suggestion: reexport JSX.Element in solid-js, so I would type El, then autocomplete for an automatic import from solid-js, like so:

import { Element } from "solid-js";

I realise Element is already defined in the global scope; JSXElement or SolidElement would work just as well if this is an issue.

[ryansolid]

I do already expose:

import { JSX } from "solid-js";

But short cutting element is interesting. Most VDOM libraries don't deal with this since they already export their VDOM node separately which basically === JSX.Element. Since we have none this seems reasonable. Naming seems annoying. SolidElement is what came to mind to me as well but it is verbose. In general, I think this is a good idea though.

[yacinehmito]

I do already expose:

import { JSX } from "solid-js";

I realize I didn't word my initial comment properly.
What I meant to say is that, although JSX is indeed exported from solid-js, VSCode for some reason picks up the one exported from solid-js/jsx-runtime.

---

More information as to why I rely on JSX.Element a lot:

1. Subjective reason: I dislike the fat arrow syntax for top-level declarations, so I define components with function. To have them well-typed, I put JSX.Element as the return type.
2. Objective reason: By default, Component accepts children. I'd rather be purposeful about this. I don't want the consumers of a component to specify children if they are not going to be used by the component.

[yacinehmito]

Another small DX feedback: lazy() kind of forces the user to export components as default.

One thing I like with JSX-first libraries, as opposed to templates-first libraries, is that one file can host many components.
As I have been learning Solid, I found that I would create components that are much more granular, which exemplified this. Thus, I have been exclusively exporting named component.

When came the time to use lazy(), I had to resort to the following "hack":

const LazyComponent = lazy(async () => ({ default: (await import('./my-component')).NonDefaultComponent) }));

To make this a bit easier, I defined the following wrapper:

import { Component, lazy as defaultLazy } from "solid-js";

export function lazy<T extends Component<any>>(
  fn: () => Promise<{
    default: T;
  }>
): T & {
  preload: () => Promise<T>;
};
export function lazy<
  M extends { [key: string]: Component<any> },
  K extends keyof M
>(
  fn: () => Promise<M>,
  key: K
): M[K] & {
  preload: () => Promise<M[K]>;
};
export function lazy<M extends object, T extends Component<any>>(
  fn: () => Promise<M>,
  accessor: (module: M) => T
): T & {
  preload: () => Promise<T>;
};
export function lazy(
  fn: () => Promise<any>,
  accessor?: (module: any) => any
): Component & {
  preload: () => Promise<Component>;
} {
  if (typeof accessor === "undefined") {
    return defaultLazy(fn);
  }
  if (typeof accessor === "string") {
    return defaultLazy(async () => {
      return { default: (await fn())[accessor] };
    });
  }
  return defaultLazy(async () => {
    return { default: accessor(await fn()) };
  });
}

It can be used this way:

const LazyComponent = lazy(() => import('./my-component'), "NonDefaultComponent");

Or this way:

const LazyComponent = lazy(() => import('./my-component'), (module) => module.NonDefaultComponent);

It typechecks and autocompletes nicely. It is also compatible with the current definition of lazy() as the behaviour is left unchanged when only one argument is provided.

Would you be keen on exposing a similar API?

[ryansolid]

I just copied React here to the letter. Although I do see the reason for it. The problem is with a dynamic import the whole file is getting pulled in any way. There is no code splitting from the other components in the file. While nothing stops from letting people name the import technically the whole file is getting pulled in.

Relevant React issue: reactjs/rfcs#64. It does seem people really fighting for named exports. They didn't scratch it off but they didn't want it to potentially limit what they wanted to accomplish.

In general while JSX libraries let you use named exports they will tend to push you towards default exports as they have no way of knowing what a Component is at compile time in most cases. Especially with function components. For example Hot Module Replacement also relies on default exports. It is useful to build things around the convention that a .jsx files default export is a component.

So while multiple components are encouraged in most JSX libraries having more than one main component is less so.

[yacinehmito]

Thank you for the perspective. I hadn't thought of all this.

For example Hot Module Replacement also relies on default exports.

What motivates this limitation?

[ryansolid]

Hmm.. I looked a bit more and it might not actually be a limitation for React. I saw some interesting issues where named exports weren't working properly, but I haven't found any documentation that said this explicitly. Preact (prefresh) has this limitation. Mostly it comes down to identifying components. But I suppose it would be possible if the right conventions were set. I actually think given we are moving towards the convention of forcing .jsx extensions we probably could handle this easier than libraries that just use .js extensions. Something to consider.

[ryansolid]

Ok I have one last change I want to get in for 1.0. It is syntax but it will affect most projects. I wish to rename createState to createStore and move createStore, createMutable, reconcile, and provide into a separate submodule solid-js/store.

I believe this accomplishes the following:

1. Through naming makes it clearer when you should be using proxies instead of signals. This naming suggests that this intended for model data, or things that require special consideration. Proxies tend to push you to consolidate versus group things by behavior. In most cases Signals are a better option for scaling and maintaining components.
2. It is easy to find when you think, I need a store in Solid. The proxy objects are also the interopt point for most 3rd party state management solutions with things like reconcile. It makes it clearer that Solid has a built in base solution.
3. It reduces the number of topics that need to be taught. You have the base reactivity and you have reactive stores. In a sense we combine 2 existing concepts into 1. This makes it easier to teach leveraging people's existing familiarity with the term.
4. Moving to a separate sub module cleans up the core a bit and also lets this have a life of its own where we can give it more directed focus and consideration.
5. It removes ambiguity with React. Solid's proxies were named after React's class component state, but these days no one uses class components anymore and useState is very different. By cutting the tie it is clear that these are not the same thing.
6. It compares favorably with Svelte's store solution. Svelte's store are powerful being a primitive but they are also a bit simple from the perspective single value notifies everything. Solid's proxies are like having your memoized selectors built-in.
7. It gives us a better looking bundlephophia score. Preact and Svelte leverage this a ton in making their libraries look small. The reason Solid apps generally are smaller than Preact even though Preact is 4kb and Solid is 7.5kb is because Preact isn't actually 4kb. They package hooks and compat etc as seperate sub modules. Same with Svelte, who package svelte/motion and transitions under different sub modules.

Interested in any thoughts. Anything I might be missing.

[seneca]

I like that change. Solid creatState acts more like a store anyway, because it can accept more than one argument. React useState can only accept one (if I am not mistaken).

[bluenote10]

By pure chance, I just saw that 1.0 has been tagged a moment ago 😱 🎉

Congrats to 1.0! Great to see that milestone reached, and thanks for all the hard work!

[ryansolid]

Thank you. It took a lot longer to get here than I anticipated. I think I estimated 6 more months in Summer 2019 but happy to be here.

Thanks.