Knockout: Add 'readonly' binding in addition to enable/disable

[ddevault]

[brigand]

It's pretty simple, but I'm not sure how many people use readonly.

ko.bindingHandlers['readonly'] = {
    'update': function (element, valueAccessor) {
        var value = ko.utils.unwrapObservable(valueAccessor());
        if (!value && element.readOnly)
            element.readOnly = false;
        else if (value && !element.readOnly)
            element.readOnly = true;
    }
};

demo

[jakeatoms]

I like it and you could simplify to below:

ko.bindingHandlers['readonly'] = {
    'update': function (element, valueAccessor) {
        var value = !!ko.utils.unwrapObservable(valueAccessor());
        if(value !== element.readOnly)
            element.readOnly = value;
    }
};

[ddevault]

The reason I use readonly is because the data still comes through in the eventual form POST if you use readonly. If you use disabled, the form doesn't post that field.

[msnisha]

Yes, I think we need to have readonly binding in ko, since sometimes we need to POST the values to server even though if they are readonly (Example: Calculated values). Disabled fields are not posted.

[pennstatephil]

+1 for readonly - I am encountering this exact issue (need to POST value from readonly field)

ETA thanks @brigand / @jakeadams for the concise solution-- works great

[johnnyreilly]

This is already completely covered but I just rooted around in one of my projects and found this:

ko.bindingHandlers.readOnly = {
    update: function (element, valueAccessor) {
        var value = ko.utils.unwrapObservable(valueAccessor());
        if (value) {
            element.setAttribute("readOnly", true);
        } else {
            element.removeAttribute("readOnly");
        }
    }
}

I believe it was originally written by @rniemeyer : http://jsfiddle.net/rniemeyer/7Jynf/

[SteveSanderson]

To help us focus on more highly-prioritised issues, we're tidying up our issue backlog. We're closing the oldest feature requests that don't have pull requests and score very low on our triage ranking system. The low triage score for this feature request suggests we should focus our finite resources on other issues. For more details, see here. Thanks for posting this feature request though. If you still actively want this feature, please reopen this issue, or post a new one (and ideally, be prepared to supply a pull request if we agree the feature would be accepted). Thanks!

[ddevault]

@SteveSanderson did you do that action via automation? You may want to revisit this issue with a human's touch, the comments include code that would solve the problem.

[ddevault]

Nice.

[pennstatephil]

looks like someone will have to do it themselves and open a pull request to get it in at this point.

[IanYates]

@SirCmpwn - they're cleaning up the huge backlog of issues. 99% of them were support requests (answered or not) or issues that have been resolved by new developments in KO but issues that brought up the same topic weren't closed. Yours got caught up in the tsunami. I like this binding handler though - I'm going to add it to my code :)

[brianmhunt]

Re-opening for discussion. I think this is a handy binding too, though I'm not convinced it needs to be in core since the attr binding accomplishes much the same (or does it? I haven't checked :grin:) with attr: { readonly: variable }.

[IanYates]

I forgot about the attr binding for this - what you said makes sense but in my short time with HTML I've learnt not to just trust my gut :)

[ddevault]

You could use attr for enabled or for css or even value. It's okay to add a vanity feature.

[brianmhunt]

@SirCmpwn Using attr for enabled is ok, and I agree it's a vanity.

Note though that css (i.e. className) is more complex since it deals with additions and removals and treating it like an attribute has performance and SVG-compatibility (#1597) implications. So unlike enabled, css is not strictly a vanity.

Personally I would err on the side of strictly using the attr instead of the vanity features, and documenting how to add those vanity features like readonly and enabled because that sort of low-entry stuff is a great way for new users to learn about the innards of KO. That said, it feels inconsistent to have enabled and not readonly.

Thoughts?

[jzabroski]

It's not about vanity, it's about legibility. I marked this as subscribe to make a note to myself to make a PR.

[jzabroski]

@brianmhunt Here is another thing to consider. It looks ugly to just set readonly=true, because then the placeholder text is still visible giving the user a call to action. So I have written a custom readonly binding which removes the placeholder tag and stashes it on data-placeholder attribute using a Caretaker pattern.

https://jsfiddle.net/LkqTU/30453/

new code:

ko.bindingHandlers['readonly'] = {
  'update': function (element, valueAccessor) {
    var value = ko.utils.unwrapObservable(valueAccessor());
    if (!value && element.readOnly) {
      element.readOnly = false;
      element.placeholder = element.dataset["placeholder"];
    }
    else if (value && !element.readOnly) {
      element.readOnly = true;
      element.dataset["placeholder"] = element.placeholder;
      element.placeholder = '';
    }
  }
};