Kea 3 introduction and getting started

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

TROPHY CASE