Immediately after WW2 all fascists worldwide disappeared in a poof of smoke. Also their rise to power has always been abrupt and without warning via an on/off switch.
Another +1 here. Intense visceral disgust of lavender. I don't think I'm "smell-sensitive" in any other way. I can tolerate all manner of, e.g., dank cheese, pungent fish, fragrant smoke, any other plant oil, etc. I just can't stand lavender.
ClojureScript with re-frame is fantastic. I also use it on a production app with an Elixir backend, it's a great fit. Be sure to check out re-frisk and re-frame-10x.
I think I see where you're coming from, but I also think you might be moving the target a bit. I suspect you'd garner less debate if you said, I dunno, just "a dynamic UI app needs a way to model state changes". "Mutate" has a specific meaning, in my mind at least, when discussing variables and data structures. React enables avoidance of direct DOM manipulation, Redux obviates direct state mutation.
The DOM can be mutated just fine behind the scenes by React to reflect whatever brand new state has been passed into it. That brand new state can be anything. It can be a single (by definition immutable) integer. It can be a deep clone of an object. This is the ideal intended Redux architecture. Redux reducer(s) receive the state and return either the state untouched, or a non-mutated copy of the state. React reacts accordingly by expressing this brand new state as (possible) DOM mutations.
> If you haven't mutated states, you don't have an interactive UI.
React allows you to treat DOM mutation as an expression of current app state.
This doesn't mean that your state itself has to mutate. It's entirely possible to structure a React (and/or Redux) app with fully immutable state, copies of which represent change. (Whether copies are done efficiently, e.g. via persistent data structure algorithms, or naively, e.g. via a deep clone, is secondary).
I'm befuddled where you're getting the impression that immutable data structures themselves require mutation.
Sure. My reasoning: The localStorage token helps protect against CSRF, e.g., this token will not be submitted via a form embedded on another site (cookie will), therefore request will not be authenticated. In an XSS attack (aka "we're screwed"), the secure, HTTPOnly cookie at least adds an additional level of complexity above simply reading a single plaintext localStorage item. Perhaps this is naive? Of course I also take every precaution to prevent XSS from happening at all. Relevant[1].
For single-page apps I use two session tokens. One in localStorage (csrf_token), one in a secure, HttpOnly cookie (auth_token). Both tokens are required for the API to authenticate a request.
My fiance and I moved from the Bay Area to Asheville, North Carolina last year and could not be happier. The only checkmark missing is decent transportation outside of cars.