171–180 of 335 posts
Bounced around 2 projects in the last 12 months, one Angular and one React, that are using the Flux pattern. It is a real bitch to unit test anything but the individual pieces, which ends up being kind of meaningless.
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…
Hey - author here. I did not mean to imply that state management is only useful to mitigate the prop drilling problem. In fact, in #2, I give another example where state management is useful.
I couldn't make sense of the second section either. It sounds like it's recommending a global store as the solution to updating a single component. The correct state management for a single component is what comes with React.
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'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…
You can try this, but I don't think it'll turn out well!
You don't want to have a bloated, disorganized global store...what you're doing now, moving state into global state only if needed, is the right way to go.
Earlier quoted context omitted.
For reference, here is a "simple" app - a parametric EQ designer that supports doing pink noise measurements of speakers (or headphones if you have the right equipment) with FFT in the browser: https://eq.spion.dev/ - works as an entirely static website :) Typically what people say is "oh most websites won't need THAT" but the appetite for interactivity only grows with most companies, so you could easily end up in a…
What definition of static website are you using here? If I turn of JavaScript all i get is "You need to enable JavaScript to run this app."
I think the largest myth that exists in the react world is the need to have a global state for everything. I've seen too many failures when teams go from displaying "this one thing" to suddenly have the requirements to display two or more of that at the same time. Redux global state for the user that is logged in? that's OK, but do you really need Redux for that? Our team uses hooks and context for everything, and a…
You don't need to put the username of the logged in user into Redux, but if multiple components across different pages need to access this data, you should make it globally accessible.
You can choose Redux/MobX for this, or you can roll your own solution with context and hooks.
I'm actually learning more about the context/hooks approach myself.
Kent C Dodd wrote a great article on this topic I'd recommend:
https://kentcdodds.com/blog/application-state-management-wit...
I don't even use any of these state libraries. All logic in the page/screen components and the prop-drill them down to where they are displayed.
I see the appeal of the simplicity of this approach, and this is how I handled state in my application before I knew what state management was.
But how do you deal with the problem of many of the components in your tree needing to know what theme is set?
Earlier quoted context omitted.
Mmm, I work on a multimedia sequencer (timeline, viewport, etc) in the browser, it would be utter hell if the whole thing was put together via manual DOM updates in something like a Backbone View render function. I know this because when I joined the company, they were trying to do it in Backbone. For a project of that scope, this was a great way to introduce a large surface for error and maintenance (the project kic…
> when React was launching and Typescript wasn't public Minor correction, React came out about 7 months after Typescript. That said, Typescript had a promising birth but a rough infancy, so I wouldn't blame anyone for considering it released only after 1.x versions starting in late 2014.
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…
I do not like Redux a lot. It leads to a lot of boilerplate code and a lot of extra files. It also exposes transparently the state that lead by default to a coupling between the "internal" data rappresentation and the rest of the UI components making refactoring a nightmare. Mobx at least leads to a more concise codebase. GraphQL and Relay/Apollo/etc help a lot to reduce the business logic in the front and code to wr…
- Our new Redux Toolkit package (https://redux-toolkit.js.org) simplifies most common Redux use cases,
- Our new Style Guide docs page recommends patterns that result in simpler code, such as using the "ducks" pattern for single-file logic ( https://redux.js.org/style-guide/style-guide#structure-files... )
- And we're working on a docs rewrite that will update the tutorials to show simpler approaches as well
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…
To me there’s nothing wrong with React, but everything wrong with people using it in inappropriate contexts. For instance, I’ve seen a growing trend of people creating a whole DOM using React JSX so that they can use React’s server side rendering pipeline. tag all the way down. But the actual reactive components make up about 30% of the page. So you’re wasting download and JS processing time (a serious concern on low…