set-then and execute

[betocantu93]

Changes proposed in this pull request

This is a proposal and not ready to be code reviewed, just to open a conversation.

There are two helpers in this PR that cover two of our heavy use cases that we couldn't think of any combination of the current existing helpers could solve, error proof and ergonomically.

mut-then / set-then Helper

In Ember {{mut}} or ember-simple-set-helper {{set}} helper is widely used, and there's currently no helper to act in consequence of some mutation

While pipe works great for processing functions and passing the return value to the next one, in some situations regarding mut, we don't care about about the actual changed value, but we do care about the "event" of something actually changing, like an observer

For example think about an autosave use case, we actually don't care at all about the return value of mut, which also is just undefined I think.

<PaperInput @onChange={{pipe (fn (mut this.value)) (invoke "save" @model)}} />

While queue works great for passing the same argument to all the functions, again, in some use cases we just want to react. Using queue is worse because suppose the user typed my string, the onChange will be triggered with my string and if by any means we forget to pass @model "my string".save doesn't exist, so this is actually a bug, of course this example is trivial but in big compositions and partial applications this might happen

<PaperInput @onChange={{queue (fn (mut this.value)) (invoke "save")}} />

I know we can hand write actions in our components to handle stuff like this, but the dev ergonomics and composability goes to the floor.

The mut-then (we can name it differently, honestly this is just a PoC) proposal consists of only the first function receiving arguments, and then keep executing the next ones without any args, so we can set and then use the power of partial application without args pollution in the chain of fns.

<PaperInput @onChange={{mut-then (fn (mut this.value)) (invoke "save" @model)}} />

<PaperInput @onChange={{mut-then (fn (mut this.value)) (fn (pipe (invoke "save") onModelSaved) @model) }} />

And so on...

Execute Helper

Literally just execute all the actions without passing anything to them, let the client use partial application as it would expect, this is great way of reacting to events like onBlur, for example we don't really wanna be saving on every onChange for an input, but we probably wanna do it onBlur.

<PaperInput @onBlur={{execute (invoke "save") onModelSaved}} />

<button {{on "click" (execute menu.close (fn this.markAsRead notification))}}> Some Notification button {{notification.detail}} </button>

You can still continue to use combination of pipes and queues, and promise aware in any of these

Other Names:
mut-then => bind-then, bind-then-{chain,fire,trigger,run}
execute => chain, fire, trigger, run

[snewcomer]

So this is a copy of queue without args? What is the pain of ignoring the args in each action?

[betocantu93]

Yes that's correct, a copy but without args, mainly to give the template ergonomics, Currently there's no way to simple chain events giving the template full control of partial application without leaks, queue and pipe 'leaks' into the chain of fns, for example using on with queue helper leaks the Dom event to the chain, using pipe leaks the return value, which might actually cause troubles if any fn in the chain returns void and any of the next function args expects maybe params to be defined or something, you can see execute as the call helper but with a promise aware chain of fns

To chain perhaps unrelated stuff like closing a dialog, creating a contact, displaying a notification and also triggering @onClick and logging to Google Analytics via a service action, all of these fns may receive args in certain way or order so leaking may have undesirable effects

function something(str, isValid) {
  console.log(str)
  if(isValid){
     this.model.save()
  }
}

<button {{on "click" (queue this.openModal (fn this.something "hey there")}} >

Click me 

<button />

The event will be leaked, and so isValid would be true... I can try to give more examples if that doesn't make sense yet?

In our use case we have a serious amount of fns down on the render tree which need to hook say to the onBlur of an input and it wouldn't be posible if we had to worry about how they are actually physically placed, we see them as kind of a series of reactions to mainly user UI interaction event which any of them is entirely responsible of partially apply the needed params

[betocantu93]

Maybe call helper may receive an array of fns? Would that make more sense? 🤔🤔

//application.hbs
<BuyForm @logSomething={{fn this.log "buy_form"}} /> 


//buy-form.hbs
<SomeComponent @onClick={{execute (set this "closeDialog" true) @logSomething}} />

//some-component.hbs
<SomeDropdown as |menu|>
 <buttton {{on "click" (execute this.buyStuff menu.close (fn this.ga.sendEvent "clicked_buy_this") (fn 
  this.notificationManager.notify "thanks") (fn @onClick "clicked_buy_this")) }} >
    Buy this
 </button>
</SomeDropdown >

Opting out from leaks makes sense when dealing with deeply nested trees of components

[snewcomer]

Ok that makes sense. Thx for the explanation! I think we will need to come up with a really clear name b/c when one steps back and evaluates how to call a chain of functions, I'm not sure an obvious answer stands out (and may be more confusing with two options)

[betocantu93]

Yup, totally agree, what do you think about sequence?

• sequence

🤔🤔🤔

[snewcomer]

Also, it sounds like the functions you are using might be called in multiple places? Otherwise, you could always align the arguments with the arity of arguments if only used in one spot?

I'm also thinking about this from a typescript point of view. You have a list of expected arguments. However, this will pass nothing and could show an error. Typically, in this case you would compose multiple functions together while perhaps sharing some logic.

What are your thoughts?

[betocantu93]

Also, it sounds like the functions you are using might be called in multiple places? Otherwise, you could always align the arguments with the arity of arguments if only used in one spot?

Yes, pretty much. I use them sparingly across the app/engines in different ways, from JS and helpers, so having full control on the template is a must, to avoid foot guns.

I'm also thinking about this from a typescript point of view. You have a list of expected arguments. However, this will pass nothing and could show an error. Typically, in this case you would compose multiple functions together while perhaps sharing some logic.

Honestly I haven't (probably should) used a lot of functional programming or composition of fns, in .js land in Ember. I often use the templates for that, but I agree, you compose multiple functions together taking the arity, order and such into account when needed to share logic or something in common, in this particular case, the only thing these fns have in common is that they were triggered by something... sometimes an event, sometimes a callback, basically like observer pattern, pretty much, these are subscribers fns. in a Template only Component land, pipe, queue, (sequence|execute) come pretty handy

[betocantu93]

Another good approach could be to just add a noargs helper...

<button {{on "click" (queue fn1 fn2 (noargs (fn fn3 myWantedArg)))}}>

function noargs(fn) {
  return () => fn()
}