What's the difference with just using `<iframe ... />`?

[koenpunt]

I'm trying to understand why anyone would use this library, where they can simply use a plain <iframe />.

What does this library do, apart from wrapping the iframe in a PureComponent, and limiting support to only the defined properties?

[robbestad]

For convenience. You you can wrap it up yourself and do the things this lib does yourself, sure. As with most things. søn. 18. nov. 2018 kl. 14:40 skrev Koen Punt <notifications@github.com>:

I'm trying to understand why anyone would use this library, where they can simply use a plain <iframe />. What does this library do, apart from wrapping the iframe in a PureComponent, and limiting support to only the defined properties? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#38>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABfQp8f46V66JwxxfA0_Mt-EUf_Icf3Gks5uwWNUgaJpZM4Yn8dE> .

-- Mvh, Sven Anders Robbestad https://www.robbestad.com <http://www.robbestad.com/>

[koenpunt]

As with most things.

Of course, but this is becoming absurdly trivial with React 16.6.0, by using React.memo;

export const Iframe = React.memo((props) => React.createElement('iframe', props));

[koenpunt]

Also, if this is for convenience, why not forward all the props to the <iframe />?

[polarathene]

@svenanders You didn't really answer this issue, why did you close it?

This repo has alot of code in place to provide a package for this purpose. How relevant is it these days for users of React 16.6+ that could use the memo approach mentioned above?

Why aren't props forwarded via spread? You have to provide updates when a user mentions a need for attribute support that could otherwise be handled. Perhaps there's a reason for that(or at least was in the past) due to issues users faced when using this package in ways different from most?

For convenience. You you can wrap it up yourself and do the things this lib
does yourself, sure. As with most things.

The README for the repo doesn't explain what those "things" are. Some clarification would be great. I completely understand if there are special use cases or legacy reasons where this package would be a better choice.

[robbestad]

I gave a terse response. I’m not obligated to provide any at all, and to be honest, I regarded the original question as rather hostile. Forwarding the props would be pointless. The repo would be ‘const Iframe = props => <iframe {...props} />’ in that case. There is also not a lot of code in this repo. It’s just enough to provide type hints and it’s tested. This makes it easy to use and requires less testing in the code that consumes the lib. søn. 14. apr. 2019 kl. 07:06 skrev Brennan Kinney <notifications@github.com

: @svenanders <https://github.com/svenanders> You didn't really answer this issue, why did you close it? This repo has alot of code in place to provide a package for this purpose. How relevant is it these days for users of React 16.6+ that could use the memo approach mentioned above? Why aren't props forwarded via spread? You have to provide updates when a user mentions a need for attribute support that could otherwise be handled. Perhaps there's a reason for that(or at least was in the past) due to issues users faced when using this package in ways different from most? For convenience. You you can wrap it up yourself and do the things this lib does yourself, sure. As with most things. The README for the repo doesn't explain what those "things" are. Some clarification would be great. I completely understand if there are special use cases or legacy reasons where this package would be a better choice. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#38 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABfQp6o8G80BTedkfuc_hKcHrGMIjcdVks5vgrdkgaJpZM4Yn8dE> .

-- Mvh, Sven Anders Robbestad http://www.robbestad.com http://twitter.com/#!/svenardocom

[koenpunt]

I regarded the original question as rather hostile.

The only reason why you would think so is because apparently it is true; this library doesn't provide any value over using a normal iframe.

But my question initially was out of interest, I was wondering if I maybe missed a special case.

Marketing this lib in that it has typescript types is not much added value either, given the fact that the html iframe tag already has types.

I think in general this library is misleading for newcomers to the ecosystem, and it could do better in actually explaining what this library does, and how people could go without.

[koenpunt]

And your comment actually emphasizes the fact;

Forwarding the props would be pointless. The repo would be ‘const Iframe = props => <iframe {...props} />’ in that case.

[robbestad]

Right... søn. 14. apr. 2019 kl. 12:44 skrev Koen Punt <notifications@github.com>:

And your comment actually emphasizes the fact; Forwarding the props would be pointless. The repo would be ‘const Iframe = props => <iframe {...props} />’ in that case. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#38 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABfQpwbjbNKblwG2uqUafrbYSNMDVmZtks5vgwaagaJpZM4Yn8dE> .

-- Mvh, Sven Anders Robbestad http://www.robbestad.com http://twitter.com/#!/svenardocom

[robbestad]

I’m sorry you don’t understand the point of this repo.i advise you to avoid it and use something else. I further advise you to spend your time searching out other libs you don’t like or agree with and ask them to provide alternatives.