Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(buttons): Fixes handling for disabled attribute and property #1095

Closed
wants to merge 4 commits into from
Closed

Conversation

alex321
Copy link
Contributor

@alex321 alex321 commented Nov 28, 2016

Fixes #1088
Fixes #1089

@alex321
Copy link
Contributor Author

alex321 commented Nov 29, 2016

@pkozlowski-opensource Let me know what you think. It works, but I guess it could be done better. I had a look at Angular Material 2 for comparison and ideas.

@alex321
Copy link
Contributor Author

alex321 commented Nov 29, 2016

Added test and implemented the following:

  • if ngbRadioGroup is disabled then all inputs are disabled
  • if ngbRadioGroup is enabled then inputs are disabled independently

I hope that this should fix all relevant functionality.

}

updateDisableState() { this._crf.detectChanges(); }

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wow, this sounds super-fishy! Why do we need to do this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I knew you'd mention that. I didn't like it either.
The question is what should happen when the group disabled state changes, say from true to false. The buttons should then check what state they are in. How should the buttons get notified when that happens?
I will have a look but let me know if you have any ideas.

get disabled() {
let result = (this._group && this._group.disabled) || this._disabled;
if (this._label) {
this._label.disabled = result;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not super-fan of having side-effects in a getter (in other words - we shouldn't be doing this). What is the motivation / problem that we are trying to solve here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't like that either. It is a bit similar to the previous comment.
The question is how to keep the label in sync with the input. Again, I will have a look, but any suggestions appreciated.

@pkozlowski-opensource
Copy link
Member

@alex321 I had a look at the PR and while tests look good I've got some reservations regarding the existing implementation (left comments in the PR).

Also I would prefer that we separate fixing a bug (handling of the disabled state on a button level) from new features (adding disabled support on a group level).

Given the 2 above comments I'm not keen on merging this PR as-is. Do you think you can give it another shoot with just a bug fix and avoiding impl patterns I've pointed out?

@pkozlowski-opensource
Copy link
Member

Also I would prefer that we separate fixing a bug (handling of the disabled state on a button level) from new features (adding disabled support on a group level).

Scratch this, we do already have support for the disabled state on the group level. Sorry for the noise.

@pkozlowski-opensource
Copy link
Member

@alex321 in fact I've played with it a bit now and I think I've got an alternative approach - could you please have a look at #1141 and let me know what you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants