Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

✨ feat(wakatime): new features and fixes #2434

Merged
merged 64 commits into from
Nov 2, 2022
Merged

Conversation

iammola
Copy link
Contributor

@iammola iammola commented Jul 30, 2022

Description

  • Added Pagination to Leaderboards.
  • Added Details to User's Activity Change.
  • Replace user's email with timezone in accessory.
  • Allow use of extension without apiKey in some commands.
  • Fixed Sorting of Recent Projects.
  • Fixed NaN% in activity change.

Checklist

iammola added 30 commits July 24, 2022 06:04
The `page` state will only ever be `undefined` on the first load.

In that case, it uses the active `page` if available and uses `1` otherwise
BREAKING CHANGE: 💥️ The `useSummary` hook returns it's data in a `Types.RouteResponse` object now
@iammola iammola changed the title ✨ feat(wakatime): add pagination to leaderboards ✨ feat(wakatime): new features and fixes Aug 6, 2022
Comment on lines 54 to 58
"preferences": [
{
"name": "apiKey",
"required": true,
"required": false,
"title": "WakaTime API Key",
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since I made this optional, I had to repeat it in the summary and private-leaderboards commands that require it.

I don't know if there's a better way of handling this, because I expected the apiKey preference to be shared across all commands. But adding it to one command doesn't apply it to the others/entire extension.

Copy link
Contributor

@sxn sxn Oct 25, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately there's no current way of defining a per-extension required preference and make it not required for a particular command, so I guess this is the only way to go about it currently.

You can define a per-extension preference, the way you did here, make it required, and then re-define it in a particular command and set it to required: false in that particular command. So your package.json would look like this:

…
  "preferences": [
    {
      "name": "apiKey",
      "required": true,
      "title": "WakaTime API Key",
      "type": "password",
      "description": "Use your WakaTime API key to use your account",
      "placeholder": "Enter your API key from https://wakatime.com/settings"
    }
  ],
  "commands": [
…
    {
      "name": "leaderboard",
      "subtitle": "WakaTime",
      "title": "Show Public Leaderboard",
      "description": "An overview of the public leaderboard. Check your rank against others all around the world.",
      "mode": "view",
      "preferences": [
        {
          "name": "apiKey",
          "description": "Use your WakaTime API key to use your account",
          "type": "password",
          "required": false,
          "title": "WakaTime API Key"
        }
      ]
    },
…

Copy link
Contributor Author

@iammola iammola Oct 27, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This works! My only problem is the user still has to provide the API key for that command as well. It's still better than the way I had it before, because now it's only one other command that asks for it.

Just to be sure, is there a way to set the preference programmatically? I checked but didn't find anything. @sxn

Copy link
Contributor

@sxn sxn Oct 27, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there a way to set the preference programmatically?

Not yet, but it's been requested before, so we may end up looking into it.

the user still has to provide the API key for that command as well

do you mean the fact that the field still appears in preferences for that particular command? or something else?

The current version of the branch works as follows for me:

Screen.Recording.2022-10-27.at.13.21.55.mov

Copy link
Contributor Author

@iammola iammola Oct 27, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's not my direct problem with it, but yeah I'll like for the same API key to be used across the extension and updating in the public leaderboard won't update the extension-wide one.

Its not a critical issue so can you please re-review the changes? Thanks!

@stale
Copy link

stale bot commented Oct 1, 2022

This issue/pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs in the next 7 days to keep our backlog clean. Thanks for your contributions.

@stale stale bot added the wontfix This will not be worked on label Oct 1, 2022
@iammola iammola marked this pull request as ready for review October 1, 2022 06:23
@stale stale bot removed the wontfix This will not be worked on label Oct 1, 2022
@sxn sxn self-assigned this Oct 24, 2022
@iammola iammola requested a review from sxn October 27, 2022 10:53
@sxn sxn merged commit dc6313b into raycast:main Nov 2, 2022
@sxn
Copy link
Contributor

sxn commented Nov 2, 2022

🎉

@raycastbot
Copy link
Collaborator

Published to the Raycast Store:
https://raycast.com/iammola/wakatime

@iammola iammola deleted the wakatime-update branch November 2, 2022 11:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
extension fix / improvement Label for PRs with extension's fix improvements OP is author The OP of the PR is the author of the extension status: awaiting response from dev
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants