Brainstorming

[pfalcon]

General development approach:

1. Would be nice to develop cute unbloated dashboard from scratch, with VanillaJS and stuff, but that may take quite an effort (mostly dealing with that JS stuff).
2. So, porting an existing project would be more realistic, even as an intermediate step. Yes, we'll end up with something bloated and which still will require digging into JS bloat to e.g. short-circuit something, but at least result "will work" (as good as the original).
3. This is not my first attempt to hack up a dashboard, can dig previous attempt(s) too.

Expected result approach:

1. Would be nice to develop clearly separate, reusable frontend which could be easily made work with any backend (not just MicroPython/Picoweb, not just Python). That means configuring the dashboard and widgets on JS side, and that may be challenging wrt to support of several instances of the same widget with different settings/styling.
2. The alternative is to develop solution tightly integrated with Picoweb backend (less JS programming again).

Widget approach:

1. Can have just small static widgets.
2. Can have small static widgets, which "maximize" on click to provide more info, iGoogle-style (e.g. weather widget shows just current weather by default, and shows forecast for few days when expanded).
3. Can have interactive small static widgets (e.g. being able to to turn on/off light).
4. Can have fully full-featured small static widgets, which can do p.2, p.3, or anything else.

Data delivery approach:

1. Can leave that to widgets themselves, i.e. make them pull it from their side. That means dealing a lot with JS.
2. Can push data to them instead, e.g. via Server Side Events (EventSource).
3. For bi-directional realtime comm, websockets will be required.
4. Can either deliver structured JSON data which widgets will render, or unstructured data which widgets yet will need to process/filter (e.g. the extreme case of p.1 is that widgets will pull pages/APIs from external internet and parse them themselves).

Regarding this, we apparently want to do as little as possible in JS, and as much as possible in Python. (Up to a point, a browser devices may have more resources than MicroPython device).

Tabbed interface:

1. There can be a lot of widgets and/or desire to group them differently, so there should be support for multiple dashboards in different "tabs". It's tempting to use dashboard widgets for switching among the tabs.
2. But, some tabs may contain other layouts than dashboards, so it's better to have explicit and standalone "tab handles" outside a dashboard.

[pfalcon]

So, porting an existing project would be more realistic, even as an intermediate step. Yes, we'll end up with something bloated and which still will require digging into JS bloat to e.g. short-circuit something, but at least result "will work" (as good as the original).

PyDashie was ported as a proof of concept: #2.

[joewez]

What about a semi-compatible library to jQuery like Umbrella.js? ([https://umbrellajs.com/]) I've been looking for a small JS script that is easy to deliver with an ESP8266 PicoWeb app. It is what I could find. Haven't run it through it's paces though.

[pfalcon]

@joewez: There's a gazillion of such libraries, e.g. http://microjs.com . The problem arises when you try to do non-trivial things, e.g. grid layouts, advanced widgets, charts, etc. All that stuff is available as jQuery plugins and known to work and integrate well enough with each other. Some of that stuff also exists in VanillaJS form, but often it's missing features (or goes big too), has various issues, lacks support, etc.

[pfalcon]

This is not my first attempt to hack up a dashboard, can dig previous attempt(s) too.

So, I had a look at what I was working on ~3 years ago. There, I exactly followed approach "try to make widgets independent from backend". Thus, all widget js/html/css loading was handled by JS itself, and by extension, I also bothered to implement pull-style processing in widgets, ajax-loading pages, filtering, parsing them, and them performing HTML templating.

That worked in expected way - poor Android browser this ran in regularly stopped to updated some widgets, then locked up/crashed. Starting the webapp now, some widgets come out completely empty, because there was some error during JS parsing/templating them, which are of course boring to debug, etc.

So, NOWAI. There should be push-style approach, as much processing as possible should happen on Python side. Q: It's cute PoV when widget shows just a single scalar value, but reality, there're lists, tables, etc. ... A: Yeah, render HTML on Python side and push like that.

[mordyovits]

Would it be acceptable to assume that the browser accessing the dashboard has Internet access? In that case, you can have the client fetch the heavy JS libs from a CDN, not from the micropython device.

[pfalcon]

Would it be acceptable to assume that the browser accessing the dashboard has Internet access?

No: http://www.vmwareinfo.com/2017/09/smart-home-lessons-from-hurricane-irma.html

In that case, you can have the client fetch the heavy JS libs from a CDN, not from the micropython device.

Sure, that can be a particular case (and everyone would start like that), but a "universal" solution should provide a fully "self-hosted" option, and thus think about the size of JS stuff (and about serving it gzipped, etc.).

[mordyovits]

That makes sense.

…

On Nov 27, 2017 4:38 PM, "Paul Sokolovsky" ***@***.***> wrote: Would it be acceptable to assume that the browser accessing the dashboard has Internet access? No: http://www.vmwareinfo.com/2017/09/smart-home-lessons- from-hurricane-irma.html In that case, you can have the client fetch the heavy JS libs from a CDN, not from the micropython device. Sure, that can be a particular case (and everyone would start like that), but a "universal" solution should provide a fully "self-hosted" option, and thus think about the size of JS stuff (and about serving it gzipped, etc.). — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFUXxrz40ESFJ78RWqWvGHkveDCM1nDSks5s6yvxgaJpZM4QqWP4> .