UI: Think about a scaleable, future-proof Framework for Frontend

[col-tom]

The project is continuously growing and therefore also the User Interface is faced with a lot of challenges in the future:

• more state (that is in sync with UI and device)
• handling state that must be persisted on the device and therefore handling success, loading state and failture (+ user feedback)
• different UI controls / forms that depend on other state
• form validation
• async data
• mobile view / responsive
• ...

Currently the Javascript code is in one big file and not really easy to maintain, also tests for the frontend is missing. Personally I would like to have a lightweight framework like Preact or similar (component based development).

This issue should serve as a starting point for ideas and discussions.

[rojer]

one thing to keep in mind is that our space budget is very tight - current filesystem size is 256K but will likely be reduced to 128K as we are almost out of code space and will need to resize. we also need to leave some space for config, logs and other miscellaneous stuff, so realistically we don't want web content to exceed 50K in size, all told (currently about 18K). there is also a reason for not having multiple files: during revert to stock all the files that are not present in the stock version will be copied over and thus take up space on the stock firmware, which may have its own constraints. index.html.gz is present in the stock firmware so it will be overridden with the stock version.

[col-tom]

ok, let's get into the discussion:

• space budget: especially for that, it's nice to have such a framework (reusable components) and with a bundler that does a lot of stuff to extremely (!) compress all the asset files (HTML, JS, CSS, ...) With a bundler we can even automatically check and warn if size is e.g. over 20k and so on
• UI development: what's the long-term solution here? IMHO the current manual appraoch isn't feasible with more developers and requriements coming in

What do you mean exactly by "having multiple files / stock firmware" ?

[timoschilling]

What do you mean exactly by "having multiple files / stock firmware" ? We only want to have files in the firmware which are in the stock (original shelly) firmware, too. The reason is that then the stock firmware will overwrite our files if a user switches back to stock.

Other wise we can run in the case that we mess up the filesystem space and we will brick the stock firmware then.

But if we bundle our assets into the index.html like we do it now, we are fine. Then we only need to handle with the size limit.

Have you seen that I have improved the development system, you can now open the fs_src/index.html local in your browser and connect them with a shelly. That means you can simply edit, safe and reload to view the changes.

Some days ago I reduced the fs size by ~4k and we now by ~13k, so we have some new space for preact, I think.

[rojer]

IMHO the current manual appraoch isn't feasible with more developers and requriements coming in

i don't know, i don't fee particular strain on the framework (or lack thereof) at the moment. so it' not like things are on fire, i think we can scale current approach for some time still.

that said, i'm not opposed to using a framework of some sort, and i've heard good things about preact in particular. if it can be made to work within the constrains that i explained above, then i'm all for it. but the constraints are what they are, and they are pretty rigid. we can't add flash to devices in the field, we must ensure that whatever we do, we leave enough headroom for future development. thanks to @timoschilling's rcent efforts, we now have a couple extra kb of space. but we need to be careful what we spend it on.

[col-tom]

Can you give a little background to me how all the things work with the local filesystem or is there a good, lightweight documentation about it? Can we increase it?

[timoschilling]

I will update the wiki about the local dev topic. tl;dr: open fs_src/index.html in your browser, input the host name of a shelly and it will work. (master branch must be up to date, feature was merged yesterday)

[timoschilling]

@rojer I think using preact will be a great benefit and will be maybe not const as much in size, while we can drop some of our code and can write more reusable code. I would expect that we came to +3-4k only.

[rojer]

if that's possible and you think will bring benefit - sure, go ahead. i have no upfront objections but the final result must represent a clear improvement over what we have today, in terms of size and/or readability.

[timoschilling]

FTR: I'm working on a preact UI rewrite, preview PR will follow in the next days