Feature: Highlight suggestions

[bdougie]

Type of feature

🍕 Feature

Current behavior

We need to provide things for the user to highlight.

Suggested solution

Can we design the follow

1. button on the contribution list that suggests creating a highlight
2. Pull Request suggestions in a list next to the feed suggesting a highlight.

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Contributing Docs

• I agree to follow this project's Contribution Docs

[getaheaddev]

@bdougie I think I need more details on this.

[Figma File]

[bdougie]

Moved this back to the backlog. Need a better solution for suggesting highlights.

[diivi]

button on the contribution list that suggests creating a highlight

This part means switching the tab to "Highlights" and focusing on the input so it expands. I'm working on this.

Pull Request suggestions in a list next to the feed suggesting a highlight.

How do we get the pull requests that the user created recently? Was this implemented in the backend?

[bdougie]

There is a new UI for this. The API for fetching recent PRs is not implemented.

[Figma]

API

This will need its own tracking issue in the API, but we should be able to grab the most recent PRs (10) and display the ones that do not already have existing highlights associated with them. For now suggestions will be PRs, but we can add issues and milestones in future iterations.

In the future, 1 PR, 1 Issue, and 1 milestone suggestions.

suggested endpoint: /v1/user/highlights/suggestions

[bdougie]

@diivi when you approach this, could you add the new modal as the way to create highlights.

@isa, can you confirm if this [figma] is ready to approach.

[diivi]

Fine by me.

[diivi]

Maybe we should fetch the recent PRs and issues on the frontend itself instead of making an extra endpoint that calls github apis anyway? We call the api for validations in the frontend already.

[bdougie]

Maybe we should fetch the recent PRs and issues on the frontend itself instead of making an extra endpoint that calls github apis anyway? We call the api for validations in the frontend already.

We are using the GitHub api for some of social card generation.

I think that would be fine, we just want to make sure we are checking if the pr or issue is not already highlighted.

[bdougie]

@OgDev-01 just assigned this to you. If you are able to approach it this week, that would be appreciated.

We will need an endpoint to check the suers recently authored PRs and Issues. Suggesting only PRs and Issues that are not already linked to an existing highlight by the user.

[bdougie]

@OgDev-01 just assigned this to you. If you are able to approach it this week, that would be appreciated.

We will need an endpoint to check the suers recently authored PRs and Issues. Suggesting only PRs and Issues that are not already linked to an existing highlight by the user.

Actually. Per slack, @diivi has bandwidth. Let us know if this is possible to be PR'd before Friday.

[diivi]

This is what it looks like with just the elements that we have now.

Once I add the suggested things to highlight, it'll be even longer (maybe making them collapsible can help). Views?

[diivi]

Another point to consider - Modals are the topmost elements in Radix UI (I might be wrong though), so all toasts appear below them (and blurred). So the way we show errors also will have to be changed.

[diivi]

Did some research, I can bring the toast to the top with some hacks. But to make it interactable I'll have to set modal={false} on the Dialog, which will make it loose the background blur, and it looks bad like that.

The alternate solution that I went for is just remove the close icon from the toast for the toasts resulting from this form. The toasts will disappear after a few seconds anyway. Here's what it looks like that way:

@bdougie @OgDev-01

[OgDev-01]

Can you take a look at the edit highlight error message handling and follow that same pattern for this If we have any error message to be displayed to users?.

The toast can remain for only success messages which mostly comes after successful request and dialog is closed

[diivi]

Thanks! Looks better.

[diivi]

About the gap between these two modals:

I can't duplicate this effect even after going through a lot of Radix UI docs. Has this been done somewhere already? Or an alternative that I can try?

[isabensusan]

I think we can do all the same modal then, and just have a good amount of padding between the two sections

[diivi]

When the modal becomes too big:

I could make it scrollable (don't know how yet), but even then it'll look like this (cut off).

What should I do?

[diivi]

Option 2:

[isabensusan]

let's make it scrollable (Option 2)

a couple of comments:

1. please keep the border radius consistent on all corners of the modal (blue arrow)
2. is there a better looking scroll bar available? something more minimal like in this mock? (green arrow)
3. let's keep the suggestions to 3 so that we can try to avoid the scrolling behavior when possible

[open-sauced]

🎉 This issue has been resolved in version 1.65.0-beta.4 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

[open-sauced]

🎉 This issue has been resolved in version 1.65.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