4 ms·

Kea 3.0 – State Management via Logic Builders

• muhehe 4y ago
  I was happy there is some interesting improvement to kea DHCP server, but it's just another react library.
  • sofixa 4y ago
    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)
• rendall 4y ago
  Has anyone reading this used Kea, especially in production, and what was your experience?
  • Twixes 4y ago
    We use it in prod at PostHog (https://posthog.com/ 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 4y ago
      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-structure https://redux.js.org/tutorials/essentials/part-2-app-structu... - https://redux.js.org/introduction/why-rtk-is-redux-today https://redux.js.org/introduction/why-rtk-is-redux-today - https://redux.js.org/tutorials/typescript-quick-start 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 4y ago
        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 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 4y ago
          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 :)
          • 4y ago
  • pauldambra 4y ago
    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
• jitl 4y ago
  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 4y ago
    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.
    • jitl 4y ago
      Yes - having an architecture that ensures maintainability is critical. But good architecture needn't require this much boilerplate. There is a lot of non-linear control flow encoded implicitly in calls to `kea`, `actions`, `listeners` in this framework, and for what? Here's one of the examples from the docs (https://keajs.org/docs/core/listeners/#error-handling https://keajs.org/docs/core/listeners/#error-handling) kea([ actions({ loadUsers: true, loadUsersSuccess: (users) => ({ users }), loadUsersFailure: (error) => ({ error }), }), reducers({ users: [ [], { loadUsersSuccess: (_, { users }) => users, }, ], usersLoading: [ false, { loadUsers: () => true, loadUsersSuccess: () => false, loadUsersFailure: () => false, }, ], usersError: [ null, { loadUsers: () => null, loadUsersFailure: (_, { error }) => error, }, ], }), listeners(({ actions }) => ({ loadUsers: async () => { try { const users = await api.get('users') actions.loadUsersSuccess(users) } catch (error) { actions.loadUsersFailure(error.message) } }, })), ]) I argue that an API with a different shape could implement the same behavior in a more direct readable style, without giving up any of the nice debugging, etc that you get with Kea's abstractions. class Users extends OtherKeaAPI { users = this.state<User[]>([]) usersLoading = this.state(false) usersError = this.state<Error | null>(null) loadUsers = this.action(action => { this.usersLoading = true this.usersError = null action.effect('load em up', async () => { try { this.loadUsersSuccess(await api.get('users')) } catch (error) { this.loadUsersFailure(error) } }) }) loadUsersSuccess = this.action((users: User[]) => { this.usersLoading = false this.users = users }) loadUsersFailure = this.action((error: Error) => { this.usersLoading = false this.usersError = error }) }
• wdb 4y ago
  I have used it while trying to contribute to a project but I found it not that easy to use and quite confusing
• imachine1980_ 4y ago
  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.
  • mariusandra 4y ago
    lol. First, it's 2 rewrites. Second, those were all 98% backwards compatible for the users (might need to upgrade plugins), and just refactored the internals. But sure, let's all write perfect code on day 0, taking into account all the ways libraries you depend on (React) can develop in the future. It's not like "frontend" is a moving target or anything... /s