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

Recoil – A state management library for React

recoiljs.org

Post reply on HN
Print view View original

21–30 of 83 posts

Re: Recoil – A state management library for React

#21

Post by concerned_user »

flowerlad wrote: post #19

What is it about React that state management is such a such a hassle? This is not the case in other frameworks. Consider iOS for example. Just add fields in App and you're done: https://developer.apple.com/documentation/swift/maintaining_... Similarly in ASP.NET: https://docs.microsoft.com/en-us/previous-versions/aspnet/75... Same in JSP: https://javabeginnerstutorial.com/jsp-tutorial/state-managem... But in React it…

React is not a complete framework more of a templating engine and nothing more, it allows you to use any state management you want. It also makes it easy to add to existing projects without requiring rewrite of everything from the ground up.

Re: Recoil – A state management library for React

#22

Post by nikivi »

flowerlad wrote: post #19

What is it about React that state management is such a such a hassle? This is not the case in other frameworks. Consider iOS for example. Just add fields in App and you're done: https://developer.apple.com/documentation/swift/maintaining_... Similarly in ASP.NET: https://docs.microsoft.com/en-us/previous-versions/aspnet/75... Same in JSP: https://javabeginnerstutorial.com/jsp-tutorial/state-managem... But in React it…

Perhaps it's due to React's architecture of one way data flow?

Re: Recoil – A state management library for React

#23

Post by simongray »

flowerlad wrote: post #19

What is it about React that state management is such a such a hassle? This is not the case in other frameworks. Consider iOS for example. Just add fields in App and you're done: https://developer.apple.com/documentation/swift/maintaining_... Similarly in ASP.NET: https://docs.microsoft.com/en-us/previous-versions/aspnet/75... Same in JSP: https://javabeginnerstutorial.com/jsp-tutorial/state-managem... But in React it…

> What is it about React that state management is such a such a hassle?

I'm not sure it's a hassle, just different schools of thought.

> This is not the case in other frameworks.

None of the examples you mention are reactive AFAIK. The point of React is that the UI is a function of the state. How exactly that is accomplished is where those different schools of thought come into the picture.

Re: Recoil – A state management library for React

#24

Post by tekkk »

vosper wrote: post #7
weeksie wrote: post #3

I'm not seeing how this works with more complex state flows. Doesn't seem much better than useReducer. Frankly, for state management I still haven't found anything that beats Redux on its own without thunks or sagas or any of that bullshit. This is despite doing my level best to see if useReducer on its own would be sufficient. It's not. Thunks are unmaintainable. Sagas are put together with bailing twine and rely to…

