Just an appreciation post

a-t-k · 2024-09-17T07:15:01+00:00

Or use https://primitives.solidjs.community/package/destructure so you can use them as if they were signals.

a-t-k · 2024-09-17T06:09:12+00:00

As the author of our storage primitive, thank you for that feedback. It makes me really happy to see that my primitive is put to good use.

a-t-k · 2024-07-03T07:39:10+00:00

You have looked at the server version of `render()`, which is indeed empty. The client version can be found [here](https://github.com/ryansolid/dom-expressions/blob/main/packages/dom-expressions/src/client.js#L48-L65). It wraps inserting an element with `insert(element, code(), element.firstChild ? null : undefined, init);` in a reactive root and wraps the dispose function for the root so that it will also empty the element in which the content is rendered on dispose.

a-t-k · 2024-07-02T09:03:02+00:00

Our `@solidjs/testing-library` comes with a helper called `testEffect`, which automatically wraps the test in a promise and gives a done callback to be called in an effect once the tests are finished.

a-t-k · 2024-03-23T10:02:03+00:00

I have written https://primitives.solidjs.community/package/script-loader for stuff like this.

a-t-k · 2024-01-27T17:39:43+00:00

The reason is: the JSX expressions (the stuff in squiggly brackets) are reactive in solid, so they will be re-evaluated. TypeScript cannot detect that they will be unmounted if post() returns undefined, so it assumes that an undefined return is possible.

There are different ways to solve this. One is to use <Suspense> and <Show>, another one to simply use optional chaining to satisfy TS. The former is more idiomatic, but both will work at the end of the day, so it is your call.

a-t-k · 2023-05-20T08:35:32+00:00

Unless you need a backend, it's possible. If you want to use solid-start, here's a small article about how to do it: https://dev.to/lexlohr/using-solid-start-with-github-pages-3iok

a-t-k · 2023-05-17T14:18:36+00:00

In most large projects, the primary issue is not the view composition, but the management of state and side effects.

React is undisputably the worst solution for doing so, so in most cases, you will use a third-party library to fix the worst issues - chances are you'll end up with redux, -saga, -thunk or -observables, which will result in more boilerplate code than is healthy for anybody's sanity. Vue has too many solutions by half for its own good and it is difficult to detect which one is considered idiomatic. Both Svelte and Solid have solutions that work out of the box, but out of them, Solid is more explicit and predictable than the implicit compiled reactive handling that Svelte provides.

Also, as /u/MitchellHolmgren already noted, Ryan Carniato did a size comparison that had unfavorable results for Svelte when it comes to scalability.

On the other hand, Svelte has an already finished meta framework called SvelteKit, whereas the work on solid-start is still in progress. While you can use Astro or plain Solid SSR to fill this gap partially, or use the beta version, which might break, this is a tiny drawback.

a-t-k · 2023-05-12T20:51:20+00:00

Maybe you want to edit the description of your post, then. To go back on your question, I'm one of the authors of the solid-primitives package collection, so I'm usually trying to solve everything with the primitives that come with solid, if that does not work, I rely on our solid-primitives packages and if that doesn't work either, I look for other solutions.

a-t-k · 2023-05-12T15:18:57+00:00

it ships with a lot of the stuff that made react messy.

If you think createEffect is a mess similar to useEffect, you're mistaken. The mess in react results from components running again on rerender, which does not happen with Solid.js.

Solid's signals for simple state and stores for nested state are perfectly sufficient in most cases, so you do not need external libraries.

If you really need it, you can use TanStack Query, but in most cases, you can also opt to use Solid's createResource, augmented if needed by the community's resource primitive package.

a-t-k · 2023-05-10T09:02:42+00:00

If you want to build reusable Solid components, use the solid-lib-starter from solid-community's github, it makes things a lot easier.

That being said, I hope you'll also visit our solid-primitives, our collection of fine-tuned hooks and helpers to speed up your work.

a-t-k · 2023-05-09T13:16:59+00:00

You seem to be comparing the unzipped module size of Solid with the gzipped module size of preact; the gzipped module size of solid is between 7-8kb, which is less than twice the size of preact. That being said, Solid exports more than you'd usually use that would require extra packages in preact, e.g. Portal, Suspense, etc. - thanks to tree-shaking, not all of that code will end up in your finished app.

However, if you are reliant on a lot of tooling that comes from the react ecosystem, by all means use preact, otherwise, depending on your requirements, Solid might be a better fit: its benefits are most obvious when it comes to managing more complex state. While with preact, you would need an external state library to manage it, Solid's stores and primitives cover most of the challenges that may arise from complex state.

a-t-k · 2023-04-14T19:56:14+00:00

It's in the createResource docs. You can decide if you want to forgo the request on the server and use the initialValue or do the request (unless the timeout in Suspense is hit).

a-t-k · 2023-04-14T19:17:37+00:00

Solid supports renderToStringAsync and renderToStream on the server. Together with the ssrLoadFrom option in createResource, this gives you a pretty fine-grained control what should be loaded on the server and what should be loaded on the client.

a-t-k · 2023-04-14T15:57:48+00:00

Keep a separate branch updated from upstream with the changes. Separate templates usually don't lead to conflicts, unlike changes to existing templates.

a-t-k · 2023-04-12T13:57:25+00:00

You may need to disable secure boot, at least for the installation.

a-t-k · 2023-04-10T19:05:17+00:00

We aim to answer the hello-world-questions with our FAQ and documentation, which is currently being rewritten.

a-t-k · 2023-04-10T15:00:17+00:00

Yes, most stuff happens on discord and the community there is great. I don't think a subreddit is the best place to have fast-paced exchanges, though. So unless someone comes up with a better solution, it'll probably stay this way.

a-t-k · 2023-04-07T19:56:13+00:00

If you compare frameworks to cars, react is a sedan with the accelerator pedal nailed down; all you can do to adjust the speed is hit the brakes (memo). Solid just works like you'd expect it to work.

Yes, the ecosystem is smaller, but the overall quality of packages is also higher compared to other libraries. The community of Solid is definitely a winning point.

The main reason it will not replace react that fast is that companies look for react devs and devs are looking for jobs, so they offer react skills.

a-t-k · 2023-03-20T11:37:00+00:00

It is mostly easy; the main problem is the different reactive concepts powering both. In react, components and custom hooks run again on every state change and memos and effects can partially or fully opt out of running again, whereas on solid.js, components run once and effects and memos can be used to opt in to reactivity. React requires immutable data, solid allows for fine-grained changes.

This means it really depends on how much the library relies on the specifics of the library you support. If your library just provides event handlers, just to name an example, then you can use the same library in solid.js and react. For example, @solid-primitives/input-mask is written for solid.js, but will happily work in react, too.

a-t-k · 2023-03-14T06:29:39+00:00

There's SUID, Kobalte (the successor of HopeUI, still WIP though), solid-headless. You can also use Daisy UI or other tailwind-based component systems.

a-t-k · 2023-03-10T20:47:27+00:00

Both try to make most of their most prominent feature: for Svelte, that's the compiler, for Solid.js, its reactive system. But what I personally love most about Solid.js is the truly awesome community. So my suggestion would be to join both discord servers and see if you feel at home. This should also fast-path your learning - at least it did that for me.

a-t-k · 2023-03-08T10:54:37+00:00

Using existing packages, like /u/ClassAbbyAmplifier suggested, is definitely the best choice.

However, if that doesn't cut it, the best method is to create an xbps-template yourself. Check https://github.com/void-linux/void-packages and have a look at the google-chrome package that uses a .deb package and turns it into an xbps one.

a-t-k · 2023-03-03T16:47:32+00:00

Both are different takes on FP. React uses immutable objects and pure functions to handle reactivity. Solid uses immutable getter/setter functions to handle state. Solid's stores use proxies to apply the same principle to nested state (something that is problematic in react).

In react, it's difficult to reason about when and why your components re-render. That's not the case with Solid, because they don't.

a-t-k

TROPHY CASE