Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Overmind.js – Frictionless State Management

overmindjs.org

Post reply on HN
Print view View original

41–48 of 48 posts

Re: Overmind.js – Frictionless State Management

#41

Post by darepublic »

christianalfoni wrote: post #12

Hi there and thanks for the feedback on "Why even choose this". Will update the front page! But to answer your question. The main reason Overmind and its predecessor Cerebral ( https://cerebraljs.com/ ) was developed is application insight. The complexity of what we build on the web these days is way beyond the scope of what our brains are able to comprehend. What effects are triggered and what state changes are made…

Interesting stuff I am generally skeptical of new webdev frameworks but I will check this out

Re: Overmind.js – Frictionless State Management

#42

Post by Emanation »

chansiky wrote: post #40
ZephyrBlu wrote: post #28

Earlier quoted context omitted.

This is definitely not true, especially if you co-locate your data fetching in your reducers, which is a common pattern. It also provides a single, centralized store instead of needing many context's and lets you abstract data shape/formatting logic away instead of having it in your application. Context and State are great, but they serve a different purpose than Redux.

Having used hooks to replace my state at some point I couldn't agree more. Application state should not be dependent on components, rather components should be dependent on application state. My recommendation is keep hooks and contexts for ui state only, like form fields/validations, modal popups, drawer collapse, filter options, etc, but for things dealing with more general application state which the ui will displ…

Why should a seperate state machine be used? Redux doesn't magically seperate state information from the tree. It's built upon react context/provider system, which in effect can be seen as a component.

The special sauce, in regards to seperation, is that it can be wired into the component tree without passing it down, which is a property of provider/context and not redux itself.

Re: Overmind.js – Frictionless State Management

#43

Post by alluro2 »

amw-zero wrote: post #27
onion2k wrote: post #21

Earlier quoted context omitted.

Redux was first released more than 5 years ago, it's had more than 3000 commits merged from more than 800 developers, and there have been 69 releases. That's a lot of learning about how to do state management in JS. I would argue that's beyond what an individual developer could ever do. Mobx has similarly large numbers - almost 3000 commits from more than 400 developers. No doubt other popular state libraries also ha…

What does the number of commits have to do with anything? That doesn’t imply any kind of quality, right? Also, have you taken a look at the source code for Redux let’s say? It’s an extremely small library. Not exaggerating, it’s on the order of 1,000 LOC. You don’t think someone could produce that? I would agree with what you’re saying if you were talking about something like Postgres, which is enormous and complex.…

Unless you want to consider all those people who contributed as not really smart for spending their time on something that a single person can easily do along the way in their project, I'm not sure why you would suggest doing so as a better alternative.

There are numerous other discussions on whether use of a state management library is needed ever, or at least in some projects. As someone who doesn't usually actually need it, I can understand the motivation for less people to use it until they know enough to realize they need it, but also don't understand people who ignore valid needs of larger teams and projects where something like Redux makes a lot of difference and is necessary. Again, unless those people consider themselves and their projects to be the biggest and most complex that can ever be, which is very likely to be false.

Re: Overmind.js – Frictionless State Management

#44

Post by bfrydl »

deepstack wrote: post #10
feoren wrote: post #3

Read through the overview and the introduction and literally could not tell what Overmind was supposed to be helping with. Everything shown looks like just basic examples of using state normally in JavaScript. What does it actually do ?

Lib like this or Redux seems like to try to better help people who don't have CS back ground to develop. Anyone who had CS training should be able to state management in plain JS or other general purpose programming language.

I think the people disagreeing with this greatly overestimate what is actually contained in a library like Redux. An entire ecosystem sprang up around it and most of it is completely unnecessary and overly complex. The base library itself is almost nothing at all and should not be hard for anyone with experience to independently create.

Re: Overmind.js – Frictionless State Management

#45

Post by czynskee »

baron816 wrote: post #6

If you want a really frictionless state management library for React, please try out my library https://github.com/baron816/use-structure It lets you make state updates using native JavaScript mutation APIs. It uses Proxies to convert those mutable updates to be immutable so that your component updates correctly. This will work: ... const arr = useStructure([]); ... arr.push(1, 2, 3) }>Add value But you could use dee…

This looks pretty cool, I love your use of proxies. Along with that though, I'm curious if you've done any performance testing comparisons? This could very well be out of date now but at some point I read that accessing properties on a proxied object are like 600 times slower than a regular JS object. I wonder if that could be a bottleneck if you're doing state updates on, say, scroll events or something.

I've been able to notice performance hiccups in these cases even just using React state. Of course debouncing usually helps.

Re: Overmind.js – Frictionless State Management

#46

Post by baron816 »

czynskee wrote: post #45
baron816 wrote: post #6

If you want a really frictionless state management library for React, please try out my library https://github.com/baron816/use-structure It lets you make state updates using native JavaScript mutation APIs. It uses Proxies to convert those mutable updates to be immutable so that your component updates correctly. This will work: ... const arr = useStructure([]); ... arr.push(1, 2, 3) }>Add value But you could use dee…

This looks pretty cool, I love your use of proxies. Along with that though, I'm curious if you've done any performance testing comparisons? This could very well be out of date now but at some point I read that accessing properties on a proxied object are like 600 times slower than a regular JS object. I wonder if that could be a bottleneck if you're doing state updates on, say, scroll events or something. I've been a…

No, haven’t done any perf testing. I’m pretty sure Vue is moving to use Poxies, so I think it’s somewhat safe. You can still use useState where you need it.

Re: Overmind.js – Frictionless State Management

#47

Post by jeswin »

ZephyrBlu wrote: post #28
jeswin wrote: post #17

Earlier quoted context omitted.

> The third reason is TypeScript. We have all felt the pain of Redux boilerplate and with TypeScript it does not become better. Redux btw, is redundant now; and offers very little value over useContext + useState. And they work wonderfully with TypeScript.

This is definitely not true, especially if you co-locate your data fetching in your reducers, which is a common pattern. It also provides a single, centralized store instead of needing many context's and lets you abstract data shape/formatting logic away instead of having it in your application. Context and State are great, but they serve a different purpose than Redux.

> This is definitely not true, especially if you co-locate your data fetching in your reducers, which is a common pattern.

How can it be definitely not true, when you have to say "especially"? Most code I've seen (including the official docs) don't data fetch in reducers. But even then, I'm not sure what you mean.

> It also provides a single, centralized store instead of needing many contexts...

Which you can very well do with useContext and useState.

Re: Overmind.js – Frictionless State Management

#48

Post by jeswin »

chansiky wrote: post #40
ZephyrBlu wrote: post #28

Earlier quoted context omitted.

This is definitely not true, especially if you co-locate your data fetching in your reducers, which is a common pattern. It also provides a single, centralized store instead of needing many context's and lets you abstract data shape/formatting logic away instead of having it in your application. Context and State are great, but they serve a different purpose than Redux.

Having used hooks to replace my state at some point I couldn't agree more. Application state should not be dependent on components, rather components should be dependent on application state. My recommendation is keep hooks and contexts for ui state only, like form fields/validations, modal popups, drawer collapse, filter options, etc, but for things dealing with more general application state which the ui will displ…

> Application state should not be dependent on components

Sorry, I don't follow. When using Context, how does the application state become dependent on Components any more than it is with Redux? You can accomplish pretty much the same thing with far less code.

Can you provide an example?

Post reply on HN