> I still haven't found anything that beats Redux on its own without thunks or sagas There was a period in the early days of Redux where MobX [0] (and, perhaps to a lesser extend, MobX State Tree [1]) was the main competitor to Redux that I used to hear about. They both seem to be actively developed, but I don't hear so much about them any more. Have you ever look at either of them? BTW I am 100% with you on Sagas. […

At least in the company where I worked in, everyone agreed that Mobx was the better option between it and Redux. It's so much more intuitive to grasp and using simple functions and objects much easier, than having to grok weird async-flows and cumbersome action-generators and whatnot.

Only problem so far, or inconvenience maybe, is the sometimes complicated ways you come to intertwine stores which have access to different parts of the fetched API data. So if you need data Y stored in store X inside store Z, you have to inject store X as dependency to store Z. Getting too carried way with these injections can make your whole state quite messy. Or loading too much logic into one store.

Probably that's just an architectural issue, that can be remedied with enough thought put into it, but I haven't at least found a clear pattern that would make it simple to decide when to break up stores, or how to refactor them.

Also you have be aware of the complexities of observables which are a bit magical. Knowing when observables don't update and how to observe in general is very much a necessity (unless you want interesting bugs).

I have been curious to try out Mobx State Tree but alas haven't had time.

Re: Recoil – A state management library for React

#25

Post by MoSattler »

weeksie wrote: post #3

I'm not seeing how this works with more complex state flows. Doesn't seem much better than useReducer. Frankly, for state management I still haven't found anything that beats Redux on its own without thunks or sagas or any of that bullshit. This is despite doing my level best to see if useReducer on its own would be sufficient. It's not. Thunks are unmaintainable. Sagas are put together with bailing twine and rely to…

Having worked many years on mid to large scale React apps, I must say: In most cases component state (or useSate) and context works just fine.

Why is everyone so eager to add third party state libraries from the getgo? In most projects, Redux doesn't add net value.

Re: Recoil – A state management library for React

#26

Post by flowerlad »

simongray wrote: post #23
flowerlad wrote: post #19

What is it about React that state management is such a such a hassle? This is not the case in other frameworks. Consider iOS for example. Just add fields in App and you're done: https://developer.apple.com/documentation/swift/maintaining_... Similarly in ASP.NET: https://docs.microsoft.com/en-us/previous-versions/aspnet/75... Same in JSP: https://javabeginnerstutorial.com/jsp-tutorial/state-managem... But in React it…

> What is it about React that state management is such a such a hassle? I'm not sure it's a hassle, just different schools of thought. > This is not the case in other frameworks. None of the examples you mention are reactive AFAIK. The point of React is that the UI is a function of the state. How exactly that is accomplished is where those different schools of thought come into the picture.

You can use React with traditional MVC to get the benefits you mention and still avoid state management hassle.

Here's one such lib: https://www.npmjs.com/package/mvc-router-spa

Re: Recoil – A state management library for React

#27

Post by gregkerzhner »

flowerlad wrote: post #19

What is it about React that state management is such a such a hassle? This is not the case in other frameworks. Consider iOS for example. Just add fields in App and you're done: https://developer.apple.com/documentation/swift/maintaining_... Similarly in ASP.NET: https://docs.microsoft.com/en-us/previous-versions/aspnet/75... Same in JSP: https://javabeginnerstutorial.com/jsp-tutorial/state-managem... But in React it…

Don't have experience with ASP or JSP, but managing state in React is vastly superior than iOS. Having a defined place to keep your data, and your view automatically refresh when it changes is the gold standard in user interface design. iOS does not easily have this kind of functionality, forcing people to use all sorts of messy techniques that are hard to follow and maintain.

The main "Apple approved" tools for user interface and state management are CoreData and UIKit. Both are imperative, mutable, and overall difficult to work with. This might be subjective, but I always notice just how poorly Apple's own apps work. There is always some button that is stuck in the wrong state, some feature that doesn't do what its supposed to, and some broken animation when views reload (I'm looking at you Podcast app). I can't know why, but my hunch is that Apple engineers are forced to use unwieldy patterns and technologies like CoreData, MVC, and UIKit, and are drowning in a sea of unmaintainable code.

As a response to the inadequate tools Apple provides, big industry leaders have stepped up and rolled their own declarative solutions. IGListKit from Instagram is a prime example of a declarative user interface solution thats vastly superior to Apple's. Going even further, Facebook basically ported React into iOS with ComponentKit.

It took Apple a good decade, but they are finally giving us these types of tools as well with SwiftUI. However, judging from its low adoption, so far they have not managed to fully get things right.

Re: Recoil – A state management library for React

#28

Post by Keats »

topspin wrote: post #18
armandososa wrote: post #13

Earlier quoted context omitted.

MobX State Tree advocate here. We have a VERY complex state that needs to be synced with the server and persisted locally and nothing fulfilled our needs like MST. Also, sign me up to the Sagas-are-bullshit club.

Mobx itself is insufficient? What does mobx-state-tree provide that mobx does not? The README doesn't convey anything meaningful.

Mobx itself is fine for most usecases I think. I've used it on 4-5 projects now and it's been working very well in each.

Re: Recoil – A state management library for React

#29

Post by flowerlad »

gregkerzhner wrote: post #27
flowerlad wrote: post #19

What is it about React that state management is such a such a hassle? This is not the case in other frameworks. Consider iOS for example. Just add fields in App and you're done: https://developer.apple.com/documentation/swift/maintaining_... Similarly in ASP.NET: https://docs.microsoft.com/en-us/previous-versions/aspnet/75... Same in JSP: https://javabeginnerstutorial.com/jsp-tutorial/state-managem... But in React it…

Don't have experience with ASP or JSP, but managing state in React is vastly superior than iOS. Having a defined place to keep your data, and your view automatically refresh when it changes is the gold standard in user interface design. iOS does not easily have this kind of functionality, forcing people to use all sorts of messy techniques that are hard to follow and maintain. The main "Apple approved" tools for user…

> Having a defined place to keep your data, and your view automatically refresh when it changes is the gold standard in user interface design.

First, in most frameworks there is only one place to keep your data. This can be your App object or session state.

Having view automatically refresh is overrated. Given the amount of work you have to do (actions, reducers, dispatch and whatnot) it is easier to just update the view yourself.

Post reply on HN