[HN Gopher] Kea 3.0 - State Management via Logic Builders
___________________________________________________________________
Kea 3.0 - State Management via Logic Builders
Author : mariusandra
Score : 33 points
Date : 2022-05-12 14:49 UTC (8 hours ago)
(HTM) web link (keajs.org)
(TXT) w3m dump (keajs.org)
| imachine1980_ wrote:
| 3 re-writes from scratch in 6 years, I know front end is dynamic
| but to be useful ship a code and mantain it. Crap tool is better
| than unestable one.
| wdb wrote:
| I have used it while trying to contribute to a project but I
| found it not that easy to use and quite confusing
| muhehe wrote:
| I was happy there is some interesting improvement to kea DHCP
| server, but it's just another react library.
| sofixa wrote:
| Same here. Kea DHCP desperately needs some love, it's barely
| better than the venerable ISC DHCP server which is a pain for a
| modern deployments (HA, API)
| jitl wrote:
| To my eye, this architecture still forces too much needless
| boilerplate. Seems like it will work well for apps that have a
| low number of very important features. Apps that naturally have a
| lot of systems will end up paying a high overhead multiplier over
| time.
| mariusandra wrote:
| OP here, so call me biased, but I tend to disagree. Curious to
| hear your thought on alternative or better approaches to system
| design here.
|
| In my experience you need some amount of boilerplate, or what
| I'd call _architecture_, to have a stable system. Give too much
| freedom ("just use get/set" or "variables on context"), and not
| only can no other developer on your team not maintain your
| code, but no part of your app will work together after a while.
| You'll end up with multiple incompatible implementations of ad-
| hoc state machines.
|
| The key to maintainability is to use a framework that forces
| you to do spend a bit more effort than you'd do when coding
| YOLO, but which forces everyone on the team to make the same
| tradeoff. The result: everyone can jump in to any part of the
| project and with a bit of digging around be fluent in the
| surroundings.
|
| Kea seems to strike a pretty good balance of making this
| possible in large projects.
| rendall wrote:
| Has anyone reading this used Kea, especially in production, and
| what was your experience?
| pauldambra wrote:
| A bit like introducing immutability removes bugs you don't
| understand... each time I see us replace some `useState`
| `useEffect` orchestration with a kea logic things get less
| buggy
| Twixes wrote:
| We use it in prod at PostHog (https://posthog.com/) and it's
| SUPER practical as an abstraction over Redux's boilerplate.
| Also makes for really sensible separation of logic from
| presentation. Only TypeScript support requires a bit of
| additional setup as type inference doesn't work with this
| architecture.
| acemarke wrote:
| Just out of curiosity, have you seen our official Redux
| Toolkit package? We specifically designed it to eliminate the
| "boilerplate" concerns and work great with TS:
|
| - https://redux.js.org/tutorials/essentials/part-2-app-
| structu...
|
| - https://redux.js.org/introduction/why-rtk-is-redux-today
|
| - https://redux.js.org/tutorials/typescript-quick-start
|
| I'm also interested in hearing any particular features in Kea
| you find useful that aren't covered in RTK.
| mariusandra wrote:
| Well, in PostHog (I'm a colleague of Twixes), we just
| decided here [1] to go with Kea, as I had more experience
| with it.
|
| Had Redux Toolkit been around when I started with Redux in
| 2016, I probably wouldn't have needed to write Kea. However
| I'm glad I did, as I now do consider Kea to be the better
| toolkit for the same job. :D. I know you disagree, and
| that's all fine of course :).
|
| In my mind Kea fills in all the missing parts from React,
| while Redux Toolkit is still a set of utility functions for
| state management. You still need to find another set of
| tools for data loading (I see this has improved), complex
| data or form management, app routing, scene handling, etc.
| Redux Toolkit doesn't bother with most of that, and I don't
| think it should.
|
| Kea however comes with solutions for all of those. The only
| thing missing from being able to build a complete app is a
| JS module bundler. Just sit down and start writing your
| actual app with the least amount of syntax possible to
| explain things in a redux'y way. Many people have told me
| that with Kea, the framework basically gets out of the way
| and disappears.
|
| Now with the Kea 3.0 Logic Builder syntax, Kea is suddenly
| like lego for state management. I'm curious to see if this
| picks up or not. I can't unfortunately link Kea from
| redux.js.org to drive traffic :).
|
| [1] https://github.com/PostHog/posthog/issues/301 -- the
| magic of working in an open source company is that we can
| post stuff like this. We're hiring!
| acemarke wrote:
| Haha, nice, that does explain why PostHog adopted Kea! :)
|
| I know I've said this in a couple issue threads, but just
| to re-state it publicly:
|
| As Redux maintainer and RTK creator, I do feel RTK is the
| best approach for using Redux, and that's why we now
| teach it as default.
|
| But it's great that you've been able to build out an
| alternate toolset on top of the Redux core that suits
| your needs and share that, and it's _also_ my job as
| maintainer to make sure that you still have the tools
| available to keep that working. (which is why even though
| I've marked `createStore` as deprecated per our prior
| issue threads, we're not going to _remove_ it - too many
| apps and libs depend on it as-is.)
|
| And yeah, agreed that Kea and RTK have different areas of
| focus. We don't _want_ to handle routing or forms :)
| pauldambra wrote:
| that's far too considerate an opinion to put on the
| internet :)
___________________________________________________________________
(page generated 2022-05-12 23:02 UTC)