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

141–150 of 335 posts

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

#141

Post by mands »

bdcravens wrote: post #112
nepeckman wrote: post #85

Earlier quoted context omitted.

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

This hits the nail on the head - it's about SPA vs MPA. Component-based architectures are a proven and a win on FE for more complex interactions, but that doesn't necessitate an SPA. We had a large SPA with a REST API backend and were finding it really difficult to add more features to the FE due to the inherent complexity of the SPA.

We decided to split it into an MPA, adding React components to server-side rendered pages as needed (along with intercooler and stimulus when we don't need the power of React).

Things have become much simpler and quicker to develop, allowing us to focus on the user features instead. It's easy to forget how much you get for free from the browser and traditional HTTP/HTML client-server mechanics, along with the ease of having full access to your database and data model in your templates - and makes you wonder if going with an SPA first is throwing the baby out with the bathwater.

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

#142

Post by shadowgovt »

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 the specific example the article gives, you probably should implement it by having a top-level component change one of its class identifiers and having the CSS properly select light mode / dark mode all the way down the chain.

... but the purpose of state is to keep track of whether you're in light mode or dark mode. You don't want the arbiter of that knowledge to live on the DOM if you're doing a web app, because you need to reason about who is allowed to change between light and dark mode and the DOM is global state; anything in your app could be editing it. State (among its other uses) serves as a gatekeeper on the ground truth of what mode you're in (and if all changes to presence / absence of the class in question pass through that component state, you're good to go).

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

#143

Post by karatestomp »

kingdomcome50 wrote: post #113
karatestomp wrote: post #25

Earlier quoted context omitted.

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 functiona…

I've done similar things, and yeah, it's great for making quick-n-dirty utilities to poke around with your data & state handling code. You can even throw ugly non-React GUIs on top, trivially, including in something like Electron (if, say, your application needs access to functionality or modules not available on the Web, as could be the case for certain Javascript deployment targets like mobile, set-top boxes, desktop, server, and so on).

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

#144

Post by acdha »

bernawil wrote: post #122
pests wrote: post #120

Earlier quoted context omitted.

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.

First time I hear XMLHttpRequest was a mistake. No one is going to sit through a full-page reload on every form validation. Even intermediate solutions that merged (hacked) client-server state failed too. APIs are just better.

> No one is going to sit through a full-page reload on every form validation.

Why not? Most of the pure HTML forms I use load at least an order of magnitude faster than the complex SPAs I use because there's so many fewer network requests. You can make SPAs which are as fast but I'd say fewer than a third companies, even very large ones like Google or Facebook, succeed at doing so and an even smaller percentage have thought hard enough about error handling. On a daily basic I use sites from Google, Twitter, Facebook, etc. where I have to do a reload anyway because their developers were unaware that network operations require timeouts, retries, and that you need to provide UI feedback for all of those to match what the browser provides by default.

EDIT: to be clear, I like that we can do a ton of very complicated things in a browser now — we've been working towards that as an industry for the last 3 decades and it's great that it's largely arrived — but I think it really hits the failure of companies to skimp on resources for anything which isn't critical to the default user experience. Duplicating built-in functionality should be seen as an expensive commitment, not the default unless you're willing to devote the extra resources needed.

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

#145

Post by shadowgovt »

lhorie wrote: post #128
jfengel wrote: post #47

Earlier quoted context omitted.

React and Redux are for apps. If you can do it with HTML/CSS, you absolutely should. React/Redux are a replacement for what people used to do with jquery or plain JS. They're not for display; they're for complex interaction of the kind that used to require a native user interface (Java Swing, Gtk, Win32, etc). Javascript is a mess, and the DOM is a mess; React makes that slightly less awful. (Redux is an extension to…

I think what GP was getting at is that there's a healthy amount of "if all you have is a hammer" mentality going on w/ React/Redux. The tragedy of commons here is that you _could_ conceivably just slap a class at the root of your React tree to implement dark mode, but if one is using something like styled-components, there's a good chance that the library will get in the way of the style cascading semantics that come…

I don't see why using libraries for complicated interactions atop React is a bad thing.

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

#146

Post by acemarke »

SlowRobotAhead wrote: post #138
acemarke wrote: post #97

Earlier quoted context omitted.

I'm a Redux maintainer. There's a bunch of reasons why Redux took off: - In 2014, a year after introducing React, Facebook announced the "Flux Architecture" concept [0]. Since it was mostly just a pattern and not a library, over the next year the community created dozens of competing Flux-style libraries, which I've referred to as "The Flux Wars" [1]. - Redux came out in the middle of 2015. Its design took inspiratio…

Can you comment on why people who like Redux on React don’t use it much when moving over to Flutter? I’ve heard “yea, you can use Redux, but don’t” a lot.

Sorry, I have no experience with Flutter or knowledge of how Redux is being used with it, other than having seen one or two random comments where the two names appeared together.

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

#147

Post by ChrisCinelli »

For state management I would start with reading "Thinking in React": https://reactjs.org/docs/thinking-in-react.html

Step 3 is key. Step 4 is also important.

Then try to simplify the app as much as you can. A system has always 2 kind of complexity: the intrinsic complexity and incidental complexity. "Smart engineers" like to show off their intelligence. That usually end up making their life harder by adding a lot of incidental complexity that eventually lead to fragile architecture and frameworks that add more complexity than necessary.

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

#148

Post by the_gastropod »

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…

> Client side validation

The server still needs to validate, no? I've never seen a form that really benefitted from client-side validation. As long as required fields are clearly marked, I don't really understand the value here.

> error messages

Hmm? What about them needs React?

> update of data pushed from server

You can poll very cheaply. And even Websockets are pretty simple. Check out Phoenix LiveView or Rails Action Cable for decent examples of trivial solutions to this.

> sharing markup/functionality between pages

Even Apache server-side includes let you do this. We're not talking about hand-rolling plain HTML files in MS notepad (or even going wholly js-free). We're talking about React being overkill in a lot of places.

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

#149

Post by fold_left »

adamkl wrote: post #31

To manage state in our React application, we have a "service layer", just like you’d see in a server side application, only these are based on state machines (reactive services based on RxJS observables works as well). We also created associated custom hooks that allow developers to easily "inject" a service into their React component (we use React's Context API for our "DI container"). From there developers can read…

I love the sound of this, do you have a link to any examples?

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

#150

Post by nohuhu »

hashamali wrote: post #124
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…

I think this is generally a side effect of people considering actions to be a replacement for the Controller part of MVC. Meaning any sort of logic (including legitimate state manipulation) is jammed into actions. Personally, I don't see that as a huge problem. Better in an action than sprinkled into components. As someone else mentioned, redux-thunk makes this even easier (and one could argue, promotes this).

Another way of doing controller stuff is by actually using a Controller: https://github.com/riptano/statium#viewcontroller. Example: https://github.com/nohuhu/react-statium-realworld-example-ap...

Logic flow doesn't have to be hard to do.

Post reply on HN