Githawk: Unsubscribe to notifications from repo view

[rnystrom]

"..." bar button alert item. Should be "Subscribe" or "Unsubscribe" based on sub status (might require additional GQL info).

[joerocca]

Working on this!
Do we want to handle the "Ignored" state? Or just consider that "Unsubscribed"?

[BasThomas]

I don't think we should silently consider state x as state y. I feel like it would be best to support all three from the start, but am again thinking how that would / could work with the actionsheet.

If we do go the actionsheet route with the three options, I was thinking about one option ("Update subscription state" or similar) that open another sheet with the three options, where this would be a radiobox style thing (but probably use a checkmark for the selected option).

Also, is this subscription state for repo's or issues themselves? It seems like issues have sub/unsub only as far as I can tell on web? And also: do we want to support both? When viewing a repo, add the subscription updater in the "..." there, and add another one to issues/PRs?

[joerocca]

This is subscription state for repos. Yeah, I believe issues is only sub/unsub. Issues/PR sub is issue #351.

_{Sent with GitHawk}

[BasThomas]

Great catch @joerocca - missed they were separated. 👍

[joerocca]

I’m getting this error on the subscription mutation. Not sure if I am missing something or if it is actually a problem with the API like the error is saying. Any ideas?
https://platform.github.community/t/getting-error-on-updatesubscription-mutation/3747

_{Sent with GitHawk}

[joerocca]

So I was getting the error because I was trying to change issue subscriptions haha. This mutation is only for repo subscriptions.

Thoughts on this?
I feel like "Update Subscription" is kind of long. Also, where should this go position wise in the alert controller?

[rnystrom]

I'm not too offended by the double alerts. We have them in IG.

Maybe change it to "Subscriptions..." to imply there is more? Drop the "update".

[joerocca]

So I’m thinking I am going to have to do a fetch on the repo. Currently, you’ll only get the updated content of the repo if you actually do a new search for it. So when pressing a bookmark or a recent search the data could be stale. Recent search is updated if you do a new search, but repo bookmarks aren't. Thoughts?

[rnystrom]

@joerocca sorry I might not be following. We have to do an _additional_ fetch for repo data? That might make sense, since right now each child VC (readme, issues, PRs, code) makes individual requests.

Is this accessible via GraphQL?

[joerocca]

@rnystrom Currently, we inject the RepositoryDetails model into the RepositoryViewController in order to get info like name, owner, hasIssuesEnabled, defaultBranch. With the addition of updating subscriptions, the model will also include viewerCanSubscribe, and viewerSubscription. The problem with this is you only get updated info if you are actually performing a new search because that is the only way new data is actually fetched. When pressing on a repo recent search or a bookmark, the data could possibly be stale if hasIssuesEnabled, defaultBranch, viewerCanSubscribe, viewerSubscription has changed and the RepositoryViewController will show stale data.

In this particular situation, I can update the RepoResult in the FlatCache when changing the subscription obviously, but this doesn't account for changes done outside of GitHawk or if the app is terminated(resulting in FlatCache being cleared). So if I update the subscription, default branch, name, etc on GitHub web I only actually get the the updated data if I am performing a new search for the repo on GitHawk.

I'm proposing we add a fetch for the repo details only when pressing on a repo recent search or a bookmark so that we are always getting the newest data and can accurately display repo details regardless of the steps the user takes to get to the RepositoryViewController.

Hope this makes more sense and sorry for the confusion haha.