Feature: iFrame widget

[Reiss-Cashmore]

Proposed change

This adds a basic iframe component with customisability for height and some other basic iframe parameters. This widget does deviate from the design guidelines. However I think by the very nature of the Widget it is justifiable.

I am not entirely sure my changes within service-helpers.js are really inline with the projects standards and would appreciate feedback. The component communication flow and organisation of HoCs is....not like anything I've ever come across before and is diffuclt to decipher so if I have not done something in the style of the project please point it out and I'll update.

There is unfortunately no decent way of providing fallback content if the iframe fails to load so right now you just get the default browser response.

Closes #
Resolves
#1227

Type of change

• New service widget
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Documentation only
• Other (please explain)

Checklist:

• If adding a service widget or a change that requires it, I have added corresponding documentation changes.
• If adding a new widget I have reviewed the guidelines.
• I have checked that all code style checks pass using pre-commit hooks and linting checks with pnpm lint (see development guidelines).
• If applicable, I have tested my code for new features & regressions on both mobile & desktop devices, using the latest version of major browsers.

[justaCasualCoder]

Looks Awesome!

[Reiss-Cashmore]

Might consider adding some zoom and transform functionality like this afterwards too. Better allow for positioning etc

https://www.w3docs.com/snippets/css/how-to-scale-the-content-of-iframe-element.html

[shamoon]

Thanks for the work. I know it's been requested, but holy cow it's ugly. Are there any use cases where it isn't? Realize that's not your fault, but in general it's not really in line with homepage's POV to support this, we're more about them APIs.

In the meantime, I've noted some code issues, up to you to take care of them now or wait for a final decision about the PR overall.

[Reiss-Cashmore]

Thanks for the work. I know it's been requested, but holy cow it's ugly. Are there any use cases where it isn't? Realize that's not your fault, but in general it's not really in line with homepage's POV to support this, we're more about them APIs.

In the meantime, I've noted some code issues, up to you to take care of them now or wait for a final decision about the PR overall.

Yeah I mean, it definitely can be used in a super ugly way. Personally, my use case is for a DVR/NVR stream. I don't think this looks too bad

You will be able to perfectly size the iframe height to your content through the config when Tailwind implement these:
tailwindlabs/tailwindcss#8261
Or I could implement that workaround in that thread

[Reiss-Cashmore]

Thanks for the work. I know it's been requested, but holy cow it's ugly. Are there any use cases where it isn't? Realize that's not your fault, but in general it's not really in line with homepage's POV to support this, we're more about them APIs.

In the meantime, I've noted some code issues, up to you to take care of them now or wait for a final decision about the PR overall.

I think this kind of illustrates possible other uses for iFrames that can integrate in the theme nicely

https://dashy.to/docs/showcase/#dipans-dash
Lissy93/dashy#777

[Reiss-Cashmore]

Some rounding on the iframe element might help a little? Past that I can only think of maybe an optional subtle drop shadow perhaps? Let me know if you have some specific ideas

[shamoon]

Yea those are cool.

I think it’ll be OK, just want to confer with my associate. We’ve always been pretty strict about styling, but ultimately yea, not much to do about it here. Anyway, I suppose beauty is in the eye of the [self-hosted] beholder...

[shamoon]

Rounding is a good idea yea

[benphelps]

While I personally think this is an anti-feature, I suppose it doesn't hurt anything by existing.

As @shamoon said, our documentation is written in a more natural and less exhaustive style, as, honestly, the more text there is, the higher chances of a tl;dr.

Thanks for the work. I know it's been requested, but holy cow it's ugly. Are there any use cases where it isn't? Realize that's not your fault, but in general it's not really in line with homepage's POV to support this, we're more about them APIs.
In the meantime, I've noted some code issues, up to you to take care of them now or wait for a final decision about the PR overall.

Yeah I mean, it definitely can be used in a super ugly way. Personally, my use case is for a DVR/NVR stream. I don't think this looks too bad

