Here’s the video of me presenting on NgRx: state management for Angular. https://youtu.be/qSpf0WiT1d4.
We made some mistakes in filming this so the slides can’t be properly seen on the video. Fortunately you can see the slides at this link:
Here’s the video of me presenting on NgRx: state management for Angular. https://youtu.be/qSpf0WiT1d4.
Published
John Hardy Developer 
It seems that reducers are basically State monads. The type of a State monad is
type State st a = st -> (a, st)
that is it takes the old state, and returns a new state and an arbitrary bindable value a. You can represent the “action” of the reducer as the Reader monad type.
type Reader action a = action -> a
So you could define a reducer as:
type Reducer action st a = Reader action (State st a)
= action -> st -> (a, st)
The only reason why Reducers are not monads is that they don’t return an arbitrary bindable type “a”.
LikeLike
Is this an approach that someone might use to manage an application written in Haskell? The main idea is that state is centralised and various parts of the view register interest in changes to it. I believe there’s a rough correspondence to the way Elm does things with regard to application state.
For me I think too much is made of reducers etc they are just the updating mechanism. All the real business logic of the application is in the effects area (middleware) which is where actions are listened to and which new actions may be emitted (usually asynchronously).
LikeLike
John Hardy So, the reducers are just what the Angular programmers see, and the kind of events that are available to the for defining reducers are defined in the middleware?
Yes indeed, my own Haskell GUI library works almost exactly like this. If I am to understand what “middleware” is, this is what I am calling a “back-end provider.” Currently I only have a Gtk+ back-end, which does the work of multi-threading, listening for X11 events, and dispatching threads to react to these events.
The central data type in my GUI library (called “Happlets”) is the GUI monad:
github.com – happlets
An end user would simply use my “GUI” monad as easily as they would use the “IO” monad in any ordinary Haskell program. You start by evaluating the initial “GUI” function in “main” function using a “back-end” provider (currently only Gtk+ is available). In your initializing GUI function you create a window which provides you with a canvas, and then you install event handlers.
I then created type classes which provide a consistent interface to the event-handling functionality provided by the whatever back-end providers can provide. For example, a keyboard event:
https://github.com/RaminHAL9001/happlets/blob/master/src/Happlets/GUI.hs#L416
The “keyboardEvents” function installs a reactive callback function that takes the Keyboard event as an input and evaluates a GUI function which transforms the state. So your keyboard event handler may be as simple as composing a function to extract information from the event with a function that alters the state:
(insertIntoTextBuffer . keyChar)
So it is pretty much exactly like how the Angular NgRx model works. I didn’t even know about NgRx or any of the JavaScript reactive frameworks, it is just that this design methodology is the best way to do things in multiple domains.
You can stop reading here, but…
Under the hood, I created a very abstract “GUI” monad which stacks together a Reader, a State, a Continuation, and the IO monad, so the GUI monad will have the properties of all four of those monad transformers combined.
The reader carries a MVar (mutex) with the modifyable state type “model”, and then I instantiate the “MonadState” type class so that end users can use state tranforming semantics (namely the “get” and “put” functions) on the content of the MVar transparently.
The continuation exists so that a GUI can be halted and a new, totally different monad can be spliced into the event handling control flow. This endows the GUI monad with the ability to do context switching, for example to switch to another document “model” when a certain event occurs.
When an event occurs, the GUI function unlocks the MVar carried by the Reader and stores a copy of it into the State monad, along with a reference to the window and some control flow information. I instantiated the “MonadState” type class such that end users using “get” and “put” only see the document “model” held inside of the mutex. If you want to transform the internal GUI state, you use “GUI get” and “GUI . put” instead, but this is never necessary for end users.
Finally, when the event handler gets to the final “return” statement, the updated document “model” is stored back into the mutex. Only one event handler is allowed access to the mutex at a time.
LikeLike
Ramin Honary I won’t pretend I understand much of that but I do understand your intention and I think ultimately it’s the way to go in this stuff. Most developers I know are no where near even this realisation, so I don’t feel too bad. I just need to do a lot more study than I’ve had time for lately.
LikeLike