|Intro:||what is kea? | installation | typescript | testing | debugging | context | redux|
|Core:||actions | reducers | selectors | listeners | events | defaults|
|Meta:||kea | logic | connect | key | path | props|
|React:||useActions | useValues | useMountedLogic | useAllValues | BindLogic | wrap|
|Plugins:||API | loaders | router | forms | saga | subscriptions | localstorage | window-values|
|Community:||ajax | socket.io|
New tutorial coming soon! Subscribe to the newsletter to not miss out.
I wasn't sure whether we should have an abstraction layer on top of Redux, but after using Kea for a day I never looked back. Kea feels like the good kind of magic. You can understand what’s happening, but it takes away a lot of the tedious tasks. Adding more features doesn't feel like adding more complexity.
Setting up Kea is so simple and intuitive. The best bit has to be how Kea handles form management, something that used to be a horrible experience for most frontenders, has been made so straightforward and almost trivial to achieve. Such a sane and sensible way to manage state.
We have 3-5 engineers working on the Kea codebase. We use TypeScript and have about 25 logic stores all connected via a parent app logic store. Absolutely LOVE the library and, as a engineer new to Redux, I found this to be incredibly easy to get up to speed on and it seems to scale very well.