hplush / slowreader Goto Github PK

Some pages are rarely used. We should speed-up app starting time by avoiding parsing JS of that pages.

We will use per-page splitting.

• Add page loading page
• Split pages to groups according to how often user will use them together
• Split JS bundle

Don’t just copy-past and focus on simple but obvious cases, try to focus on solutions for real community questions.

We should look for new posts first:

1. In feeds which was not sync last time
2. In Slow feeds
3. In feeds which user likes more
4. In feeds which posts more often

With filters to set popular posts, erc

Add xml:base to link resolution in Atom loader.

Check the same attribute for RSS.

It will be nice to deploy PRs. At least Storybook, performance tests and web UI.

It will be nice to be able to deploy PRs from guests. This is why preview deploy should work without GitHub secrets.

Preview deploy should also use GitHub environment API to add a link for preview (not a comment).

We should have tests for the whole pages with emulating store’s content

• Add Storybook
• Add tool to test light/dark version
• Think about tool to test :hover
• Add sugar to test pages by emulation stores
• Publish Storybook to dist/

Feeds list could be very long. We should help user to solve these problems:

• Do I have any dead (not working anymore) feeds?
• Do I have any feeds which stopped to write?
• What feeds creates more noise?
• What feeds give me more things?
• Find feed by name
• Find feed by some other parameters like slow/fast type, etc
• Share some feed with a friend
• Find feed by category
• Rename category

We also need to add Show feeds with errors link to refresh status page to open feeds page with errors filter.

We will have a complex filters syntax but without docs user will not learn how to use them

I think Discord is now must-go community platform

We should predict feed type (fast/slow) on:

1. Loader type (RSS is more often slow, than social networks)
2. Content type (too many small posts with images only or 1-2 sentences is more often fast content)
3. Text content length

Every post should have Read it later button. After clicking the post will be moved to special “magic” feed in Slow.

When user update filters, we apply them only to new posts.

We need a button on feed’s organize page, which will apply filters to loaded posts.

Maybe we should do it on Logux level

We can have CHANGELOG.md in the project root with special marks for client’s type (add them to CONTRIBUTION.md) and client’s will have a function from core/ to filter records.

We should ask user to report their link somewhere

We should avoid common template and create project-specific file thin ink about real help for users.

It should reflect new developer onboarding. What it should include:

• We use English but don’t afraid to use DeepL
• How to start each component (web server, mobile app)
• Design practices
  • Link to Nano Stores docs
  • Link to Nano Stores I18n
  • Link to Logux
  • All logic in the core, web is just UI
  • All logic in stores, very dump components
• What developer should think about
  • Conflict resolution (not ideas, just avoid broken stage)
  • Clear types
  • Tests
  • Dependencies criteria
    • JS bundle size (recommend tools, tell about .size-limit.json)
    • node_modules size (recommend tools)
    • Choose best not popular (for to search)
  • Log and storage migration
  • Can we move this code to the core? Will other clients will use it too?
  • I18n and RTL.
  • Keyboard UX: think about path, react on keydown.
  • If you change text a lot, you need to change translation ID.
• Popular steps which can be complex
  • What files to change to add new page
• Test strategy (unit tests for core, visual tests for UI, performance and integration tests)
• Folder structure
• Release cycle
• Deploy
• Where ask questions
• How to find next task

What if we added a subscription with rss loader, but then blog’s author changed format to atom.

Also, we need to think about redirects (to update URL in subscription data).

Add golden path tests for core.

We should use real subscriptions and real data.

After clicking on Refresh button, if user has account on the server, client should first wait for synchronized state to not download the same posts 2 times

Animation will make it easier to find next :focus node by peripheral vision.

I like how this animation work in GNOME app, for instance.

In Fast, we should suggest go to Slow (if there are posts there).

If Slow, we should suggest read books.

We can show Refresh button, but only if the last Refresh was >5 minutes ago.

Including the case, when other client was unsubscribed a few time ago

We can run it after log migration (on new version).

It could help with #23 #22 #21 #20

Maybe ActivityPub protocol in general

Users may now be able to read all fast posts.

In this case app will consume more and more disk storage.

We need to add:

