-
Notifications
You must be signed in to change notification settings - Fork 164
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
[#1894] Add embeddable ramp widget #1988
[#1894] Add embeddable ramp widget #1988
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your work on this @MarcusTXK! The structure looks great, just found some small issues/bugs
- Currently clicking on the "view breakdown of commits" (the button that will usually open the commits panel on the report), the user is redirected to the report itself (with commits panel not open). I was wondering if it would be better to open the corresponding commits panel on the report as well?
- Similarly, if granularity is set to "week" and the user clicks on the ramp, ordinarily on the report it opens the corresponding commit in the commits panel, but in the widget it does nothing. I think it would be good to minimally redirect to the report, and preferably open the corresponding commit like it does in the original report
- Currently the widget renders any errors in the summary panel, could this be removed in widget view?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @MarcusTXK, thanks for working on this PR!
On some initial testing, I noticed a few things to address:
-
The copy to clipboard function works on
localhost:8080
but not on the IP addresses (eg.http://0.0.0.0:8080/
). I don't know what the issue is here, but can you take a look to ensure it works in production? -
The tooltips on hover appear outside the viewport of the iframe. This can probably be fixed when resolving Add dynamic positioning support for tooltip #1929. However, the issue is more amplified on the iframes, as there is no way to see what's on the tooltips even after some scrolling.
-
As discussed in class, the embeddable ramp widget has some bugs when tested using the RepoSense backend test report data. Please take a look, thanks!
This is the code to the iframe I used, which is supposed to be the first summary chart on the report:
<iframe src="http://localhost:8080/#/widget/?search=&sort=groupTitle%20dsc&sortWithin=title&since=2018-03-01&timeframe=commit&mergegroup=&groupSelect=groupByRepos&breakdown=false&chartGroupIndex=0&chartIndex=0" frameBorder="0" width="800px" height="104px"></iframe>
Instead of just that one chart, the first summary chart in each of the repo is included in the iframe.
Thanks a lot for the feedback, I have addressed all of them below.
Thanks for noticing this! I have fixed this as well as breakdown filetypes (that I realised was not hidden as well)
I tried implementing this logic, however after spending quite awhile, I realized that it requires quite a bit of changing the code in order to render the URL for I think a simple workaround for now would be for the user to open the tab first, and then copy the iframe, if the user wants the page to be redirected to the report with their tab open. If we are to add logic for this, I feel it should be in a seperate PR as part of a further enhancement of the widget feature, as the non-trival refactoring needed will make this PR more confusing (as the current one already involves a degree of refactoring).
Good catch for this! For now, I have updated the logic to redirect to the report for ramps that are of granularity "week". I think this functionality can be added together with the one above in a separate PR, for the same reasons of adding even more complexity to this PR.
This was an interesting issue to solve. It turns out that
Yes, I agree that this is an issue, but I feel that this is best fixed in a separate PR. Perhaps in widget mode I could temporarily disable tooltips until this is fixed.
Thanks for noticing this bug, I did not notice this as the reports I tested it on were smaller. I have fixed this issue. Additionally, @ckcherry23 brought up a good idea during our CS3281 meeting to add feedback to the user when the copy button is clicked, so I have modified the tooltip to now show "Copied iframe" upon clicking of the copy button, for 2 seconds, before it reverts back to its original text. |
@HCY123902 Thanks for the feedback, Ive updated the icon to redirect the user to the RepoSense Report |
…b.com/MarcusTXK/RepoSense into 1894-add-embeddable-ramp-widget-split
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @MarcusTXK, the embedded iframe with the title looks cleaner and almost ready. I noticed a few more issues:
-
There is a tooltip for the 'number of lines' shown beside the title (for both
group by author
andgroup by repo
). Can you disable this tooltip as well for widget mode? -
It doesn't seem like the copy iframe feature works for ramp charts when using the
None
option forgroup by
. I am not sure if you intended this, but I think we should allow embedding ramps even when using theNone
option. Can you recheck or clarify this?
@ckcherry23 Thanks for helping to take a look, appreciate your help!
Thanks for spotting this, I have hidden it for widget mode.
This was an accidental bug introduced with the inclusion of title for single charts, and the title being undefined for |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
v-on:click="handleMergeGroup(getGroupName(repo))" | ||
) | ||
.tooltip | ||
font-awesome-icon.icon-button(:icon="['fas', 'chevron-up']") | ||
span.tooltip-text Click to merge group | ||
a( | ||
v-if="isGroupMerged(getGroupName(repo))", | ||
v-if="isGroupMerged(getGroupName(repo)) && !isChartGroupWidgetMode", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MarcusTXK is it possible to group these repeated checks to a higher level? I know this is how it is currently done but we can look into how to reorganise to reduce repeated codes like this one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I definitely agree it would be great if we could refactor these repeated individual checks into a common one, though I unfortunately cant think of a clean way to do it at the moment.
Lets explore how to refactor the frontend for this as well as other similar instances in a future issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
The following links are for previewing this pull request:
|
Fixes #1894
Proposed commit message
Other information
Screenshots
RepoSense Report
Embedded Group Ramp (Unmerged)
Embedded Group Ramp (Merged)
Embedded Single Ramps
The height of the iframe are calculated based on
the number of charts in the iframe * chart height + title (if present)
such that no scrolling of the iframe is required when viewing it. The width is set to an arbitrary value of800
. These dimensions can be edited by the user in the iframe should they prefer other values.Tested the iframes on the following html file (green bg to see the widget margins better) :
Design Decisions
Why iframes?
For embeddable widgets I initially considered two options, the first being standard Web Components that can be embedded in any HTML or iframes.
I ultimately decided to use iframes as using standard Web Components required prebuilding of the components and for users to add two items, a link in the head for css and a script in the body for the widget source, which is troublesome for the user. Iframes on the otherhand can be directly embedded in the body of any html file with no hassle.
Reuse of
c-summary-charts.vue
I initially intended to create a seperate widget component, however this has the drawback of being hard to maintain as if the summary chart is updated, the widget would have to be updated separately. Since
c-summary-charts.vue
renders the charts in a double for loop, I realized that we can easily reuse it but filter out non relevant elements and only render the specified charts. This can be thought of as a matrix, where we access the required row or required element directly by keeping track of indexes. This is done via the url parameterschartGroupIndex
andchartIndex
.Overall
This are the main changes:
c-home
andc-widget
inapp.vue
. The common logic are passed down as props to the respective pages.router-view
rendersc-home
orc-widget
depending on if the routing is/
or/#/widget
.c-summary
does not render thesummary-picker
ifisWidgetMode
prop is passed in, and now passes inchartGroupIndex
andchartIndex
toc-summary-charts
which only renders the specified indexes.c-summary-chart
conditionally renders certain buttons, depending on if it is currently a widget (which is determined by ifchartGroupIndex
andchartIndex
are passed present).summary-chart.scss
This must be merged after #1974.
Note: I am merging into a branch with the same code as #1974 to make it easier for review. Once #1974 is merged in I will change it back to merging into master
tl;dr
Common logic moved into
app
,app
renders eitherc-home
orc-widget
and passes in common logic as props.c-widget
rendersc-summary
with some extra props.Edit: Documented bugs: