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

Things I wish I knew about state management when I started writing React apps

medium.com

Post reply on HN
Print view View original

111–120 of 335 posts

Re: Things I wish I knew about state management when I started writing React apps

#111

Post by crtlaltdel »

spookthesunset wrote: post #99
itronitron wrote: post #62

Earlier quoted context omitted.

I've worked on a few applications with 'rich/complex interactions' and everyone on the team was opposed to using any sort of JS framework. That was nice because it was relatively easy for anyone to trace through the application as needed. In my experience if the application state is overly complex then that is a result of the design, and that usually leads to a bad experience for the user.

> I've worked on a few applications with 'rich/complex interactions' and everyone on the team was opposed to using any sort of JS framework Ah but if you actually looked at what you built, I am 100% sure you folks built your own framework instead. A framework that has no community support, no stackoverflow articles to help out and most likely minimal explicit documentation. You will never be able to hire talent that…

i've seen a shop start as a "no-framework" effort and it did indeed become an "internal framework" project. imo it was a strange choice, given how much effort had to go into maintaining and bugfixing the internal framework...mostly issues that would have been flushed out in something with wider support.

before being involved in mostly "modern saas", i was heavy in electrical/electronics mfg and there was always a tension between "not-invented-here" and "borrow-buy-build" camps. NIH would stress that all components in our designs should be in-house (electrical metering, data acquisition, etc) while the BBB camp would turn every effort into a 3rd party integrations exercise. at times this even applied to the factory floor. i seriously know a person who was like "hrm, lets build our own pick-and-place for the smt line..."

Re: Things I wish I knew about state management when I started writing React apps

#112

Post by bdcravens »

nepeckman wrote: post #85
the_gastropod wrote: post #60

Earlier quoted context omitted.

I actually write a good bit of React professionally. I'm familiar. I just have yet to see a very compelling case. And the excuse is almost always this nebulous "rich/complex interaction". And.... I just rarely see any good examples of this. The huge majority of apps (web or otherwise) are not video games. They're forms that submit stuff to a server and get a response. There's sometimes a dropdown here or there.... an…

I see this sentiment on hacker news a lot, and I honestly dont get it. A list of functionality I've implemented that requires (or is made easier by) JavaScript: Client side validation, error messages, autocomplete, dynamically picking/removing/auto filling fields based on user input, forms that need to know user answers to previous forms, smart tables, update of data pushed from server, sharing markup/functionality b…

The issue seems with moving responsibilities that the server handles really well to the client (namely, state and session management). I think it's less a matter of Javascript-framework vs no framework, and more a matter of SPA vs. non-SPA

Re: Things I wish I knew about state management when I started writing React apps

#113

Post by kingdomcome50 »

karatestomp wrote: post #25
nubb wrote: post #3

I’ve been learning React and have been avoiding Redux out of fear of complexity. However, as my app grows more complex, the need for a global state manager becomes more apparent. Time to start learning Redux today :)

1) Redux is pretty simple, but some of the terminology is obtuse for no good reason and makes it harder to get a grip on than it should be. "Action" = event, "Action Creator" = any function that emits an event, it's basically... not even a real thing worth discussing with its own special term. There, problem mostly solved. 2) TypeScript is the only sane way to use it. The bouncing between files and "wait, what was th…

Nailed it. Not only do I share the same sentiments, I have also had a very similar experience with 3.

Specifically, I like to be able to interact/test with my application as I build it in the console. I have had much success with wrapping my "Action Creators" in a API of sorts and mounting it to the `window`. This saves me from having to either create some sort of one-off component to "get at" some piece of functionality or hand-rolling actions in redux dev tools.

Re: Things I wish I knew about state management when I started writing React apps

#114

Post by bernawil »

zelly wrote: post #80
vga805 wrote: post #8

What's the deal with the recommendation to use some library for managing forms? I've been working with React almost since its initial release and I've built some pretty complex forms... yet form libraries remain the one thing I've never really seen a need for. At the very least, using something like formik shouldn't be a necessity. There should be some qualifier that it's only really needed for very complex forms. Or…

Don't overthink it. Native HTML5 elements come with form validation and even a way to serialize (!) and submit form data w/ action and method attributes. (To implement the same as React components would be a 3 month project coming with a 1 GiB node_modules dir.) The only time you have to add JS bloat is for date pickers and time pickers which aren't supported on Safari yet (and you can user agent sniff for this). Blo…

People need way more validations than html5 elements can provide. They need CC number validation. Validations that depend on the content of sibling elements. And they need it to display in custom ways like internationalized or whatever.

Re: Things I wish I knew about state management when I started writing React apps

#115

Post by brlewis »

brlewis wrote: post #17

Point 1 in this article is totally misguided. "State management is how you mitigate prop drilling" implies that when prop drilling is not a problem (i.e. most of the time), that you don't need to think about state management. Even if you're prop drilling, you need to make sure data is not stored/updated in multiple places in your app in order to keep the UI consistent. The one redeeming part of that section of this a…

In fact, the linked article is useful because it links to a much better article on state management with React: https://kentcdodds.com/blog/application-state-management-wit...

Re: Things I wish I knew about state management when I started writing React apps

#116

Post by WilliamEdward »

some-guy wrote: post #61
the_gastropod wrote: post #41

I'm one of those "old dogs" who don't quite get the advantage of using React in the majority of the cases it's used. This article didn't really help... > What makes these frontends complex? State management. The frontend “knows” a lot of things, and these things interact with each other in non-trivial ways [...] Example: dark mode support. For example, say your app has a dark mode. All your rendered components must k…

For individuals making small sites, it's absolutely overkill. For my job, with hundreds of developers working on a giant SPA blob with constant feature creep, frameworks like React are a necessary evil to maintain the insanity.

At what point does it stop being a small site and become a giant app? Genuinely curious cus im wondering if i should make the switch.

Re: Things I wish I knew about state management when I started writing React apps

#117

Post by mpfundstein »

pier25 wrote: post #108

> You can make API calls in your actions just like you normally would Jesus don't do this. Mobx, Vuex, Redux, etc, are about managing application state not about managing application logic. I started making SPAs in 2015 and I also used actions for everything (API calls, auth, etc). It was fine for small projects but then I got to work on a medium sized project and those actions became huge and controlled everything i…

What about redux-thunk? I usually put all me data fetching logic in thunjs and dispatch to regular actions if needed.

Re: Things I wish I knew about state management when I started writing React apps

#118

Post by switch007 »

some-guy wrote: post #61
the_gastropod wrote: post #41

I'm one of those "old dogs" who don't quite get the advantage of using React in the majority of the cases it's used. This article didn't really help... > What makes these frontends complex? State management. The frontend “knows” a lot of things, and these things interact with each other in non-trivial ways [...] Example: dark mode support. For example, say your app has a dark mode. All your rendered components must k…

For individuals making small sites, it's absolutely overkill. For my job, with hundreds of developers working on a giant SPA blob with constant feature creep, frameworks like React are a necessary evil to maintain the insanity.

React is just a library though. Surely there is much more to your story than React alone?

Re: Things I wish I knew about state management when I started writing React apps

#119

Post by nawitus »

pier25 wrote: post #108

> You can make API calls in your actions just like you normally would Jesus don't do this. Mobx, Vuex, Redux, etc, are about managing application state not about managing application logic. I started making SPAs in 2015 and I also used actions for everything (API calls, auth, etc). It was fine for small projects but then I got to work on a medium sized project and those actions became huge and controlled everything i…

What does "do in action" mean? If you mean "make API call in reducer", that is commonly known to be an anti-pattern. Triggering the API call by dispatching action, however, is a common pattern. Usually it's implemented with a library like redux-saga or redux-observable.

Re: Things I wish I knew about state management when I started writing React apps

#120

Post by pests »

bernawil wrote: post #102
the_gastropod wrote: post #60

Earlier quoted context omitted.

I actually write a good bit of React professionally. I'm familiar. I just have yet to see a very compelling case. And the excuse is almost always this nebulous "rich/complex interaction". And.... I just rarely see any good examples of this. The huge majority of apps (web or otherwise) are not video games. They're forms that submit stuff to a server and get a response. There's sometimes a dropdown here or there.... an…

They're forms that submit stuff to a server and get a response What kind of response? Asuming no React, a. json b. SSR-html? If, a. Now you've got to process that response, handle errors and finally render into html. You'll be either imperatively replacing DOM nodes, interpolating string templates or both. Probably re-binding event handlers after that. b. You'll be merging your server-rendered html to your current vi…

You forget the most basic response. A full HTML file with a corresponding reload. None of what you said applies. I'm a big react fan and advocate too but sometimes I think we forget about the basics.
Post reply on HN