Component bindings are bound too late

[nsgundy]

When I pass a component with bindings to the ModalService.showModal() function, I would expect to have the passed values available in the $onInit() lifecycle-hook of that component (that's when all the bindings are supposed to have been initialized). However, that is currently not the case and one can observe the value only being set later. A workaround is to use the $onChanges() lifecylce-hook of the component, but that's not always convenient.

// test.component.js
export const TestComponent = {
  template: `<tabs initial-tab="$ctrl.test">...</tabs>`
  controller: function() {
    $onInit() {
      console.log(`test=${this.test}`)
    },
  }
  bindings: {
    test: '<',
    close: '<'
  }
}

// somewhere in the application
ModalService.showModal({
  component: 'testComponent',
  bindings: {
    test: 'this is a test'
  }
})

Other observations:

• close needs to be bound as a one-way binding (>) and not an event binding (&) as I would have expected
• Using text bindings (@) does not work. Modifying the above example, test will evaluate to the string bindings.test
• I have not tried binding to event bindings (&) on the component, glancing at the source code I'd imagine that they won't, especially when trying to pass events with data

@DougKeller Any ideas on how to address these issues?

[nsgundy]

Right, the issue for the bindings being bound too late is that they are only put on the scope once the controller is being run. If the bindings are placed on the injected scope directly, then the issue vanishes and $onInit() inside the component has access to the bindings.

[dwmkerr]

Anyone able to make a quick PR w/ tests to show the correct behaviour?

[DougKeller]

Apologies, I didn't notice this issue when it was first brought up. Funny enough we ran into this ourselves internally, so I just pushed #280 to address the $onInit issue.

The attribute and output bindings issues you brought up are trickier issues, so I didn't address those here. It's not ideal, but like you noticed using a one-way input binding for these instead works.

I've added a note to the readme to reflect this.