agile VS jotai

If you want to know more checkout this repo:https://github.com/agile-ts/agile

I was wondering about this weird question as I'm trying to build a fast State-Management framework. And currently, I'm micro optimizing it to make it as fast as possible.

I faced the same issue, and so I created a State Management library (AgileTs) based on the neat atom concept of Recoil. AgileTs isn't bound to React, and therefore the global States can be modified and accessed outside the React tree.

Doucmentation

This allows you to preview and edit your global bound States at runtime. For example, the core of the AgileTs documentation is globally bound for better debugging. Note that you should avoid attaching your application States to the globalThis in production because then third parties can easily interfere in your internal application logic. Since the AgileTs documentation has no vulnerable logic under the hood, the core is also accessible in production. Thus you can play around with the AgileTs documentation core and, for example, update the NPM_DOWNLOADS State or update the astronaut color.

It might sound self-indulgent, but my favorite State Manager is, of course, the one I've created myself called AgileTs. It's a singleton-based State Manager, which means your States are singletons, and are not tied to a single source of truth store object. This gives you much more flexibility in structuring your store the way you need it. Here are some Style Guides on how you might structure your application using such a singleton State Management approach \^)

Well.. AgileTs is a simple state manager that is supposed to be an alternative to redux, mobx and zustand..

Well.. that depends on the project.. (In my opinion) There is often no need for external dependencies on small projects like a single-page application, apart from nextjs, (since I want good performance). If it's a more significant project with more advanced logic, I always have a State Management Framework like AgileTs in action because passing states through multiple components is annoying. Regarding UI components, I try to build my own components as much as possible and only use external components if these correspond precisely to my needs. For instance, toastify is often an external dependency in my projects.

Daishi Kato, creator of Zustand and Jotai, says there are a few things we need to support RSC serialization:

I've just published jotai-wrapper, a super tiny and simple utility library that makes using jotai even simpler. It comes from the necessity to migrate a project with react-context-slices to jotai. Both libraries share a similar API. While in react-context-slices you have the useSlice hook, in jotai you have the useAtom, useSetAtom, and useAtomValue hooks. In react-context-slices you define either React Context or Redux slices, while in jotai you define atoms. The need for the migration from the first to the second was a high memory usage by react-context-slices when using React Context slices.

Atom-based: splits states into tiny pieces of data called atoms, which can be written to and read from using React hooks. In this group, we have Recoil and Jotai.

jotai Is the signal based state manager I recommended, offering the best developer experience (in my opinion) as it eliminates the necessity to define and update a global store

Jotai 🧙‍♂️

Atomic libs include Recoil, Jotai, and the one I maintain: Zedux. Zedux especially was designed to work well with sockets and RxJS observables and has been getting some traction recently, so of course I recommend checking it out. Feel free to hmu with any questions.

Global State Machine: Jotai (great for any state that needs to be stored globally for your application)