okkur / syna

Highly customizable open source theme for Hugo based static websites
https://syna.okkur.org/demo/
Apache License 2.0
250 stars 133 forks source link

Add new repositories fragment #803

Closed mpourismaiel closed 4 years ago

mpourismaiel commented 4 years ago

What this PR does / why we need it: Added new fragment called "repositories". Demo and documentation is available at /fragments/repositories. Currently it only supports Github. I plan to add Bitbucket and Gitlab shortly but adding them would require a simple interface to keep us from writing the template multiple times. Writing the code isn't that hard but I prefer to get approval on the design and how it's currently implemented before I move on.

image

Which issue this PR fixes: fixes #599

Release note:

- repositories: Added new fragment to fetch and display user repositories from Github
mpourismaiel commented 4 years ago

I don't think subitems would be a good idea for this fragment. A whitelist of repositories can be created using a variable, specifying fields is something that is applied on all the cards (I don't think changing the fields per project is a good idea, both design-vise and the confusion that it causes to the end user). Also we can allow a filter function to be written by the user and call that. For example, we write our sort and filter functionality in a helper partials/helpers/repositories_github/fitler.html that returns a filtered list and document how to write new filters. We can keep the sort and count in our code for the sake of simplicity as well.

stp-ip commented 4 years ago

Ok so we keep it simple. Make it the first provider specific fragment. Adding more buttons from the data as follow on.

So default sorting is just by last commit date. We should have at least star count as well. Sidequestion there. Does a fork have the same star count as the main repo? If not, then filtering wouldn't be needed. We would just have star count default sort and it would always bubble up the users personal repos and show the 5 most important or so.

Not sure about what you are imagining on the filter side. Care to elaborate? My first thought was just whitelisting of repos as a list.

Thinking about lists. Any reason to not make the "user" not a list? Also is this better to be called "user" or namespace? It being a list of namespaces for example we could do something like: "okkur, okkur-incubator".

The other option there is to keep it simple and pull in only one namespace/user and the Syna user could always create multiple separate fragments.

mpourismaiel commented 4 years ago

Sorting and filtering is a bit of a problem since we can't get pinned repositories and have to rely on sorting and limiting or filtering (based on a whitelist or "no forks" somehow) and again, limiting with count. We can however extract the code we use to filter repositories into a helper file that receives repos as a parameter and returns the new list. Then any user who wishes to change the list to their liking can override that helper, copy it to their website and update its code.

stp-ip commented 4 years ago

I would leave advanced sorting and filtering for now, but add these points:

Happy to do the whitelist idea in a separate PR. The others I feel are good things to have here already. Thoughts?

mpourismaiel commented 4 years ago

image

@stp-ip Also updated fragment's name and changed forks to display_forks. I think it's more intuitive.

stp-ip commented 4 years ago

Let's do the whitelist and maybe additional buttons in a separate PR.