Fetch GitHub raw files from jsDelivr about emgithub HOT 5 CLOSED

Looks good to me. Thanks and I'll merge #16

from emgithub.

If I'm not wrong, I think you mean two places to use jsDelivr:

• fetched file, by changing const rawFileURL = `https://raw.githubusercontent.com/${user}/${repository}/${branch}/${file}`; in https://github.com/yusanshi/embed-like-gist/blob/master/embed.js#L24. I saw your fork and you had added an option fetchFromJsDelivr. I think fetching from jsDelivr can even be the default, i.e., no need for fetchFromJsDelivr. JsDelivr is reliable and doing this will benefit all users, especially for those in China.
• embed.js, by changing ${window.location.origin}/embed.js... to https://cdn.jsdelivr.net/gh/yusanshi/embed-like-gist@master/embed.js... in https://github.com/yusanshi/embed-like-gist/blob/master/404.html#L264. In this way, the embeding script tag will be <script src="https://cdn.jsdelivr.net/gh/yusanshi/embed-like-gist@master/embed.js?target=..."></script> instead of <script src="https://emgithub.com/embed.js?target=..."></script>. I think this will bring trouble to users following instructions at https://github.com/yusanshi/embed-like-gist#create-your-own-project. Hardencoding serviceProvider is not friendly to them. And their modified embed.js (either in another GitHub repo or local) is not used at all so they must make some changes before deploying them.

In summary, I think the first one is completely OK, you can make a PR (just one line of code, I think, hahaha). The second one is likely a breaking change and we can talk it more.

By the way, as for the second one, I think GitHub Pages is accessible in most networks of China, although slower. If https://emgithub.com/embed.js is accessible without any proxy in China, then only the first change is enough 👀

from emgithub.

Yes, the first point is the internal changes of embed.js, that is exactly what we need to do. But in my opinion, the fetchFromJsDelivr option may be necessary, because jsDelivr always needs time to purge cache when raw file is updated, even if jsDelivr purge cache API is explicitly called by users. I think users need to know the disadvantages of using jsDelivr CDN, maybe we could explain it in the documentation.

The second point I said is what users need to do when copying links from emgithub.com (e.g. paste the link here https://github.com/yusanshi/homepage/blob/f72910bc16f9a706639d836d83aa3cb27a2a7249/_posts/2019-12-17-emgithub.md#L39-L53 in your blog), it is the user’s own Choice, although they will get such a problem. I don't think it’s a good idea to make changes in 404.html too as you said, maybe we can talk about ​how to help users solve this proble.

from emgithub.

I didn't realize the cache issue of jsDelivr and thanks for explaining this. So we can add a checkbox (text: Fetch from jsDelivr, maybe with a little question mark and when hovering on it a helping message is shown), or a dropdown with select tag (Fetch from githubusercontent, jsDelivr)? Anyway it's just a little bit of my opinion. You can choose any implementation you like and I'll appreciate it if you can make a PR for it.

As for the second, maybe adding some text in README? For example, if you are having connection issues with https://emgithub.com/embed.js, you can use a CDN for embed.js. For example, replace https://emgithub.com/embed.js with https://cdn.jsdelivr.net/gh/yusanshi/embed-like-gist@master/embed.js in the JavaScript tag ...
However this will bring the serviceProvider issue and it'll be a little dirty to fix this (e.g. serviceProvider = serviceProvider.includes("cdn") ? "https://emgithub.com" : serviceProvider). I think this can be just put aside. https://emgithub.com/embed.js is basically OK without a proxy from my own experience.

from emgithub.

I have implemented the feature of fetching files from jsDelivr, I tested it on local machine and it works, please check the pull request when you have time.

As for the serviceProvider issue, I agree with you, and there is no change at the moment.

from emgithub.