Thoughts on the new Input and Feed page layouts

could you see if there is a line number associated with the javascript error in the console log?

Iā€™m actually got beta off at the moment, but I thought I would try editing a device that was previously giving the error (in the new look inputs page) form the device page and it does the same error from there. So this is a device module thing not a device integration or new look thing.

And, now Iā€™ve posted that I have just recalled noticing that there is a commit on the master branch of the device module that hasnā€™t made it to the indexedinputs branch that maybe related. (see Comparing indexedinputs...master Ā· emoncms/device Ā· GitHub)

Andā€¦ when I try to update the database I get caught in the loop previous reported by @Paul




and so onā€¦

I will look into deleting the empty devices or adding an input so they are not empty to see if it has any impact, I will try to confirm next time I switch beta on.

Even with the cookie working, it will still annoy the hell out of me if I use another machine or the cookie expires, why canā€™t the existing default collapsed or default uncollapsed setting be reused in the beta version? That setting is the single best feature of the existing inputs page. I would prefer it is always fully closed when I open the page or refresh, I would prefer it not to remember what I had open previously, itā€™s like returning to a cluttered desk, I liked starting afresh each visit.

Thanks for spotting, Iā€™ve merged that change now into device:indexedinputs. I also updated emoncms:indexedinputs yesterday to contain the latest from the master branch.

Im personally quite fond of the saved collapsed/uncollapsed state feature. I found always arriving at a collapsed view when I wanted to generally see the status of the emonpi or emontx node a pain :slight_smile:

Iā€™m not so concerned about the saved state, I can live with that (if it works correctly) and I understand it is required for the sideswipe mobile views etc. What I cannot live with is the default (if thereā€™s no cookie or itā€™s expired etc) being to expand all. There must be a hard-coded default to fully uncollapsed in the new views as that is the action weā€™re seeing. I donā€™t understand why that cannot use the existing setting for open or closed.

I understand adding saved state, but I do not understand it being at the cost of an existing feature when it neednā€™t be. The open/closed default user setting should also dictate the first action of the collapse/uncollapse button on page. If I do come to an old previous ā€œsaved stateā€ then clicking the collapse/uncollapse button should always collapse all (if user setting is ā€œclosedā€) otherwise not only are we met with a partially collapsed/uncolapsed page but it will take 2 clicks of the button to get to the users preferred default state.

If itā€™s not possible to use the existing setting, then please at least point out where in the code it is hard-coded (both the page and button states) so that I/we can make local changes and stash them across updates, this as you can understand is going to seriously impair the experience of using emoncms.

Weā€™ve sat on opposite sides of this fence before which led to you kindly adding the default user setting in recognition of the fact users differ, I do not understand why that feature has to be lost to add ā€œsaved stateā€.