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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: add a "mark notification as done" button #706

Merged
merged 7 commits into from Feb 6, 2024
Merged

feat: add a "mark notification as done" button #706

merged 7 commits into from Feb 6, 2024

Conversation

adufr
Copy link
Contributor

@adufr adufr commented Jan 18, 2024

Related issues

#500 - feature request: mark notifications as done

Context

Hi! This is my first PR on this repo; let me thank you for making this great app!

As a new user, I instantly found quite frustrating that I wasn't able to mark notifications as done. After doing some digging, I found that GitHub does now provide an endpoint for that 馃帀

Discussion

This PR changes the existing "mark notification as read" icon, to better reflect what it does, and adds a new "mark notification as done" button right next to it:
image

Unfortunately, it looks like GitHub does not provide an endpoint for marking all notifications from a repository as done, so I couldn't add a new button to the Repository component 馃槥

Also, if that's OK with you I'd like to change the "Unsubscribe" button:

  • use the bell-slash icon to match GitHub's icon
  • change its positionning which feels odd in my opinion
image

Let me know what you think about it; I can do that in another PR if you prefer so 馃し

@adufr
Copy link
Contributor Author

adufr commented Jan 18, 2024

Also, on a side note, I have some other ideas for improvements that are now possible thanks to this new API endpoint:

  • add a setting to "mark as done" when clicking a notification (while still keeping the existing setting to "mark as read")
  • someway or another, add the posibility to not hide "read" notifications from Gitify (only hide "done" notifications)

LMK what you think about it, I'd gladly work on that too!

@bmulholland
Copy link
Collaborator

bmulholland commented Jan 18, 2024

Your comments about read vs done are interesting. In my workflow, I generally treat "read" as "done." In your workflow, what's the difference between the two?

Edit: Actually, could you please split that discussion to a new Issue? That will keep this PR focused on a single topic (which already expands into discussions about positioning of icons etc).

@bmulholland
Copy link
Collaborator

bmulholland commented Jan 18, 2024

Re: the changes here -- it seems natural to mirror the Github behaviour and icons. Looks like those don't have a read icon, actually. Opening the entry marks it as read. And I guess Done probably marks it as read + done? Maybe we could match that, which means only two icons. (This also means I support changing the icon to match Github's interface.)

If we do keep all three icons, then in a row as suggested at the bottom of the description looks best to me.

@afonsojramos What do you think?

@bmulholland
Copy link
Collaborator

BTW @adufr -- thanks for the contribution!

@adufr
Copy link
Contributor Author

adufr commented Jan 18, 2024

@bmulholland

Your comments about read vs done are interesting. In my workflow, I generally treat "read" as "done." In your workflow, what's the difference between the two?

Edit: Actually, could you please split that discussion to a new Issue? That will keep this PR focused on a single topic (which already expands into discussions about positioning of icons etc).

Yup I'll open 2 different issues, one for each matter

expect(result.current.isFetching).toBe(false);
});

expect(result.current.notifications.length).toBe(0);
Copy link
Collaborator

Choose a reason for hiding this comment

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

This seems odd. If the request failed, shouldn't the notification list remain untouched, length 1? My read of the code under test is that it doesn't change the notifications list in the failure condition, but maybe I'm wrong.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I agree, tbh I just copy pasted the markNotification tests, so they were already broken before my PR 馃槵

I'm trying to figure out how to initialize a non-empty notifications array with mocked data, but without any success for now...

@setchy
Copy link
Member

setchy commented Jan 18, 2024

Great contribution @adufr.

@bmulholland @adufr your comment above got me thinking....

Opening the entry marks it as read.

Does this mean that the setting Mark as read on click is no longer applicable, perhaps due to a change in GitHub's default behavior when opening an inbox notification?
Screenshot 2024-01-18 at 8 45 46鈥疉M

@bmulholland
Copy link
Collaborator

Does this mean that the setting Mark as read on click is no longer applicable, perhaps due to a change in GitHub's default behavior when opening an inbox notification?

I've only recently picked up contributing here, so I'm not familiar with all the options. I wasn't considering that Setting. It does kinda feel like this read vs done workflow replaces the need for that. But I don't know what people actually use, and I suppose there's lots of possible workflows. We could take an opinionated approach to it but it would require deep consideration and that's beyond the level of effort I'm able to put in.

One easy take is this "mark as done" would replace the "mark as read," though. I honestly don't think most people know or care about the distinction, so having one button for mark as done, no button for mark as read, and keeping the setting seems like a reasonable middle ground.

@setchy
Copy link
Member

setchy commented Jan 18, 2024

From my observations, changing Mark as read on click has no change in behavior within GitHub anymore. From what I can tell, regardless of setting, it is always marked as read.

Is that the same experience you observe?

@adufr
Copy link
Contributor Author

