4 ms·
Absolutely great article. One thing I always see missing is why front-end applications can't use sessionStorage or localStorage? Why is this generally frowned u
by memonkey 4y ago
Absolutely great article. One thing I always see missing is why front-end applications can't use sessionStorage or localStorage? Why is this generally frowned upon?
- wizofaus 4y agoI'd assume because it's often abused? There are perfectly legitimate reasons to use either and I've been technical lead on React projects where the decision was made to use them. In at least one case it was a known "shortcut" as we didn't have time to properly develop server-side persistence and local storage was "good enough" for 95% of use cases. And session storage is needed to allow page refreshes without cookies.
- bayesian_horse 4y agoFor what purpose? If you use it as state management inside the SPA, it's actually slower than all the other approaches.
- frosted-flakes 4y agoMost apps actually do use localStorage as a persist layer. But it's not a replacement for state libraries because it's just a place to store strings, and that's it. A state management library is so much more than a scratchpad.
- wildrhythms 4y agoWhat these state management solutions usually attempt to address is reactivity. When the <UserLoginModal /> finishes its login process and sends a bunch of data about the newly logged-in user to the global store, I'd like for some N other components in the tree to consume that new information. State management solutions help relay that new information down the tree to the components that need it. Local storage and session storage can persist data, but have no way of informing components that something has changed without implementing a setState() and listener/callback system, at which point you've recreated yet another state management system.
- proxyon 4y agoThe same reason we read from RAM / CPU cache and not from the hard drive