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.
Wow, you really think British fascism was a serious political threat after six years of war against various fascist powers. That’s a truly McCarthyesque level of paranoia.
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.
> 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.
> React allows you to treat DOM mutation as an expression of current app state.
Current app state. As in not past state. Not future state. There would be no need for the distinction if the state wasn't mutated.
> 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).
You are confusing the mutability of a data structure with the mutability of state. You can model mutable state using immutable data structures, but it's mutable state regardless. In fact, that is exactly what the Redux/ImmutableJS model is. If the state of your "immutable" react app were really immutable, you would have a webpage, not an app.
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.
That is mutable state. Your Redux store is a mutable state container. If your redux store returns a {a:1,b:2}, and then you dispatch an action and it now returns an {a:2,b:1}, then you have mutated your state. It doesn't matter at all if the store's data structures are mutated in place or replaced with a modified immutable updated copy of a previous state, you still have mutable state.
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.
Also, "finite state machine" has a very specific meaning, and that isn't just any machine that has a finite bunch of variables that you call state.
If React lets you execute arbitrary JavaScript code (which it does), then you're no longer using just a finite state machine, you're using a Turing machine, which is something different, and more powerful. It may have many finite state machines embedded in it, but to refer to a user interface as a finite state machine is like referring to a car as a pulley, just because the engine requires several pulleys to work, and ignoring all the rest of the engine and car. You can't make a car out of just pulleys, and you can't make a user interface out of just finite state machines.
React, as it is presented to the programmer and for all practical reasoning, is programming with finite state machines. Sure, javascript is Turing complete and capable of much more (behind the scenes in React there is plenty going on that does not qualify as FSMs), and within a react application or even a component you might use Turing complete semantics to describe actions, data structures, effects, or whatever...but constrained to the API and idioms of react it is perfectly acceptable to call it FSM programming. In fact, Facebook already says this about react, that UIs are state machines and react is a way to declaratively describe them that way.
A better analogy for the equivalence of Finite State Machines and User Interfaces is the equivalence of human arms and levers. Just because it is one doesn't mean it isn't the other. One is abstract and the other is concrete, but there is still an equivalence. And not just computer user interfaces either...you could take pretty much any real world user interface: analog, mechanical, digital, whatever. Hell, tubas and vending machines are finite state machines. They fit the definition of a finite state machine because they are.
