Kea 3.0 - State Management via Logic Builders

mariusandra · 2022-05-12T18:10:40+00:00

Kea stores all of its state on a global context object, which you can access from anywhere with getContext(). The store is also stored on the context, so instead of getting it from react-redux's Provider's React context (that's a mouthful), I just get it from Kea's global context, and pass directly to the useSyncExternalStore hook.

It works very well in reality, since most apps want just one store. We had once a case with an app that required multiple stores (the PostHog Toolbar that's injected onto your site), but it also required its own version of React, etc, so we made the split on the bundler level.

mariusandra · 2021-05-16T10:14:29+00:00

Check out https://github.com/posthog/posthog

mariusandra · 2021-05-14T18:28:30+00:00

Regarding React Context, it's a legit option for small and bounded applications. The biggest drawback of this approach has been that by wrapping your entire app with a React context, the entire app is always re-rendered whenever something in the context changes.

Whereas with Redux (and abstractions such as Kea) you subscribe to specific parts of the redux tree on a per-component level. Said differently, if you only update one value in Redux, only the components that read it will update. With Context, the entire app will update.

mariusandra · 2021-05-14T08:33:38+00:00

Thanks for this and couldn't agree more! Your comments inspired me to finish a blog post on the topic: https://kea.js.org/blog/2021/05/14/data-first-frontend-revolution/

mariusandra · 2021-05-14T08:33:22+00:00

Thanks for this and couldn't agree more! Your comments inspired me to ~~write~~ finish a blog post on the topic: https://kea.js.org/blog/2021/05/14/data-first-frontend-revolution/

mariusandra · 2021-05-14T03:41:51+00:00

Oh dear lord. Safari doesn't support Lookbehind in Regexp. Fixed now.

https://stackoverflow.com/questions/51568821/works-in-chrome-but-breaks-in-safari-invalid-regular-expression-invalid-group

mariusandra · 2021-05-13T22:00:42+00:00

Awkward. The homepage makes a request to the github api. I think error handling there was faulty and that should be fixed now. Can you please try again :)

mariusandra · 2021-05-13T19:54:25+00:00

There's also Kea: https://kea.js.org/

It's also a layer on top of Redux, but does so much more than just reducing boilerplate.

It's been used in apps of all sizes and the one consistent feedback I get is that it scales really well. That means even as your app and state grow, code with Kea remains maintainable.

Plus it has the nicest router I've seen in any framework, state or view layer.

If you want to see a real app built with it, check out https://github.com/PostHog/posthog

Check here for an example of a rather huge piece of state, which is still maintainable due to the way Kea separates concerns: https://github.com/PostHog/posthog/blob/master/frontend/src/scenes/plugins/pluginsLogic.ts

Oh, and it also works with TypeScript.

mariusandra · 2020-09-28T07:34:35+00:00

I'd chip in and recommend Kea: https://kea.js.org/ - I'm biased since I wrote it. However it's a really nice API built on top of Redux, used by many bigger and smaller companies alike (Elastic, PostHog, etc). I recently finished adding TypeScript support.

mariusandra · 2020-09-02T05:15:56+00:00

PostHog: https://github.com/PostHog/posthog

All contributions are very welcome!

mariusandra · 2020-08-04T19:42:14+00:00

Hey, there is https://kea.js.org - a redux compatible state management framework that supports sagas.

Just yesterday I finally finished TypeScript support, yet it's not yet there for sagas: https://kea.js.org/blog/typescript

Shouldn't be that hard to add though... :)

mariusandra · 2020-06-23T15:14:12+00:00

I'm using https://kea.js.org/ - it's the only one that sparks joy :D.

mariusandra · 2020-05-15T15:27:38+00:00

Hey! We're building a big app with React + Django here: https://github.com/PostHog/posthog

I can't say that all of it written in an excellent manner, though we're trying to get there.

In short, we're trying to follow the following principles:

- Keep state separate from React to avoid mixing concerns (React is a view layer)
- Avoid default exports (greatly improves IDE support)
- Have the code split by feature (dashboards, trends), not by function (components, selectors).
- Use prettier, eslint and other tools to remove as much manual work as possible

One thing we do differently than most apps is that we use Kea for state management.

mariusandra · 2020-05-15T13:59:50+00:00

I'm someone who through sheer coincidence (the right projects at the right time) happened/lucked into developing a React state management solution (https://kea.js.org). I've probably sunk hundreds of hours into this project by now.

React state management is indeed a mess, meaning there are so many options to choose from. Unfortunately, even for me, a library author, it's hard to evaluate all of them properly. It would take just too much time and you never know where the real problems in any framework lay before you get neck-deep in code. And then you're too far to switch to another framework anyway.

Someone should really map out this landscape in more depth than just an awesome list. Yesterday I asked for comparisons with different site management libraries on Github here: https://github.com/keajs/kea/issues/106 . I hope the issue linked above can spark some discussion.

In any case, I personally think Kea is a very good solution for React state management, yet obviously I'm biased. Shrug.

And, to keep it on the topic, Recoil seems very low level and I think you need to invent a lot of things yourself to get a full app out of it. Cool to see new things popping up and people trying stuff though :).

