feature request: simplify render api

[zh99998]

API for render could be much simpler, write data(torrent-id and file index number) in element data-* attribute and then no user javascript required. webtorrent.js select all element

like bootstrap http://getbootstrap.com/javascript/#carousel

api for example

<video data-torrent-id="..." data-torrent-file="1" controls autoplay poster="xxx" src="xxx">
   <!--or <source xxx></sourcce>, for fallback-->
</video>

then when webtorrent.js is load, query [data-torrent-id], add to client, and call renderTo function.

the src or source is for fallback. I don't know it's proper or not. will it start load origin url before webtorrent js load? if so, we could use another name like data-src, after if webtorrent.js loaded and check browser don't support the environment, move them to src or source.

[feross]

This is not a bad idea. 👍

It would certainly make WebTorrent a lot easier to use for basic use-cases. I wonder how complex the code would be. If we can do this in ~100 lines, then I think it's fine to support. Any more than that, and I think that might be a sign this is too much feature-creep to include in the main library.

will it start load origin url before webtorrent js load? if so, we could use another name like data-src

I think data-src will be required in order to prevent http requests from being started. This is certainly the case with <img> tags, but not sure for <video>.

[zh99998]

here is a simple one. I only tested video tag.

    if (WebTorrent.WEBRTC_SUPPORT) {
        // for no webrtc-supported environment, webseed should also works, but I don't know how to do.  #882

        var client = new WebTorrent();
        document.querySelectorAll("[data-torrent]").forEach(function (element) {
            client.add(element.getAttribute('data-torrent'), function (torrent) {
                torrent.files[parseInt(element.getAttribute('data-torrent-file')) || 0]
                        .renderTo(element, {
                            autoplay: element.hasAttribute('autoplay'),
                            controls: element.hasAttribute('controls')
                        })
            });
        });

    } else {
        document.querySelectorAll("video[data-torrent][data-src], video[data-torrent] > source[data-src], audio[data-torrent][data-src], audio[data-torrent] > source[data-src], img[data-torrent][data-src], iframe[data-torrent][data-src]")
                .forEach(function (element) {
                    element.setAttribute('src', element.getAttribute('data-src'));
                });
    }

call example

<video id="trailer_1" controls autoplay
                                   poster="http://i0.wp.com/www.myacg.cc/wp-content/uploads/2016/03/1.jpg?resize=960%2C540"
                                   data-torrent="http://mycard.moe/thdod/videos/thdod_trailer_1.torrent">
                                <source data-src="http://d8.my-card.in/%E6%88%91%E7%9A%84%E5%BD%B1%E7%89%87%2041.mp4"
                                        type="video/mp4">
                                Your browser doesn't support HTML5 video tag.
                            </video>

[feross]

@zh99998 Nice -- this looks reasonable. Do you (or someone else) want to take a stab at sending a PR for this?

[DiegoRBaquero]

Anyone working on a PR for this?

[feross]

@DiegoRBaquero I don't believe anyone's working on this.

[ClassicOldSong]

I don't think this is a good idea. If you want to have this feature, you should work this out with additional scripts. Webtorrent should not implement any dom operations in order to keep the module pure.

[feross]

@ClassicOldSong WebTorrent already touches the DOM if you call torrent.renderTo() or torrent.appendTo(). But thanks for sharing your thoughts on purity. It's worth considering possible tradeoffs if we just go searching through the DOM when the script is loaded. We might ask the user to explicitly opt into this behavior, something like:

<script src="webtorrent.min.js"></script>
<script>
  WebTorrent.initDOM()
</script>

[feross]

https://www.smashingmagazine.com/2017/02/designing-html-apis/

[DiegoRBaquero]

Imho we should create a separate webtorrent repo for the additional functionality. With great functionality.

Maybe webtorrent-render?

[ClassicOldSong]

@DiegoRBaquero I agree. WebTorrent is more of a data fetching tool than a media presenting tool. Also I think most UI designers don't care about where do you get the media from, they just care how the player looks like, and how do users feel. Maybe another library could help extend the functionality of WebTorrent, but WebTorrent itself, doesn't need them.

[Daniel-Abrecht]

Just for fun, I wrote a library which reacts to errors when the browser tries to load a resource, allows to register custom protocol handlers, and falls back to them if the browser fails to load the resource. It currently only works with src= and href= attributes or the fetch api, but not yet with multiple sources. I also made a handler for magnet URIs, using this webtorrent library, which basically works but is still a bit incomplete.

This way, a magnet URI can be used basically everywhere like any other URL.

The project repos:

• https://github.com/Daniel-Abrecht/protocolloadfallbackhandler/
• https://github.com/Daniel-Abrecht/magnet-protocolhandler

Demo: https://jsfiddle.net/fhmqess3/1/

[feross]

@Daniel-Abrecht That's pretty cool, nice work.

[KayleePop]

Here's a PR: #1421

Uses a path instead of an index for files.

[jimmywarting]

maybe close this issue?