One thought, something I hadn't tried before -- we could modify
the user models directly in if we could guarantee (a) no attribute collisions
with any other components that use that model, and (b) that the attributes get removed as soon as the component which added them gets
destroyed.
If the component placed its 'checked' attribute into a component-specific namespace under each user (e.g., instead of 'user.checked', something like 'user._cid3.checked', where _cid3 identifies the component) then we'd avoid attribute collisions when that same user instance gets handed to different components over its lifetime. The component would generate/claim a unique identifier on init ("_cid3" in this example), add it a property on each user, place all user-specific data under that property (instead of storing data on the user directly), and then delete that _cid3 property once the component gets removed/destroyed.
This feels rather dirty to me, but it would allow us to bind directly to the models as we're looping over them instead of needing a separate 'checkedItems' map -- thus allowing the system to look much closer to your example, since we wouldn't need any of the consequences of trying to store attributes across two different observables (such as that {{checkboxFieldValue}} helper). We might even be able to use {{#with ...}} to do this transparently for the template's benefit.
It wouldn't be pretty, but it might be less ugly than what's in that fiddle now.![]()
If the component placed its 'checked' attribute into a component-specific namespace under each user (e.g., instead of 'user.checked', something like 'user._cid3.checked', where _cid3 identifies the component) then we'd avoid attribute collisions when that same user instance gets handed to different components over its lifetime. The component would generate/claim a unique identifier on init ("_cid3" in this example), add it a property on each user, place all user-specific data under that property (instead of storing data on the user directly), and then delete that _cid3 property once the component gets removed/destroyed.
This feels rather dirty to me, but it would allow us to bind directly to the models as we're looping over them instead of needing a separate 'checkedItems' map -- thus allowing the system to look much closer to your example, since we wouldn't need any of the consequences of trying to store attributes across two different observables (such as that {{checkboxFieldValue}} helper). We might even be able to use {{#with ...}} to do this transparently for the template's benefit.
It wouldn't be pretty, but it might be less ugly than what's in that fiddle now.
