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

161–170 of 335 posts

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

#161

Post by williamdclt »

davnicwil wrote: post #73
Waterluvian wrote: post #28

I'm starting to lean towards holding ALL app state in a single store rather than having component local state because every so often I get burned by not seeing the future. Example: okay I have a bunch of tabs that show different views. The state for which tab is selected can live with the tab container. Months later I find that I need other parts of the app to be able to switch to a different tab when user actions ha…

If you're looking to retrofit something like this in, just for a simple piece of state like which tab is active, and don't want to refactor all your existing local state management code, Context is a really powerful tool for this. I think of it like a dedicated state 'portal' - should I need to use one particular piece of local state in other components, I just write a quick dedicated Context for that one piece of da…

Agreed, I use Context as a "store for UI stuff" and it always fitted perfectly. Keep data in the global store (Redux or whatever), component-specific state in the local state and inter-component state in Context.

And I wrap almost everything in hooks anyway, so the component doesn't care if it's local, Context or Redux: it's just data and I'm free to move it in different stores.

Tabs are typically the sort of thing that makes me think "context" immediately. Also implemented nested collapsable sections with this, TikTok-like feed where different components control the same UI component (sliding panel), tables...

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

#162

Post by GrumpyNl »

jfengel wrote: post #47
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…

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 disagree with making it easier. Php, jquery and css will bring you a long way. react is far more complex.

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

#163

Post by draw_down »

john-radio wrote: post #77

Help me out here. So state management refers to frontend tools like Redux and Vuex, and it sort of represents the "backend of the frontend" in that it defines constructs and their behaviors for the frontend to manipulate. Is that a correct understanding? If so then doesn't it result in some bad code duplication between e.g. the Redux layer and the Django models?

I think it's best to either have some sort of codegen that creates the frontend types from the server-side types, or work in the same language so they can be shared. You're right that that sort of duplication is a risk, it should be addressed with tooling (or, again, doing everything in JS). As with everything else, there should be a single source of truth.

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

#164

Post by veeralpatel979 »

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…

> form libraries remain the one thing I've never really seen a need for

I felt this way too, until I used Ant Design's form component (which uses rc-form under the hood).

Form libraries take care of validation for you, allow you to specify an initialValues prop, and give you a handleFinish={values => ...} prop so it's easy to run your own API call when the user clicks "Submit".

Plus, Formik lets you model the form values using a TypeScript interface which I like.

To me, Formik provides several advantages over not using a form library, and no disadvantages except a small learning curve, so that's why I recommend it.

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

#165

Post by kreetx »

acdha wrote: post #144
bernawil wrote: post #122

Earlier quoted context omitted.

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…

I agree with this.

Yes, ideally, a SPA could be better (i.e why re-send the parts of the app that didn't need to change), but most of these apps are actually way slower -- either because the developers don't know/care beteer, or perhaps more probably, are not given the time to implement the perfect(-ish) solution.

A full html page reload isn't much slower than react/redux doing a json fetch, but it may appear so since most of the content doesn't flash, new content comes in with an effect etc. And I agree, this looks more slick.

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

#166

Post by veeralpatel979 »

qwerty456127 wrote: post #21

> Think about the most complex frontends you’ve used. Frontends that made you wonder — “how did they create this”? 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. So in my view, state management is the core problem when developing a UI. To build a non-trivial React application, you need to consider state managem…

Author here. The way I think about it is, the web was designed for rendering static markup. JavaScript was designed for adding small amounts of interactivity.

Instead, we've managed to turn the web into a full-blown application platform. Do you think Tim Berners-Lee envisioned something like Google Maps being created in the browser?

Now, I concede that JavaScript isn't the best language for creating client-side apps. I hope someone applies some first-principle thinking and creates a language expressly designed for this purpose.

Considering how many people and developers use web apps, this could be an area where someone can have a massive impact.

I wonder if WebAssembly is the solution here?

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

#167

Post by williamdclt »

john-radio wrote: post #77

Help me out here. So state management refers to frontend tools like Redux and Vuex, and it sort of represents the "backend of the frontend" in that it defines constructs and their behaviors for the frontend to manipulate. Is that a correct understanding? If so then doesn't it result in some bad code duplication between e.g. the Redux layer and the Django models?

That's pretty much it. The Redux store is a database (up to you to keep it normalized), things like selectors and actions are akeen to controllers (one just reads data, the other just writes).

You do have some "concept duplication", more than code duplication. Indeed you'll have to define your interfaces twice (Django models and Typescript definitions for example), but that's always the case if you consume an API (you always hope that what you expect from an API is what is received).

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

#168

Post by reilly3000 »

I haven't seen much mention of Apollo here. It offers a 'full stack' state management solution from server to client to offline cache. Each component can be adopted independently, but they work really nicely together. The tradeoff is that you're writing graphql, but it comes along with a lot of benefits, like consolidating requests etc. On the server-side, graphql can be a thin wrapper over rest apis. Defining good schemas can be a bit of a pain, but they maintain a level of consistency throughout the system as it grows.

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

#169

Post by chrisco255 »

john-radio wrote: post #77

Help me out here. So state management refers to frontend tools like Redux and Vuex, and it sort of represents the "backend of the frontend" in that it defines constructs and their behaviors for the frontend to manipulate. Is that a correct understanding? If so then doesn't it result in some bad code duplication between e.g. the Redux layer and the Django models?

Not sure what you mean by "bad code duplication"? If you have a need for a rich front end application you're going to need to implement some state management on the front end. The back end is responsible for running APIs, managing services, interacting with the database, and performing validation on API calls. A good REST API is typically stateless. But a front end can't be stateless. Let's take Facebook for example. The front end needs to track which conversations are open, which users in your friend list are "active" or "away" and render the appropriate icon, threads of conversations need to be woven together on various panes on the screen, visual feedback about whether a post has already been "liked" by the current user needs to be provided, etc. It needs to be able to receive real-time updates and post those to the UI in the proper location. There's a ton of complexity there and you have to place that state in memory on the client somewhere. Managing front end state effectively is crucial for complex applications.

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

#170

Post by veeralpatel979 »

bcrosby95 wrote: post #63
breytex wrote: post #26

Earlier quoted context omitted.

You got that wrong. Modern JavaScript / SPAs make it possible to implement something like Outlook right within your browser. No (big) download, no clicking through an installation wizard, no fragmentation of versions for a tool, which forces you to be online anyway. I don't get all the hate towards SPAs and JavaScript Frameworks here on HN. Everyone is basically complaining about complexity for applications, which ar…

I find lots of these "requirements" come from developers that are bored with their job and need to spice things up.

Maybe! But also, as a user, I expect to do more and more in my browser.

I would find it strange, and probably switch to a competitor, if my preferred airline for example made me install (and keep updated) a desktop app in order to book a flight.

Post reply on HN