RFC: Replace run and mutate operator with action about overmind HOT 5 CLOSED

I also encountered 2. while playing with overmind and that's what made me explore some alternative way to express actions (that and the type of parallele 😄 ) (https://github.com/etienne-dldc/meleze-store).
To be more specific I was doing some pattern matching (branch) and dealing with null value was just not practical... it feels like the declarativeness, while great for the most part, was holding me back.
Note: As I said before, I'm not proposing to change overmind's API, I'm just sharing my ideas in case it helps :)
So once I realized that I was not happy with the code I was writing I thought about how I could make it better. The answer I found was that the code I was having a hard time expressing declaratively should be written imperatively, with plain old Javascript !
You might say that RFC above solve my problem, and in a way it does. But what made me thing about a different system is that the action above is basically an opt out button, once you are in an action (aka imperative mode) you can't really go back to declarative, your only way is by returning an value but then it feels a bit out of order...
So how did I solve this ? By using the return value as the next thing to do.
Basically instead of building a function, I'm building an object (called an executable) that can be executed.
So const setFoo = mutate(({ state }) => { state.foo = 'bar' }) return an object that contain the mutation function.
Then you have an action() executable factory that take as parameter a function that must return an executable:

const maybeSetFoo = action(({ value }) => {
  if (value > 42) {
    // we return the mutation we want to perform
    return setFoo;
  }
  // null is ignored
  return null;
})

Here I could have used a filter but for more complex use case and things like type guards it's just not practical to use declarative code.
If you want to see what it looks like you can take a look here (still very WIP) : https://github.com/etienne-dldc/meleze-store/blob/master/src/index.ts

from overmind.

@christianalfoni Is this a thought experiment or does the implementation live somewhere we can play with?

from overmind.

@etienne-dldc Thanks for your input here! I see where you are going and yeah, that is certainly powerful! And I guess there is nothing wrong with us creating an operator that does exactly that. Instead of like when which returns a boolean, you return an actual operator. Though not sure about typing etc, which I guess you worked a lot on? :)

One thing I see though is that even though the implementation has a lot of power, it will hide some implementation details in the expressed pipe.

pipe(
  maybeSetFoo // You do not know what operator is actually run when truthy
)

pipe(
  when(valueIsMoreThan42, {
    true: setFoo,
    false: null
  })
)

This was of course a contrived example as well and splitting up into a when etc. is exactly where you start doing quite some additional work, as you point out. It is a difficult one and really nice to have both options POC-ed :)

from overmind.

@abalmos It is a tiny change I will do later today a long with a couple of other small fixes... which marks that my list of fixes is done and I can focus on more docs and start preparing some videos :)

from overmind.

Old stuff

from overmind.