As the developer's first social platform, github has countless outstanding open source projects that bring great convenience to work and study. Projects that you need or love are just a click away from Star.
Star is easy, but with stars repositories growing and passing, it's hard to remember what it takes to use a project. Github provides only a simple search, find the target star repositorie actually has become a minor troublesome thing.
So having your own github stars repositories manager is a must-have for developers.
Previously used github stars repositories manager on the market, such as Astral, although it can be used, but always feel awkward, not easy to use.
Gitstars was born. 🎉
Pure front-end implementation, no server and database, your github is everything.
Github stars repositories manager, which every developer owns.
Welcome to https://monine.github.io/gitstars/ to enjoy the fun, more welcome to provide advice in the Issues after the experience.
Thanks to imsun for get access token service
Extensive use of Flex layout, so please do not use on IE.
The project release version using Vue development, source dev branch. There is also a React development version, source in react-dev branch, just for practice.
Welcome to read the source code, make comments.
Interface style mimics Astral, support Chinese and English switch.
You may be curious, there is no database, where is the tag management data stored? Please see below:
When you first visit gitstars, a gist project with the file gitstars.json will be created within your github gists (There are two on the map because the development needs, as a user, you will only have one).
All your tag management data is stored in the gitstars.json file, meaning that all your tag management operations are modifying the file, no database, everything on github and yours.
However, every time you use the github API to get the management data relatively slowly, and the data you get from the github API has a 60-second cache (check the Response Header Cache-Control field). Which means you refresh the page after you've modified the management data will find that the data is still before the amendment, for which I have e-mail asking github how to cancel the cache, the reply is unable to cancel ...
So in order to solve the experiential problem here, it reminds me of an optimization that should be done without the above problem:
Synchronize management data in localStorage
This is necessary, gitstars not only did, and also done a perfect exception / error rollback processing, which you do not need to care about. Not only your management data, and also some other immutable data will be stored in the localStorage as well, avoiding getting the content from the github API each time it is opened, which also speeds up page content loading.
Synchronization of management data stored in localStorage can cause a problem: Multi-client data is not synchronized
So for the data to be correct, must obtain the data remotely from each visit to gitstars and then compare it with the local data. Lastly, change the time value, updating the local data to the remote data only if the remote data time value is greater than the local time value.
MIT