Allow adding custom components

[tmigone]

Hi there, I'm the lead developer for https://github.com/balenalabs/balena-sound/.

We have a very rudimentary local ui on the project which was only added as a proof of concept, it let's you manage the device, set dtoverlays and has a volume slider, nothing too fancy so I want to replace it with this awesome device-ui sauce which is basically the same thing but 100x times better, and free of maintenance (at least for me :P). Here is how it looks:

What problem do you want to solve?
I would love to be able to add custom components to handle application specific logic. At the moment the volume slider is the only custom thing we have but I want to add a lot more. Ideally the component gets added to the sidebar and has it's own page.

What do you think is the correct solution to this problem?
I've been talking to @nucleardreamer about this and we discussed a few options.

We talked about the possibility of allowing users to provide their component in a .vue file plus some sort of manifest config file, but that presents a lot of problems like you need to rebuild the vue application, you need to consider what extra npm modules the custom component needs, translations, etc. There might be a way forward with this if you extend the device-ui dockerfile, copy over the files, manually install the modules and use something like this https://github.com/FranckFreiburger/vue3-sfc-loader, but it seems to be very complicated approach and error prone. Also this type of solution would mean anyone wanting to add a custom screen would need to write vue code, which reduces the audience.

So we came up with another idea which is adding custom components via iframes. The user would extend the dockerfile and add a configuration file. This can be json, yaml, whatever. The file would contain basic metadata required to add the component to the sidebar, basically a name and a URL to load. Then the app would read this file and add the necessary custom components on the fly.

There is an additional problem with this approach which is that the page we are rendering via iframes might be using API's internal to the device. This is the case in balenaSound for example. The existing UI uses an API that's provided by the sound-supervisor service. To solve this we could add dynamic routing to the app serving device-ui, some logic that maps requests that come in for instance /audio/volume would be transformed into http://sound-supervisor:3000/audio/volume. The specifics of the mappings involved would also need to be provided via config file described previously.

Are you willing to submit a pull request to implement this change?
Sure! And I bet @nucleardreamer is willing to help :P

[tmigone]

Thought a bit more about the dynamic routing, not sure if it will be needed. Haven't played with iframes in a while but i think if the API's are on the same domain as the UI being served then it won't be needed.

[maggie44]

Hi @tmigone,

Great to have another example of a use case for the UI, it really helps in thinking through design, user interaction and so on.

At the moment adding custom components is done by including the component in the components folder and importing it where you want it. The Wiki has a bit of detail, and some examples: https://github.com/maggie0002/balena-device-ui/wiki. I realise the docs are super lean, really flushing those out is on the list.

I may be a little confused on what it is you are trying to do, but I think I got the general gist. Much of what you are describing is already planned, the aim is for components to be enabled and disabled (visible/hidden) by using a control panel page. In that page users will also be able to move them around on the interface, without having to touch any code (unless they want to). Also a config file at build time to set the initial state.

Most of the challenges you allude to around npm modules and translations are already handled by lazy loading and tree shaking. For example, in the current package.json there is quasar installed. This package contains hundreds of buttons, dials, switches, notifications, bells and whistles, and we use about 2% of them. But having it included in our package.json doesn't mean our final build output has all those hundreds of items compiled, we end up just with the ones we use but trimming the fat at build time.

A bad example is the ApexCharts we currently have installed. That doesn't have the same functionality, we have to import all 18 charts just to display one. Which is why ApexCharts is listed on the project board to be axed and replaced with something else.

Basically, other than for build times which are marginally slower with more packages, we do not have to worry too much at this stage about what npm packages we add in. Similarly, we could add a thousand visual components, but if they are not referenced in the code and if when they are added they are lazy loaded, we don't see a slow down on user interaction (also thanks to chunking). Only downside here, maybe a slight increase in the build size we need to store in our container, but Kbs rather than GBs, and it isn't passed to the browser unless it's needed.

I have oversimplified a little bit here, and there is some other magic we will need to apply, but gives a good idea at least and we could skip the iframes.

Most of what I think you are looking for is in the pipeline, but there is quite a lot of work involved. As soon as we start allowing configuration of the page, we need state management, and then after state management we need database storage, and with database storage we need a database migration strategy to avoid breaking changes, and then, and then, and then. I dumped in to the project board the other week some of the things that would need addressing, it is already at 54, and it excludes time spent for @nucleardreamer and I to sit down and get it all organised. All super possible, and I think massively beneficial, but at this stage I am a little wary of starting the walk down the next road. If we take the first step, it is like throwing a code grenade in to the current repo, and if we are not certain we can get to the end of the road, we may be leaving people worse off than just letting them code it in Vue using this as a basis.

The good news is, there is some talk going on about walking the road, and hopefully we will all hear something soon.

A good win-win in the meantime, would be to commit the components, front- and backend. Then we can either fork the repo and in a few lines of code get a new interface for you with those components. Or if we get to walk the path of more user friendly and customisable, we have the components ready to go that users can select and manipulate from a control panel. That latter solution I envision being as you mentioned, a config file that dictates how the page should look at build, and then you are in a zero-maintaince state for the UI of Balena Sound. And then also allow users who are using the UI for other things, in a few click of a buttons add in the Balena Sound Component Group to their menu bar (drag and drop), install your container, and off to the races.

I haven't looked at the code of Balena Sound, but based on the screenshot you added, it looks like the DAC device tree overlay is an SDK endpoint, I am assuming based on the internet connectivity requirement? If so, then we could add that backend in to the SDK endpoints. It will be valuable to have their for others to use too. And that is @nucleardreamer's code so you have just the guy to help.

The volume slider, is it interacting with the device directly? Would probably make sense to port that code in to a custom endpoint.

Then we just add the individual component for each in to the Quasar frontend components folder. Also a super helpful contribution as others can then use the volume slider and SDK route for their own purposes. I'm sure Quasar will make this all super easy too, there are pre-built sliders ready to go out of the box.

Great to be able to brainstorm. Watch this space.