bindingSources to take constructor's context

[chikamichi]

Hi,

I commented an issue on underscore which relates to Epoxy.

I honestly don't know what to think of it, whether it's a bug, a feature-request, an invalid statement… but reporting it here seemed the best move.

---

Edit: reporting issue in the appropriate tracker, as requested in first comment.

Hi,

I found out that Epoxy makes use of _.result to "compute" its bindingSources. Given the current implementation of _.result, Epoxy cannot account for the contextual data passed to the Epoxy view (which is a Backbone View, really). Therefore bindingSources, when expressed as closures/functions, cannot receive the view options or any kind of context.

One painful aspect of bindingSources as it is now relies on the fact that it is automagically executed at constructor-call time. But there is a reason to it, so simple ways to alleviate the limitations that comes with this design would be to either:

• be able to proxy the constructor's options through _.result, to the bindingSources attributes
• get rid of _.result, use some verbose, compliant code instead

As for now, a developer willing to work around this limitation without touching Epoxy's source code can output something nasty like this (coffee inside for the sake of brievity):

# in the Epoxy view:

# Nope!
#bindingSources:
  #usefulData: (arg) -> …

initialize: (options) ->
  @someData = new Backbone.Model(options.someData)
  Object.getPrototypeOf(@).bindingSources =
    usefulData: @someData

This does not rely on passing arguments to custom sources, though. It just ensure code is executed within the scope of the fully-fledged view. It is a viable alternative, but may not fit well with Epoxy's current design (initializing custom sources at constructor-time).

There is a discussion in Underscore's issues tracker about whether _.result should be modified to allow extra arguments to be passed. It doesn't seem like a good idea, though, as this helper has been designed to handle simple use-cases.

[gmac]

Hey, please do me a favor and keep Epoxy-related discussion confined to this Epoxy forum. Underscore is our dependency – if something doesn't work the way we want it to, the solution is to adjust behavior within Epoxy... not request changes to our foundation components.

[chikamichi]

Well, double-checking my writing, I actually did not request any change within Underscore, which implementation seems rather fair. I merely reported a potential use case found in the wild, as @braddunbar wrote "feel free to post more use cases". Whether this use-case is legitimate is debatable, therefore I wanted to let you know so that you could think about it in the specific context of this very library.

I am sorry if the place to report that was not optimal. The internet is vast, people do get lost sometimes.

But yeah, aggressivity overriding insights, I like that :+1:

[gmac]

Your report is a little verbose, so I'm not entirely sure that I follow... My interpretation of your issue here is that all _.result functions are called without context, therefore factory functions do not have access to the initializing View instance? I just checked Underscore source and confirmed that the _.result method does not accept a context argument. Without Epoxy switching to a new library-specific implementation of _.result (which admittedly wouldn't be difficult), Underscore doesn't give us the tools to support context there.

I guess my hesitation to move away from the current system would be that Backbone uses the Underscore method, and Epoxy uses Backbone... therefore I'd like to keep these nuances consistent across all libraries.

[chikamichi]

Your interpretation is right.

Using either bind or a composition of function, involving _.result and a proxifier (setting the execution context to that of the view) would make for a simple, underscore-based fix.

Thank you for your feedback.