<story><title>Persisting React State in LocalStorage</title><url>https://www.joshwcomeau.com/react/persisting-react-state-in-localstorage</url></story><parent_chain></parent_chain><comment><author>geocar</author><text>I&amp;#x27;d recommend just putting this crap in the URL. That way (a) the server could see it too, and (b) users could share their state by sharing the URL (which makes supporting them easier!). If you&amp;#x27;ve got so much state this doesn&amp;#x27;t make sense, then ¯\_(ツ)_&amp;#x2F;¯ I suppose caching it in localStorage is fine, but I haven&amp;#x27;t yet run into this problem.&lt;p&gt;Having a setSticky((k,v) =&amp;gt; that modifies the url with the history API is pretty easy, and if you get the results using the Context API, you can have your root monitor the URL (again using the history API) and publish the result using a context so you don&amp;#x27;t have a storm of updates.</text></comment>
<story><title>Persisting React State in LocalStorage</title><url>https://www.joshwcomeau.com/react/persisting-react-state-in-localstorage</url></story><parent_chain></parent_chain><comment><author>dudus</author><text>I remember people were abandoning localstorage a while ago because of some fundamental problem I can&amp;#x27;t quite remember right now. Not sure if it was difficulty in keeping in sync which the author mentions or the fact that it can&amp;#x27;t be scoped in a way to share among subdomains. I&amp;#x27;m sure someone here will have a better memory than me.&lt;p&gt;Edit: after some basic research among other complaints are: bad performance, synchronous, bad security model, only strings, limited to 5mb, no access to web workers.&lt;p&gt;Localstorage has its uses but shouldn&amp;#x27;t be abused to store everything in it.</text></comment>