-
-
Notifications
You must be signed in to change notification settings - Fork 27
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
Add an autosplitter badge #674
Conversation
Adds a badge to runs that were performed using an autosplitter.
I believe using the auto splitter settings is potentially going to cause false positives and false negatives. You may reuse the same splits for a different game and the settings might not get cleared out. And you may use an auto splitter that doesn't have settings. |
Hm, is there any better way of detecting autosplitters? |
Not really. But detecting the auto splitter settings should work in a lot of cases. |
app/views/runs/_timing_badge.slim
Outdated
href=run_path(run, params.permit(:compare).merge(timing: 'game')) | ||
v-tippy=true | ||
:title='"Recorded in realtime & gametime—click to switch"' |
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.
I believe if you don't put the colon before the attribute you won't have to double wrap the strings. From my understanding the colon tells view to interpret it as JS first.
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.
Could have sworn title
was a special case with this, but now that I try it it works fine and I can't find anything in the docs about it not working. ¯_(ツ)_/¯
@CryZe Alright, I'll go ahead and merge this and accept that there will be some false positives/negatives. Seems like the common case should be fine, but I'll keep an ear out and remove if it's causing too much confusion. Thanks for the input! |
Adds a badge to runs that were performed using an autosplitter:
I had trouble with the tooltip even after hard loads, so I dove a bit into solving them globally -- now that our whole site is in a Vue app container, even if we're not using Vue in a given place we can still take advantage of the Vue tippy tooltips, which show consistently regardless of soft/hard loads, so I moved the surrounding tooltips over to that style.