• Settings for the number of posts.
• A regular task to remove old posts.

https://en.wikipedia.org/wiki/OPML

Of course, we will use only for RSS-based subscriptions (including semi-RSS like YouTube).

Maybe we should add a selector to export slow/all/fast subscriptions.

And the UI should be unified with #30

In our visual tests system we need tests with left-to-right (Arabic, Hebrew) articles in English (and Arabic, when we have it) UI.

To be sure that everything renders normal.

• We need to show how many MBs was used for preloaded images in cache settings.
• We should have a button to clear all cache

In RSS and Atom (maybe even some universal helper) we need to be sure that link to feed wil be not in <link> tag, but in Link HTTP header

Add browser emulation for the same golden path as in core integration tests

We could add PIN code to access to reader. If user enters one PIN, we will show all subscriptions, on other PIN we will hide some subscription marked by user.

Use case is a police check for illegal feeds on the street.

Blocked by #96

In loader-tests/ we need to create a config with URLs to test loaders on real data.

• Add script file and integration script to project’s package.json. It will use a lot from #96, think about code re-using.
• This script need to read loader-tests/feeds.yml
• Add there dev.to, LiveJournal, Tumblr (some safe-for-work project, ideal the artist with their work), WordPress official blog, other blog engines blogs, some popular blogs you know (Github).
• For each RSS try to find the right loader by calling loader.isMineText(). Show nice error if the loader was not found.
• For found loader call loader.getMineLinksFromText(). Be sure that it returned some posts.
• For URL remove path (https://example.com/news.rss → https://example.com/) and call use methods from core/preview.ts to be sure that reader will find that RSS URL from the home. feeds.yml should have a marker to disable this test for feed.
• Add to docs information about that test and that file.
• Add CI workflow to run that script every day.

We need to define loader and test for JSON feed format.

We should re-use as much code as possible between RSS/Atom/JSON loaders.

https://en.wikipedia.org/wiki/JSON_Feed

Now we are making in-memory tree for the whole page even if we need a small node.

Maybe we should think to use stream parsers to reduce memory consumption.

But, it could slow down the subscription process if different loaders will look for different things in page. Maybe we need more complex API for parser.

Right now filters use simple RegExp and support only simple single filter like filter(param) and not filter(param).

We need to add the proper filter query parser to add support brackets and and/or. Maybe with formal grammar like in twitter-search-query-parser, but we should be careful with JS bundle size.

What we want to support:

1. filter(param) and filter(param)
2. filter(param (with escape\))
3. filter(param) or not (filter(param) and filter(param))

We need a function which will suggest filters based on feed’s posts (not user input).

For instance, if account has a lot of reposts, we can suggest move them to Fast.

We need to be sure, that we cache images not during the feed sync, but also when we receive loaded posts by other client from log sync.

We need to keep lang from loader source to render post’s font correctly (in Unicode some symbols renders differently depends on language).

Atom feed could be not only on single page, but with pagination.

<link rel="next" href="http://www.syfyportal.com/atomFeed.php?page=4"/>

https://www.rfc-editor.org/rfc/rfc5005#section-3

We page PostPage to handle pagination well, so we need just to update loader and add tests.

During parsing posts from RSS/Atom feed we need to parse all images in the text and put to post.media (list of URLs).

We will use them (don’t need to implement, just to understand why we need it):

1. To preload images for offline reading.
2. To render all images in post compact mode in feed.

• Cache media only for slow feeds

We should add a feature to export/import the whole state of app:

• All subscriptions (not only RSS like in #13)
• Last synchronized date
• All unread subscriptions
• Settings
• Subscription meta-info like filters

In UI we should be able to select what parts to export/import.

Maybe we should this UI with #13

It will be nice if we will be able to reproduce user's issue by importing their state to empty project.

We could also suggest exporting the whole log to have 1-1 state replication (and maybe add Import log to app start screen).

• Add reason to */deleted actions to keep them in log
• Add a way to clean too old */deleted actions from log

We should add an integration tests with a lot of data (500+ subscriptions, 10K+ posts, 5K+ posts for current subscription).

Automatic way to check performance is better, but we should also have a way to test performance in sort of Storybook page (we can start from manual check this Storybook page).