UI: Command history

[ghost]

Action: Port / Rewrite functionality from LW3

Present Source:
https://github.com/LaserWeb/LaserWeb3/blob/master/public/lib/jquery/jquery-input-history.min.js and https://github.com/LaserWeb/LaserWeb3/blob/master/public/js/main.js#L219-L225

Desired result: Command console: Press up/down to access previously sent commands. Gets stored in Localstorage for reuse

[jorgerobles]

I've got that working, but I'm worried about localstorage backend, as it uses serialization, so cannot access the command history as a single line, rather get from localstorage to memory, rendering useless for this case.

[jorgerobles]

Will reopen upon future work on it (Gcode running and so on...)

[jorgerobles]

uMinded Strikes Again - LaserWeb / CNCWeb (Development Casual Chat) - 18:02

How can I log processing output to the "commandHistory" div?
Creating a progress bar is difficult as you need to know runtime but a simple "[1/5] Loading Cutme.dxf" etc would be benificial I think.

[jorgerobles]

@tbfleming, should we have this on the main or a secondary state storage? Now this component state is not bound with redux store.
Actually this is related with Commands sent to server but does not relate with a general log. If so, the current approach should not be efficent.

[jorgerobles]

Maybe just hacking into the component thru ReactDOM to append the non-command line is possible, but any command entered will trigger re-render of stored command history, so destroying the former line.

[tbfleming]

This is tricky; I haven't put any thought into it. Something to watch out for: React state and DOM state are regularly purged. e.g. what what happens with Hide Docs / Show Docs.

[iceblu3710]

Would be nice if there was a simple call that dealt with all the state issues behind the scenes. Just call commandHistory.append(string, icon) or something like that.

All the state and moving parts are pretty confusing.

[tbfleming]

@iceblu3710 I agree

[tbfleming]

@jorgerobles there's a way in React to make a DOM child outlive its React parent. Every time the React component is reconstructed it would add the pre-existing DOM child to itself. The entire state could safely live in that child's DOM. I suspect that would be the second-most efficient approach. The most efficient approach is probably virtual scrolling, which is complicated to set up.

[jorgerobles]

@tbfleming do you know the name of the technique of outliving (I have no idea how to search for it)

[tbfleming]

I don't think it has a name. componentDidMount() can add existing or new DOM nodes as children.

[jorgerobles]

Well, here's something working.
Added static method CommandHistory.log(message, level, icon) to be called elsewhere.

I have detached a CommandLog component and hold its instance on window.commandHistory. It's attached and detached at CommandHistory didMount willUnmount, so the object should exists even when is not visible (not sure, but surely react will complain)
by the moment It's not storing a persistent state so a page reload could wipe the data.

[jorgerobles]

@tbfleming about the hide/show docs issue, I did not want to pollute the application state with so feature, but if is annoying I could try to use the "detached" technique. Maybe I can store them at class level instead of window level. Alternatively we can use an UI redux store, so use it to bind all the states that are merely visual, and the main (APP) store for the rest. (There's no sense to pollute the main store with "visible"/"hidden" flags everywhere)

[tbfleming]

The main store already has a lot of UI state, including active tab, which operation is expanded, splitter positions, camera zoom, pan, and rotation, the workspace settings at the bottom, plus more. The store is really good at that kind of stuff.

window.commandHistory: you're close to what I mentioned, but not quite. For performance reasons, window.commandHistory and its children probably need to be native DOM nodes which aren't managed by React. React has poor performance with long lists, except with the more complicated virtual scroll approach. This is one of those rare cases where Document.createElement, Node.appendChild, and Node.removeChild are better than using React's normal approach.

[jorgerobles]

I've moved the log to use native DOM element. @iceblu3710, have you seen the example of use?

[iceblu3710]

@jorgerobles, yes I saw it. This will be very handy, thanks!

[jorgerobles]

I'll close until further work on it (lw-comms)