Use native DomParser instead of opml-to-json dependency

[absidue]

Use native DomParser instead of opml-to-json dependency

Pull Request Type

• Feature Implementation

Description

This pull request replaces the opml-to-json dependency with the native DomParser. I did a similar thing for parsing the RSS feeds, which went down well, so I thought I would do it for the OPML import too.

Screenshots

before:

after:

Testing

1. yarn dev
2. Download the 3 test files (Just a list of all the LTT channels)
3. Before importing each of the the files, click "Remove All Subscriptions / Profiles" in the privacy settings.
4. Import the subscription files, the broken one is intended to fail, this is to test that the error handling works.

opml-testfiles.zip

Desktop

• OS: Windows
• OS Version: 10
• FreeTube version: 0.17.1

[PikachuEXE]

Tested locally

[ChunkyProgrammer]

importing is not working with my subscription list as one of the channels that I am subscribed to has a & in its name (the export needs to escape special characters now, i think).

When using the library, it just ignored this error and was still able to parse it.

[ChunkyProgrammer]

Invidious can also export the subscriptions like this: https://yewtu.be/feed/channel/{CHANNELID} (for yewtu.be as the instance) so it might be worth doing a replace for everything before 'channel/' as well to support the invidious one. This could be done in a different PR if you'd prefer

[absidue]

This should be fixed now.

[absidue]

@ChunkyProgrammer You should now be able to import your subscriptions. XML is very strict but as HTML isn't, I've made it fallback to the HTML parser. That will allow you to import subscriptions that are invalid XML but still valid HTML.

[ChunkyProgrammer]

Would you need to throw another errorNode to get to this catch block?

[absidue]

Not sure, the docs don't mention what happens if it fails to parse HTML https://developer.mozilla.org/en-US/docs/Web/API/DOMParser/parseFromString#error_handling

The HTML parser is too lenient, for the broken file it produced this:

Maybe I should check the error message and only fall back to the HTML parser if the HTML entity error occurs?

[absidue]

Okay, only doing it for a specific error won't work, as Firefox always outputs the same error if the XML is problematic. So checking the error, wouldn't work for the web build.

[ChunkyProgrammer]

Might be good to log the error with the xml and then try to do it with the html dom parser

[absidue]

It'll log the error now before trying to parse it with the HTML parser.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.