WebUI fix change detection of input elements

[mcspr]

• use setOriginalsFromValues function right after elements had changed and
  only with those elements
• add checkbox handling to setOriginalsFromValues to match hasChanged
• apply hasChanged after value is set to refresh originals after saving
• change parts that already set 'original' attribute manually

This was sort-of broken, because nothing really bad happens besides sending all of the available key-values to the device.

And I am not really sure what is up with the schSwitch: [0xff]. Need to look at it again and then I will commit this
upd: This part is reworked by using empty array when there are no schedules, scheduler code on the device uses 0xff as the default anyway. Similar code is added for the wifi objects.
Sending as arrays instead of plain keys (see comments bellow about deep-object-diff) to allow clean-up methods to work. Diff library is ~1.5KB additional code, so more things need to change.

fix #2035

[mcspr]

What I need to look into is those arrays, because changing value in the middle will not put it at a proper index later.

I guess the is_group could be removed. Since we receive all of the data, name attribute could be the same as the settings key e.g. (with current ws api):
relayBoot0 => "0" from settings -> {relayConfig:{boot:[0]}} via json -> input[name="relayBoot0"] in the interface.
input[name="relayBoot0"] in the interface is changed to 1 -> getData() -> {'relayBoot0': 1} -> relayBoot0 is written with a basic setSetting(key, value), no need to unpack it.
And since getData will now only send data partially, no need to worry about the size here.

@Tofandel If you have some spare time, any problems here / shorter approach to track 'original'?
I was going to steal something from the other PR, but I think that part is not yet here (settings saving specifically)?

espurna/code/ui/src/App.vue

Line 364 in c4500a3

this.sendConfig(this.$refs.formSettings.values);

Printing values -> {"modules":{},"version":{},"device":{"hostname":"ESPURNA","desc":"","now":1573372283,"uptime":22,"lastUpdate":22},"relay":{}}"

[Tofandel]

Are you trying to send only the modified data but need to send the full arrays?

I would change the approach, get the entire data then do an object diff (non deep) between the original and that data, that's what I'm gonna do in vue

[mcspr]

Yes. Not-yet-pushed version just adds index to the name when creating elements, avoiding arrays on the way back to the device and using flat object as in settings.

[Tofandel]

So you should get full arrays or new value if modified and null if deleted and nothing if not changed

[Tofandel]

Okay so you need to do a deep object diff and then just flatten the result and send it, dead simple

[mcspr]

Ok. I'll get back with the code in a bit Effectively, the ws keyCheck things are filtering unsupported data keys instead of UI. Since haschanged now actually does something I hope this means some code shrinkage on that front and the config parser block

[Tofandel]

No and yes. A deep diff should basically tell you what was modified, added or deleted and then you do what you need to do (eg flatten each one individually and merge all of them)
https://www.npmjs.com/package/deep-diff (see example to understand the data you get with info on what's added, deleted, modified)

Or simpler to use the data https://www.npmjs.com/package/deep-object-diff
Have a look at the detailed diff example
Once flattened in the end the deleted keys will be sent as null and the arrays only the modified keys sent with the right index

[Tofandel]

But that means you need the exact and entire state of the previous data to compare it with the entire new state

[mcspr]

Thank you for the link, that makes it more clearer. idk though how much code I am willing to add to the existing webui at this point. edit: aand I have tried the deep-object-diff and looked at your's example in the Vuejs pr. It does pretty much the thing that I wanted to do.

But, scheduler uses a lot of keys, so it is unclear whether this actually saves anything. WiFi objects a bit different since the most common case is just 2 keys. Easiest are Rules, just a single string. Other things are fixed size based on relay / magnitude association.
RFBridge kind-of handles things on it's own, saving each element on demand.

I guess the other problem is having html element's original=... storing the old state? One approach I could try is to hide them instead of removing right away, allowing Save to actually commit the resulting state. Then it is just a matter of either sending things as is, or adding special handlers like ssidN => "", schSwitchN => 0xFF to erase the settings group.

[mcspr]

General npm / babel / browserify question. Looking at deep-object-diff package, there are bunch of modules that are exported through the src/index.js. I was under the impression that I would need to compress + mangle everything into a single file to make it work with the existing htmlmin

// ...somewhere in the package.json...
"browserify": {
    "transform": [["babelify", {"presets": ["@babel/preset-env"]}]]
 },

But how come nothing gets added to the window? Only if --standalone some_object_name option is used for browserify, only then I get window.some_object_name.detailedDiff

edit: Or via webpack analogue:

    entry: "./src/index.js",
    output: {
        library: ["some_object_name"]
    }

I guess it is expecting some app as an entrypoint instead of barebones module?

[Tofandel]

Because it's the default behaviour of webpack to build as an app with an entry point and nothing accessible in the outer scope, so yes what you're doing is effectively creating a library so you either need to specify the output library or to set the imported function on window.detailedDiff = detailedDiff in your index.js

[Tofandel]

I think the simplest way to fix the issue is the best, so if with DOM/events only works well enough without complicating too much the process, it's fine and go for it

All this is handled quite easily with the new data state in the vue ui, I'll work on it this weekend and should get it ready soon, the PWA is taking shape

I might need some help getting the public API built though
(To output device name, description, board name and espurna version on a public endpoint)

[mcspr]

True, but I hope I am not overthinking it. At least it will be some baseline to compare to. Looking forward to Vue :)
This was also a nice refresher of how js stuff works at all.

sidenote:
If only I thought about this sooner - mcspr@7b701c5, compression even figures out a way to make this commit only ~150B in size. And also works in half the time.