You will be able to perfectly size the iframe height to your content through the config when Tailwind implement these: [tailwindlabs/tailwindcss#8261](https://github.com/tailwindlabs/tailwindcss/discussions/8261) Or I could implement that workaround in that thread

Here the correct solution would be to integrate the NVR directly using an API. I know most ONVIF devices have common endpoints, and we already have a mjpeg stream widget.

I imagine this PR will be followed up by a Discussion/Issue stating that the iframe makes public facing (insecure) requests, and doesn't use the proxy, making this even more of a mess.

[shamoon]

Yes, had that concern and good point, it's probably worth noting that these requests won't be proxied (yes it's obvious if you think about it but...). I do think the built-in browser protections for iframes mitigate the problem somewhat

[Reiss-Cashmore]

While I personally think this is an anti-feature, I suppose it doesn't hurt anything by existing.

As @shamoon said, our documentation is written in a more natural and less exhaustive style, as, honestly, the more text there is, the higher chances of a tl;dr.

Thanks for the work. I know it's been requested, but holy cow it's ugly. Are there any use cases where it isn't? Realize that's not your fault, but in general it's not really in line with homepage's POV to support this, we're more about them APIs.
In the meantime, I've noted some code issues, up to you to take care of them now or wait for a final decision about the PR overall.

Yeah I mean, it definitely can be used in a super ugly way. Personally, my use case is for a DVR/NVR stream. I don't think this looks too bad

You will be able to perfectly size the iframe height to your content through the config when Tailwind implement these: [tailwindlabs/tailwindcss#8261](https://github.com/[tailwindlabs/tailwindcss/discussions/8261](https://github.com/tailwindlabs/tailwindcss/discussions/8261)) Or I could implement that workaround in that thread

Here the correct solution would be to integrate the NVR directly using an API. I know most ONVIF devices have common endpoints, and we already have a mjpeg stream widget.

I imagine this PR will be followed up by a Discussion/Issue stating that the iframe makes public facing (insecure) requests, and doesn't use the proxy, making this even more of a mess.

Not sure I'd go as far as anti-feature but would definitely call it an escape hatch. Which could risk becoming a crutch for users and potentially lead to more issues raised. So maybe a disclaimer is necessary.

My Unifi stuff does output an RTSP stream so yeah totally agree the correct thing to do would be to have something transcoding to output something that could be ingested by mjpeg but I don't fancy building all that for a simple preview on my homepage. So for now, an easy escape is to just use the unifi preview url on a refresh. I have a couple of similar really basic and naive examples like this too.

Here is another example:

Twitch chat provides an embed link for the chat widget. For someone building a streaming focused dashboard for example. I don't think anyone wants to put in the work to integrate with twitch to bring something that they offer in a nice neat package for example. Although I think embeddable panels are on the decline in recent times, there are some custom web dev scenarios I see personally

Will update the docs now too

[shamoon]

Hmm, re the sizes thing, Im not sure how intuitive it is, like its not obvious if a user needs to supply that entire map, and overall I think its just too much. I agree fine-grained control is nice but it's at the cost of simplicity. My inclination would be to use a single value, especially since even with this control it's just never going to perfectly align, I think people will have to accept that.

[shamoon]

Also, please use pre-commit as noted in the guidelines https://gethomepage.dev/v0.7.4/more/development/#code-formatting-with-pre-commit-hooks

[Reiss-Cashmore]

Hmm, re the sizes thing, Im not sure how intuitive it is, like its not obvious if a user needs to supply that entire map, and overall I think its just too much. I agree fine-grained control is nice but it's at the cost of simplicity. My inclination would be to use a single value, especially since even with this control it's just never going to perfectly align, I think people will have to accept that.

You know what, I think you're right.

I have an idea that is even simpler

[Reiss-Cashmore]

Hmm, re the sizes thing, Im not sure how intuitive it is, like its not obvious if a user needs to supply that entire map, and overall I think its just too much. I agree fine-grained control is nice but it's at the cost of simplicity. My inclination would be to use a single value, especially since even with this control it's just never going to perfectly align, I think people will have to accept that.

Let me know what you think of the refactored approach. Simplified to just allow user to specify tailwind classes on the iframe element

[shamoon]

Yea this is better, pared it down even more—K.I.S.!

[shamoon]

Well, here we are. LMK if you have any concerns.

[Reiss-Cashmore]

Looks good to me, I was erring on the side of making w-full and rounded optional just cause you never know what people might need and destyling can be annoying. This will work for my use cases so if you are happy so am I!

[adm2k]

@Reiss-Cashmore

Greetings, Since there currently is no no widget for NUT UPS monitor I am trying to use the iFrame and get it looking close to the others. I have been trying to solve this on my own without success. How can I change the background color of the iFrame widget? I am trying to get to show in the "lighter" slate color - see the UptimeKuma in the photo below. I belive the code is 2A3445.

Since you are the creator of the iFrame widget I was hoping you could answer. Any help is greatly appreciated!

[Reiss-Cashmore]

@Reiss-Cashmore

Greetings, Since there currently is no no widget for NUT UPS monitor I am trying to use the iFrame and get it looking close to the others. I have been trying to solve this on my own without success. How can I change the background color of the iFrame widget? I am trying to get to show in the "lighter" slate color - see the UptimeKuma in the photo below. I belive the code is 2A3445.

Since you are the creator of the iFrame widget I was hoping you could answer. Any help is greatly appreciated!

I'm out at the moment so can't give a full response to this and the other thread I've been tagged in. You want to select the css on the parent container of the iframe. That's what has the theme background in. Which looking at the template, won't be very simple to do. It has generic theme styles applied like bg-theme-200/50 on it which need overriding. Selecting parent CSS from a child is fragile. The iframe itself shouldn't have any background applied as far as I remember.

I did want to make the classes applied more explicit but I don't think that's inline with the conventions of this project as much. They tend to err on the side of uniformity

FYI @shamoon this is the exact sort of reason why I broke out the w-full and rounding classes and made them explicitly overridable. Cause you just never know what people might want to do and destyling this after the fact will lead to people creating really fragile setups likely to break with updates. Should I bring that back and include the container elements classes as an option too?

[adm2k]

Thanks for the response! I am hoping a remedy can be implemented as I suspect it may be awhile before we see a service widget for NUT UPS tools (https://networkupstools.org/). As of now I am just referencing an internal webpage that NUT provides and then using the iFrame widget to display the data. I had to do a bunch of tweaking of the html page to get the four main pieces of data. I am attempting to keep the "look and feel" of other widgets, so getting the iFrame widget to use the background color of A23445 (slate) should solve the issue for me. I can tweak the tables in the html page and adjust the cell colors to match other widgets.

All this could be avoided if we could get a NUT widget :) but that is beyond my capabilities. I know the NUT UPS tool is used by many individual and organizations to monitor their UPS backup batteries etc.

Thank you!!!

[shamoon]

It’s not reasonable to expect that we can satisfy every users’ specific needs, they should be balanced with overall ease-of-use, stability, maintenance etc.

I don’t think there’s anything particularly “fragile” about using CSS to override any styles. Frankly this is kind of an argument against iframe itself, it’s “messier” because we don’t have much control. I’m not actually suggesting we remove it or anything like that but I don’t see any issue leaving the onus for further customization to the user themselves.

also, in general I think folks should really create separate discussions for these separate questions. No one except us maintainers and the PR authors (and anyone subscribed to the PR who likely is not interested in these questions) see these random comments on closed pull requests so asking here means they don’t benefit from any possible wider community input.

[Reiss-Cashmore]

It’s not reasonable to expect that we can satisfy every users’ specific needs, they should be balanced with overall ease-of-use, stability, maintenance etc.

I am in agreement with you 100%! Personally I don't think anything suggested here goes against those principles. It's a very minimal change code wise. Giving the user the ability to control all the classes, optionally, if they choose to. Thus giving them the tools to cater to their own needs. Anyone who doesn't need to, won't need to do any extra config or even worry about the existence of class options.

Maintenance and reliability wise, it is a very minimal penalty. Yes it's a couple of extra lines, granted. But the actual functionality here is literally just passing values along a chain or using a default is nothing provided.

The fragile part, was in reference to the kind of CSS this person will have to write, in order to do something simple like remove the background of the Container. As far as I can tell the below is the only way to do something as simple as remove the Block components background

FYI @adm2k this is probably the piece of CSS you want for now. Replacing "MyServiceName" with the value you set as "id" in your Service config as shown here https://gethomepage.dev/v0.8.0/configs/custom-css-js/

#MyServiceNameID > div > div:nth-child(2) > div {
  background: none;
}

I'm guessing this is pretty obvious why having users write XPath based CSS selectors is not great.
Just incase it isn't that obvious. This is doubly fragile, if the user ever updates their service name / id, this will need updating in their custom styles. Which at worst is annoying. But if a maintainer ever changes the template of the iFrame widget introducing a new div or changes one of the element tags in the chain this will break a users custom style pretty easily.

Alternatively an easy compromise would just be to add id's to the various child elements in the component and pass through the service name into the id so that they are uniquely selectable. This seems to be within the existing conventions of the project, however, I believe by far this is much worse for the "ease-of-use" principle you outlined, versus making all of the styles for both the iFrame and it's container overridable.

I think opening up this configuration and moving the classes to all be overridable would go a long way to making sure the project isn't pestered by future issues about styling the iFrame widget. I don't want the iFrame to become one of those features the maintainers despise because it results in the most "noise" .

[shamoon]

I mean, Im not 100% certain what he's trying to style here but the 'darker' container around the iframe itself has a 'service-block' class, so it would literally just be

#MyServiceNameID .service-block {
    background: none;
}

[Reiss-Cashmore]

I mean, Im not 100% certain what he's trying to style here but the 'darker' container around the iframe itself has a 'service-block' class, so it would literally just be

#MyServiceNameID .service-block {
    background: none;
}

Ahh yep you are right that would be easier. Albeit specificity might start coming into play if they take this too far. I do think some of what I was saying still stands, I made this dicussion so we can move away from the PRs

#2342