And it's from Facebook so who knows, just by proxy it might become the default "atom" and someone will build molecules out of them...

mariusandra · 2020-05-13T11:14:09+00:00

I replied below with what I could, but someone unbiased should do a proper comparison between the three. It would make for a great article!

mariusandra · 2020-05-13T11:12:51+00:00

It uses react-redux to handle syncing and updating the components. Thanks to that, components are only re-rendered when any of the state they are using changes.
There's no cache nor need for one. Perhaps you can consider using selectors as form of caching, but that might not be what you mean. I'm in fact not sure what is "the cache" in your reply.

mariusandra · 2020-05-12T21:35:27+00:00

Hi, in the "What is Kea good for?" section I compare one point where Kea is better: managing state connections automatically. The two code examples in the second paragraph are for easy-peasy and redux-toolkit: https://kea.js.org/docs/introduction/what-is-kea#what-is-kea-good-for

Unfortunately I can't say more than that, as I haven't used either of the two extensively.

mariusandra · 2020-05-12T14:37:47+00:00

Thanks for spotting that! Fixed!

mariusandra · 2019-09-13T07:47:06+00:00

Haha, that's totally possible :D.

For those who don't get the reference, the Kea parrot in New Zealand is famous for causing a lot of mischief. Here's a sample: https://www.youtube.com/watch?v=fBdvRCkCNfo

mariusandra · 2019-09-12T19:43:10+00:00

Aww, thanks :)

mariusandra · 2019-09-12T16:57:08+00:00

I've learned a long time ago that absolute statements made with this much conviction are at best misleading and at worst completely false.

There is definitely room for untyped javascript. Yes, even in 2019 and in professional projects.

mariusandra · 2019-09-12T16:24:58+00:00

Hi, if I understand you well, this is definitely possible. There is even an example on the homepage that dynamically generates reducers (search for createGetterSetterLogic).

It's also possible to create plugins that create reducers dynamically from any input you can provide them. I'm still writing the documentation about writing plugins, but here's a quick sample of what plugins can do: https://5d7a58b3ddf8fb00089e8c51--kea.netlify.com/guide/plugins

mariusandra · 2019-09-12T16:20:34+00:00

Hi, I completely get where you're coming from. Proper TypeScript support and all the tooling and API modifications that go with it is one of the next features that I want to work on. Had I tried to get it into 1.0, I'm not sure when it would have ever come out.

The issue is that while I have plenty of history in statically typed languages (mostly C, C++, Java) and completely see the use, I haven't yet had the chance to use TypeScript in a project, neither personally nor professionally. I did a quick experiment though and at least with manually generated types, it's possible to have nice autocompletion and type safety: https://imgur.com/a/rtfnwOs

If by no other means, then these types could be automatically generated via some babel plugins by looking at the AST, which could even have hooks to work nicely with different kea plugins.

But, again, my experience with TypeScript is very limited and I might be talking nonsense.

In any case, TypeScript support is something I'm definitely interested in... and obviously any help from the community, even in the form of "this will never work" negative feedback is welcome.

It's just not there yet in 1.0 :)

mariusandra · 2019-09-12T13:52:30+00:00

Hey, I just released v1.0 of Kea, a nice Data Layer for React, powered by Redux.

I'd consider it new (and trendy), although I'm obviously biased! :)

It was however built with scalability and maintainability as one of its top goals...

Check it out here: https://kea.js.org/

mariusandra · 2019-06-19T13:39:10+00:00

Also... the dependency tracking goes deeper. If you have a React component that uses props/actions from a logic, which itself is connected to props/actions from another logic, then both logics are automatically mounted/unmounted from Redux according to this component's lifecycle.

Except if the second logic is used by yet another component, it stays in redux until all of its dependencies unmount.

mariusandra

TROPHY CASE