To be checked, if such visits are counted

https://stackoverflow.com/a/5672936/9902555

To avoid duplicates it should also contain the date

• Should have pages with entry ID: https://contoso.com/123456
• Page should contain previous versions of the entry
• Ideally, you can see the differences between versions, similarly to the below (perhaps with jsdiff or something from this answer):
  
• Main page should contain a list of recently updated entries, separated by date
• Filters to ignore: category change
• Preferred technology: Next.js with static site generation

https://docs.github.com/en/codespaces/managing-your-codespaces/managing-encrypted-secrets-for-your-codespaces#adding-a-secret

Will require changing the variable name to not start with GITHUB

Build should throw an error if unhandled tag is detected. It will trigger an email notification so I can update the settings. Otherwise, the error might go unnoticed.

Alternatively, app can have a category Other tags to store them. Any fixes would go on a best-effort basis

Currently, only 5 commits are loaded on the main page (implemented in #9). Button can be similar to what is currently on the entry page. It should load next 5 commits.

At the end there should be an indication to show that no more entries is available.

Perhaps it can have analytics added to check if someone uses it at all

When loading history, app sends one request per change of the file. As GitHub limits number of requests to 60 (per hour?) it needs to be handled. Possible solutions:

1. Log a Plausible event if quota is exceeded
2. Client-side authentication to get higher quota
3. Caching of requests client-side
4. Using microservice to proxy requests
5. Store the data server-side and pull from there
6. Preload everything during build time (to be checked how long would it take)

Similarly to Roadmap, after clicking it should show more data. Better than in Roadmap, we'll show the content by default.

Ideally it should have the changes highlighted.

There is a site providing similar functionalities: www.roadmapwatch.com

To be checked how we can cooperate

To be checked why and settings to be adjusted

Currently, build log shows the error:

Linting and checking validity of types ..- error ESLint must be installed in order to run during builds: yarn add --dev eslint

Can be generated with PowerShell script performing comparison between two commits (today and today - 7 days)

https://nextjs.org/docs/pages/building-your-application/rendering/static-site-generation not to be used as it's for /pages router

https://nextjs.org/docs/app/building-your-application/data-fetching/fetching

Either to separate paragraph or simply to hyperlink

With this, it can be saved to Pocket

Example name 123456-v0001.json (up to 9999 versions)

https://docs.github.com/en/codespaces/developing-in-codespaces/default-environment-variables-for-your-codespace

Options:

• To be processed in a script (then can be used in other components, not only the website)
• To be added to website (for other components (bots) it'd need the same code to be run twice)

Following #38, main page should display diff if a property has changed

• Add link to BuyMeACoffee or something similar

Perhaps there might be a custom filter to show All (turned off by default). There might be a class names debug, hidden by default.

Ideally, such changes should not be visible on entry page, but that's not a big deal.

Now the changes are visible on the main page but are not visible (to be checked) on entry page. Example: https://github.com/robdy/watcher365.com/blame/main/data/127496.json

Similar to this: wakatime/vscode-wakatime#280

Potential solution: add as an environment variable and then reference in VSCode settings.json

https://github.com/praneshr/react-diff-viewer#text-block-diff-comparison

Now it checks whether pubDate has changed, which is not very useful

app/page.tsx line 27 const response = await octokit.rest.repos.listCommits({
owner,
repo,
path: "data",
});

Example

Or for any other screenshot service

Entry page should contain changes in the top part (currently it only has current text). Changes should be highlighted on word level, not on the letter level.

Removed tags should be on red, added tags on green.

Examples how changes can be displayed in the history:

• Rolled started
• Rollout finished
• Timeline updated
• Text updated (for both title and description)
• Tags updated

Updated and pubDate can be ignored as per #15. To start with, the change description can be added above the diff. Then, diff might be hidden.

Every change to the content is followed by build

Every time a change is generated, bot shuld generate a screenshot of it and post to Twitter. Example ways: https://www.urlbox.io/7-ways-website-screenshots-nodejs-javascript

Potential next phase: tag bot to be notified about specific entry. Or bot can reply to a specific post and therefore people can watch it

Workflow for bot:

1. Upload to Imgur and return the URL
2. Post to Twitter and attach the image

• Test puppeteer in headless mode
• Try pupeteer in Azure Function (https://www.browserless.io/ or https://testingbot.com/ as per this answer or pptr.io)
• try IFTTT Pro plan for posting to Twitter
• explore https://pikwy.com/pricing as a cheap way to screenshot the page

N to be set to 5, for example

Possibly because of #60 but to be checked. Data on entry history is displayed correctly

For example: title and the entire current version

• When building on Vercel, the data folder is mot included

From GitHub

Risk: at some point we might hit rate limiting from GitHub
Perhaps there's a way to log the remaining number of requests and monitor it via build logs

From local .json files

Requires maintaining separate script to manage files

From local files using git client

To be tested
https://github.com/nodegit/nodegit

For example: new-only, updated

https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/React_interactivity_filtering_conditional_rendering

https://nextjs.org/docs/app/api-reference/functions/use-search-params

To be checked how it works with SSG that is now implemented in #71

https://web.dev/virtualize-long-lists-react-window/

Groups:

• Release status
• Release phase
• Cloud instance
• Platform
• Product

• Update GitHub action