rfcs
rfcs copied to clipboard
in-implementation updates to the default helper manager RFC, 756
During implementation, a couple things came up:
-
we don't do a great job of documenting when autotracking happens outside of getters -- therefore, added an example of autotracking in a helper to the examples section -- as composing helpers in classes that have access to tracked data can be a powerful encapsulation tool for library and app authors alike
-
we need a minor tweak to how arguments are passed to the helper function to enable default arguments for helpers relying on positional args
Much thanks to @chancancode for binging these things up.
Also, Idk how this is supposed to work with staged RFCs, :shrug: I guessed (feedback welcome, as always)
Notes from our meeting:
- [ ] Motivation: "it looks like a JavaScript call"
- [ ] Idiom Constraint: We want to support normal JavaScript idioms from Handlebars. This means that we need to support optional positionals, and we also would like to turn named arguments into a options object. However, in idiomatic JavaScript, it is difficult to have optional positional arguments and named arguments without doing a lot of manual checking. We are intentionally leaning into the JavaScript call idioms over the Handlebars call idioms, which do support that pattern.
I no longer have the energy to put in to this, so if someone wants to take it over, that'd be much appreciated
I think this is currently hung up on the text is still not very clear to everyone who read it/didn't capture everything we want to convey with the change succinctly. I can eventually wrap this up (or someone else could) but it's not a huge priority for me personally, because the feature was landed anyway. It's important to capture this in the RFC as the source of truth but it's not a blocker, though it's important to do it while we still have the context.
@chancancode do your thoughts remain the same here?