adufr commented Jan 18, 2024

From my observations, changing Mark as read on click has no change in behavior within GitHub anymore. From what I can tell, regardless of setting, it is always marked as read.

Maybe Mark as read on click should be replaced with Mark as done on click then? 馃槄

But the Mark as read button could still be useful in the future; I'm going to open a feature request for a new setting that would allow to "Show read notifications" in Gitify (but hide "done" notifications)

EDIT: see #708 for the new feature request

@bmulholland
Copy link
Collaborator

Re: "Mark as read on click" -- I confirm this has no effect now, Github marks it as read when you open it anyway. We should remove the Setting.

Re: a "mark as done on click" -- When opening the notification, you get a blue bar at the top where you can click Done. That's two clicks, but it's also how Github does it, so maybe good enough?

@adufr
Copy link
Contributor Author

adufr commented Jan 19, 2024

Re: a "mark as done on click" -- When opening the notification, you get a blue bar at the top where you can click Done. That's two clicks, but it's also how Github does it, so maybe good enough?

Why not add the setting anyway? For those who, like me, might be happy to have it?

@bmulholland
Copy link
Collaborator

Why not add the setting anyway?

Sure, especially considering we just removed another setting :)

@adufr
Copy link
Contributor Author

adufr commented Jan 19, 2024

Me again -- do I need to change anything for this PR to be merged?

I'd like to work on other things (such as #714 or #708) that would require some shared functions, and I would prefer avoiding stacked PRs 馃槢

@afonsojramos
Copy link
Member

Well, first of all great contribution @adufr! It sparked quite a lot of discussions so it is not even just about the individual contribution, thank you!

Sorry for coming late to the party, but these past days have been a bit hectic.

One easy take is this "mark as done" would replace the "mark as read," though. I honestly don't think most people know or care about the distinction, so having one button for mark as done, no button for mark as read, and keeping the setting seems like a reasonable middle ground.

Totally agree here! As now we've removed the "mark as read" I'd say that marking it as done on click would definitely be an option I would at least consider enabling to be honest. Everyone has a different workflow, so I'm up for it.

Unfortunately, it looks like GitHub does not provide an endpoint for marking all notifications from a repository as done, so I couldn't add a new button to the Repository component 馃槥

GitHub doesn't, but we probably could I believe... Seems like an easy add to just traverse across all of the repo notifications and mark them as done.

@adufr
Copy link
Contributor Author

adufr commented Jan 19, 2024

Thanks!

GitHub doesn't, but we probably could I believe... Seems like an easy add to just traverse across all of the repo notifications and mark them as done.

Yes I agree, I thought about it! but we should document ourselves about rate-limits just to be safe...

@bmulholland
Copy link
Collaborator

bmulholland commented Jan 22, 2024

Okay, to keep us moving, how about we merge this PR, and agree on next steps (follow up PRs)? Are you cool with that @afonsojramos ? In that case, @adufr , only thing before merge is to get the branch green and conflict-free.

Those follow-on PRs are, I believe:

  1. Make icons consistent with Github, as discussed, and fix their alignment (could be two PRs, for easier/faster review & merge)
  2. Add option to "Mark as done on click"
  3. Replace icon for "mark repo as read" with "mark repo as done." Optionally, deal with rate limits.

Have I missed anything?

@adufr
Copy link
Contributor Author

adufr commented Jan 30, 2024

Hi! Sorry I've been sick as hell for the past week!
I'm finally starting to feel better and so I'm more ready than ever to resume my work on Gitify!

So to clarify, IMO this PR is still valid as-is (I've just updated it with main)
Once this get's merged:

  1. I'll open a PR for the icons consistency
  2. I'll open another PR for the "Mark as done on click" setting

@bmulholland
Copy link
Collaborator

On my end, I'm good to merge this -- even if there's some details wrong, better to keep moving. Just one code thing: what about #706 (comment) ?

@afonsojramos
Copy link
Member

Tests and build fail though. I'd prefer to have that fixed before merging.

@adufr
Copy link
Contributor Author

adufr commented Jan 31, 2024

Sorry it should be good now!

@bmulholland
Copy link
Collaborator

@afonsojramos I missed that, and I agree. Thanks!

Copy link
Collaborator

@bmulholland bmulholland left a comment

Choose a reason for hiding this comment

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

LGTM. @afonsojramos good with you? Go ahead and merge if you're okay with it

Copy link
Member

@afonsojramos afonsojramos left a comment

Choose a reason for hiding this comment

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

Looks good to me! Sorry for the late review!

@afonsojramos afonsojramos merged commit 7c3523e into gitify-app:main Feb 6, 2024
7 checks passed
@setchy setchy added the enhancement New feature or enhancement to existing functionality label Mar 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or enhancement to existing functionality
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants