This is also widely known as WTF-16 (seriously, look it up!)
If the issue is one of jurisdiction, did they file the case in the wrong court?
Following local news, I've seen the case where a case is closed because it was filed in the wrong court. A different court had jurisdiction in the matter. I wonder if that's what happened in this case.
They also denied that she’s part of some well defined class for a class action. It’s not like they are saying there’s some other court she can go to.
US courts are generally infamous for denying justice whenever they see fit using technicalities like “standing” and other procedural grounds.
Environmental law violations, illegal surveillance programs, civil asset forfeiture like here, and constitutional violations are quite often practically impossible to get courts to address, especially if parts of the US government are the defendant.
React could be argued to have abandoned the fight for being the best client side framework technically (though they have dominance pragmatically). They are really all focused on Vercel’s Nextjs/SSR/SSG/RSC stuff in recent years
There's nothing stopping people from using these atom-based libraries to build more robust abstractions, but from my professional experience I tend to just see global getters and setters with useEffects / lifecycle method of your frameworks choice as a side effect sync.
Maybe my instincts are off here though and I am overly cautious. I love XState but the learning curve is rather massive and getting buy in from other team members is hard when the DX of the atom approach is so nice.
I feel like state "management" and reactivity performance are talked about a lot, when ultimately state orchestration is where I see things fall over the most.
I’ve seen far larger messes created in redux due to tight coupling of things across large apps to a global store and the inability to work with things like Maps and Sets or other values that are not trivially JSON serializable.
In the other direction I have seen messes with observable-based state management systems where things become far more complex and too far abstracted (how often do you really care about anything other than the latest value and maybe the previous one?) or with proxy based systems that have too much fragile magic (valtio, mobx) or require wrapping your components and going all in on oop (mobx)
To me signals hit the magic spot of reactive without being overkill and keep code testable in smaller units while retaining performance benefits of surgical updates
I like xstate in theory — it’s a good way to think about complex state transitions — but in at least half of cases in practice where you aren’t interested in a derived value, someone is storing a value/ getting the latest value or toggling a boolean and it’s just such overkill for that. The reducer pattern itself doesn’t meaningfully show up much for similar reasons. The other common cases are with fetching states (idle, loading, refetching, success, error) but you often end up wanting things like cache management or maybe even optimistic updates so eventually tanstack query covers that ground better than rolling your own.
Jotai, mentioned briefly in the article, may not be built in but is as intuitive as signals get and isn’t even tied to React as of later versions.
I’ve very rarely met a state management problem in clientside state management where neither tanstack query (for io related state) nor jotai (for everything else) are the best answer technically speaking. The rare exceptions are usually best served by xstate if you want to model things with FSMs or with zustand if you actually need a reducer pattern. There’s a tiny niche where redux makes sense (you want to log all state transitions or use rewind or are heavily leaning on its devtools) but it was the first to get popular and retains relevance due to the fact that everyone has used it.
You can go a long way with useContext and useReducer/useState but few would opt for alternatives if jotai came batteries included with react.
The most disturbing thing about it is the way advice to forget about science and optimize for the process is mixed with standard tips for good communication. It shows that the community is so far gone that they don't see the difference.
If anyone needs a point of reference, just look at an algorithms and data structures journal to see what life is like with a typical rather than extreme level of problems.
https://github.com/tc39/proposal-pipeline-operator
It would make it possible to have far more code written in the way you’d want to write it