luci-base: form.js: keep config for disabled options

[thg2k]

When using "depends" functionality, fields that do not satisfy the constraint are hidden from view, and on save they are removed from the uci configuration. This causes a loss of information previously stored by the user when for example temporarily disabling a certain functionality. Upon reactivation of the said functionality, it is an improved user experience to restore any configuration previously used.

What do you think about this @jow- ? I'm not sure of side effects this change might cause.

[hnyman]

I have been thinking about the same "loss of previous config" at disable, as preserving the config details of dependencies of the disabled option might be interesting some times.

(Leaving the not-in-use options there might confuse the user in some cases, though)

[jow-]

This is what the rmempty flag was about, originally, but over the years its meaning was conflated with optional and nowadays it is not easy to untangle without a tree-wide refactoring and retaining backwards compatibility at the same time.

I'd suggest to introduce a new property .retain instead which defaults to false. If an option is found to have unsatisfied dependencies and if .retain is set to true, the value is not removed.

I am against making this the default behavior though since - in conjunction with default values - it'll cause configs to suddenly contain a lot of unused options, confusing users and violating LuCI's design goal of producing the smallest possible config without setting redundant (where value matches the default) or unused options.

Note that for places where it makes sense, a similar behavior can already be achieved by setting .remove to an empty function.

[hnyman]

The largest negative impact is on complex suboptions depending on the high-level options. E.g. disabling 80211r functionality causes you to lose all 15-20 R0/R1 keys & other config items that depend on 80211r option being enabled.

Would that proposed new .retain need to be separately defined for all the 10-20 different 80211r suboption fields?

Or could that .retain be defined for the top-level 80211r enabled option, meaning that preserve the lower-level suboptions even if this main options is disabled. The dependency would be evaluated in style of "enabled or retain". Would that work?

(Ps. right now that 80211r is not a huge problem any more, as most 80211r settings can be automately generated)

[jow-]

My proposal would require each individual sub option to be tagged. Since there is no real concept of "sub options" unless you want to apply it to all options of a section or if you consider any option a sub-option that is somehow dependent on a given option.

But walking the dependency tree is expensive and complex, I'd rather avoid adding too much logic for this comparatively minor use case.

[jow-]

Closing this as it will not be merged as-is.

[jow-]

Commit f5fbecf introduced a new retain property for options. You can set it on individual options whose contents should be kept when the options are disabled due to unsatisfied dependencies.

See also http://openwrt.github.io/luci/jsapi/LuCI.form.AbstractValue.html#retain