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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Checkbox / Radio Bindings [RFC] #447

Open
davismj opened this issue Feb 18, 2019 · 2 comments

Comments

@davismj
Copy link
Member

@davismj davismj commented Feb 18, 2019

馃挰 RFC

Most input bindings are pretty straightforward, but checkboxes have some additional common use cases that should be handled in vNext out of the box. New use cases are marked.

Additionally, to reduce confusion, we should remove the model property in favor of the value property, if possible.

basic checkbox

  • when checked, checked = true
  • when unchecked, checked = false
  • checked when !!checked
  • unchecked when !checked
<label>
  <input type="checkbox" checked.bind="checked" />
  Checked
</label>

猸愶笍 negated checkbox

  • when checked, checked = false
  • when unchecked, checked = true
  • checked when !checked
  • unchecked when !!checked
<label>
  <input type="checkbox" checked.bind="checked" value.bind="false" />
  !Checked
</label>

scalar-valued radio

  • when checked, checked = value
  • checked when checked == value
  • unchecked when checked != value
<label repeat.for="value of values">
  <input type="radio" checked.bind="checked" value.bind="value" />
  ${value}
</label>

object-valued radio

  • when checked, checked = value
  • checked when checked == value
  • unchecked when checked != value
<label repeat.for="value of values">
  <input type="radio" checked.bind="checked" value.bind="value" />
  ${value.label}
</label>

猸愶笍 scalar-valued checkbox

  • when Array.isArray(value)
    • when checked, checked.splice(0, checked.length, ...value)
    • when unchecked, checked.splice(0, checked.length)
    • checked when checked.length === value.length && checked.every(c => value.includes(c))
    • indeterminate when checked.length != value.length || checked.some(c => !value.includes(c))
    • unchecked when checked.length === 0
  • when !Array.isArray(value)
    • when checked, checked = value
    • when unchecked, checked = null
    • checked when checked == value
    • unchecked when checked != value
<label>
  <input type="checkbox" checked.bind="checked" value.bind="values" />
</label>
<label repeat.for="value of values">
  <input type="checkbox" checked.bind="checked" value.bind="value" />
  ${value}
</label>

猸愶笍 object-valued checkbox

  • when Array.isArray(value)
    • when checked, checked.splice(0, checked.length, ...value)
    • when unchecked, checked.splice(0, checked.length)
    • checked when checked.length === value.length && checked.every(c => value.includes(c))
    • indeterminate when checked.length != value.length || checked.some(c => !value.includes(c))
    • unchecked when checked.length === 0
  • when !Array.isArray(value)
    • when checked, checked = value
    • when unchecked, checked = null
    • checked when checked == value
    • unchecked when checked != value
<label>
  <input type="checkbox" checked.bind="checked" value.bind="values" />
</label>
<label repeat.for="value of values">
  <input type="checkbox" checked.bind="checked" value.bind="value" />
  ${value.label}
</label>
@davismj davismj changed the title Checkbox / Radio Bindings Checkbox / Radio Bindings [RFC] Feb 18, 2019
@davismj davismj added the RFC label Feb 18, 2019
@davismj davismj added this to Implemented in Proposals Feb 18, 2019
@davismj davismj moved this from Implemented to Discussion in Proposals Feb 18, 2019
@bigopon

This comment has been minimized.

Copy link
Member

@bigopon bigopon commented Feb 18, 2019

I think the issue with this is

it breaks .value for object scenario if we patch/override that property
It makes binding unpredictable when value binding nolonger consistent with the rest

@davismj

This comment has been minimized.

Copy link
Member Author

@davismj davismj commented Feb 18, 2019

Makes sense to me. It would be a nice to have but I don't really think it is critical.

I'm trying to think of it from an average developer's perspective. It's one more thing to learn, so why do we have to learn it? Why couldn't we just throw away / ignore the underlying input.value value and just use one value managed by Aurelia's binding engine? What developer out there even cares what input.value is anyway?

@fkleuver fkleuver added this to RFCs in Work queue Oct 7, 2019
@fkleuver fkleuver moved this from RFCs to Triage in Work queue Oct 7, 2019
@fkleuver fkleuver moved this from Triage to RFCs in Work queue Oct 7, 2019
@fkleuver fkleuver moved this from RFCs to Backlog in Work queue Oct 7, 2019
@fkleuver fkleuver moved this from Backlog to In progress in Work queue Oct 7, 2019
@fkleuver fkleuver added this to the Au2 v1.0-alpha milestone Oct 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Proposals
  
Discussion
Work queue
  
In progress
3 participants
You can鈥檛 perform that action at this time.