3 ms·

Can you give an example of what you mean by side effects as data?

by dmn322 4y ago

dgb23 4y ago
You describe an effect as a data structure which gets interpreted and applied by the appropriate driver (for the lack of a better term). Think of how we do it on the wire: we send a description of a event (command/effect) to an API server which routes/dispatches it to something that applies an effect. It’s not a function call, but a generic (implementation agnostic) description of intent in pure data. It’s like that but inside your program.
- dmn322 4y ago
  Is it kind of like events getting emitted and handled? I'm just a little fuzzy on what's creating the data/request/effect, and then where it's sending that once it's created, and then where the "drivers" would come from and how they would get invoked.
  - dgb23 4y ago
    > what's creating the data/request/effect Just a function. > where it's sending that once it's created, and then where the "drivers" would come from and how they would get invoked Depends on entirely on how you'd do it. You can apply the Functional Core Imperative Shell architecture, where side-effecting, stateful code (imperative shell) always calls the functional code (functional core). The shell basically handles files, db connections, HTTP/TCP, exceptions, retries etc. and basically asks the functional core of what to do by providing the data that comes out of those things. For example there's no reason a HTTP routing library has to do IoC. It can also be structured in a way so you you give it a path and it returns you data, such as an event description, a set of questions or a command description etc. There are also frameworks that work this way, for example the UI state management framework re-frame. It handles the side effects for you and calls your functions that you register on certain UI events. The re-frame documentation is very good at explaining this step by step.
LandR 4y ago
SOmething like this: (rf/reg-event-fx :stop-timer (fn [{:keys [db]} _] (let [handle (db :ticker-handle)] {:db (assoc db :ticker-handle nil) :stop-ticker [handle]}))) The side effect here is to a stop a running ticker on the page, but the `reg-event-fx` function just returns a map (data) where the first key is :db (which is the new app state, which is like a db, can even have a sorta schema over it) and the second key is the actual even :stop-ticker, which takes an argument handle (the handle of the ticker to stop). The event handler is just describing the side effect that is to occur by returning the map.
- dmn322 4y ago
  ok so would it be correct to say this is sort of like handling an event that gets emitted? Sorry, I know no clojurescript, so I'm having a hard time parsing it even googling the syntax
  - LandR 4y ago
    Yes, exactly. There is a piece of code which emits the event :stop-timer, that stops a js timer in the window. :on-click (fn [_](rf/dispatch-sync [:stop-timer])) In clojure a map has the syntax {:key :value} So this event handler is returning a map which describes the event. There is then a further function which does the actual event (rf/reg-fx :stop-ticker (fn [[handle]] (when (not (nil? handle)) (js/clearInterval handle)))) BUt as far as testing goes, you can test the event handler and test that it returns the expected map. The framework is responsible for actually executing the event that is described the event handler and it does it via the name :stop-ticker. Your event handler itself can remain a pure function.
comma_at 4y ago
Instead of doing the side effect you return a description and let the framework handle it. E.g. you don't call `transact(db, data)` but return `["transact", db, data]`. Now your function is pure. The framework will expect you to provide the transact handler, e.g. as `register_handler("transact", (db, data) => {..})`. Personally I'm not a fan of this abstraction (another layer of indirection). I'd rather take a `transact` function as an argument.

Can you give an example of what you mean by side effects as data?

by dmn322 4y ago

Can you give an example of what you mean by side effects as data?

You describe an effect as a data structure which gets interpreted and applied by the appropriate driver (for the lack of a better term). Think of how we do it on the wire: we send a description of a event (command/effect) to an API server which routes/dispatches it to something that applies an effect. It’s not a function call, but a generic (implementation agnostic) description of intent in pure data. It’s like that but inside your program.

dmn322 4y ago
Is it kind of like events getting emitted and handled? I'm just a little fuzzy on what's creating the data/request/effect, and then where it's sending that once it's created, and then where the "drivers" would come from and how they would get invoked.
- dgb23 4y ago
  > what's creating the data/request/effect Just a function. > where it's sending that once it's created, and then where the "drivers" would come from and how they would get invoked Depends on entirely on how you'd do it. You can apply the Functional Core Imperative Shell architecture, where side-effecting, stateful code (imperative shell) always calls the functional code (functional core). The shell basically handles files, db connections, HTTP/TCP, exceptions, retries etc. and basically asks the functional core of what to do by providing the data that comes out of those things. For example there's no reason a HTTP routing library has to do IoC. It can also be structured in a way so you you give it a path and it returns you data, such as an event description, a set of questions or a command description etc. There are also frameworks that work this way, for example the UI state management framework re-frame. It handles the side effects for you and calls your functions that you register on certain UI events. The re-frame documentation is very good at explaining this step by step.

LandR 4y ago

SOmething like this: (rf/reg-event-fx :stop-timer (fn [{:keys [db]} _] (let [handle (db :ticker-handle)] {:db (assoc db :ticker-handle nil) :stop-ticker [handle]}))) The side effect here is to a stop a running ticker on the page, but the `reg-event-fx` function just returns a map (data) where the first key is :db (which is the new app state, which is like a db, can even have a sorta schema over it) and the second key is the actual even :stop-ticker, which takes an argument handle (the handle of the ticker to stop). The event handler is just describing the side effect that is to occur by returning the map.

dmn322 4y ago
ok so would it be correct to say this is sort of like handling an event that gets emitted? Sorry, I know no clojurescript, so I'm having a hard time parsing it even googling the syntax
- LandR 4y ago
  Yes, exactly. There is a piece of code which emits the event :stop-timer, that stops a js timer in the window. :on-click (fn [_](rf/dispatch-sync [:stop-timer])) In clojure a map has the syntax {:key :value} So this event handler is returning a map which describes the event. There is then a further function which does the actual event (rf/reg-fx :stop-ticker (fn [[handle]] (when (not (nil? handle)) (js/clearInterval handle)))) BUt as far as testing goes, you can test the event handler and test that it returns the expected map. The framework is responsible for actually executing the event that is described the event handler and it does it via the name :stop-ticker. Your event handler itself can remain a pure function.

comma_at 4y ago

Instead of doing the side effect you return a description and let the framework handle it. E.g. you don't call `transact(db, data)` but return `["transact", db, data]`. Now your function is pure. The framework will expect you to provide the transact handler, e.g. as `register_handler("transact", (db, data) => {..})`. Personally I'm not a fan of this abstraction (another layer of indirection). I'd rather take a `transact` function as an argument.