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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: show recording button if set #26565

Merged
merged 4 commits into from
Dec 2, 2024

Conversation

daibhin
Copy link
Contributor

@daibhin daibhin commented Dec 2, 2024

Problem

Follow up to PostHog/posthog-js#1571

Changes

  • Consolidate all 'View recording' buttons and apply consistent logic
  • Add new maybeHasRecording function that looks at the $recording_status property

@daibhin daibhin mentioned this pull request Dec 2, 2024
Copy link
Contributor

github-actions bot commented Dec 2, 2024

Size Change: 0 B

Total Size: 1.11 MB

ℹ️ View Unchanged
Filename Size
frontend/dist/toolbar.js 1.11 MB

compressed-size-action

@posthog-bot
Copy link
Contributor

📸 UI snapshots have been updated

2 snapshot changes in total. 0 added, 2 modified, 0 deleted:

  • chromium: 0 added, 2 modified, 0 deleted (diff for shard 1)
  • webkit: 0 added, 0 modified, 0 deleted

Triggered by this commit.

👉 Review this PR's diff of snapshots.

? properties.$recording_status
? properties.$recording_status === 'active'
: true
: false
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
: false
: isSemVerAfter("1.194.0") ? false : true

so.... we need to consider library version here, no?

something like that - with a made up method I don't think exists 🙈

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Do we not get away without it? I was working off the assumption that properties.$recording_status will be undefined for older versions of the SDK. That will fail the second check in the function and hence resolve to true (eg. for all events in a time before we captured $recording_status we assume there might be a recording

Copy link
Member

Choose a reason for hiding this comment

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

ugh... yeah, ok... too many question marks and colons 🫠

    return properties.$session_id
        ? properties.$recording_status
            ? properties.$recording_status === 'active'
            : true
        : false        
        ```

Copy link
Member

Choose a reason for hiding this comment

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

too many for my brain

@@ -38,7 +36,13 @@ export const OverviewTab = (): JSX.Element => {
event ? (
<div className="h-full overflow-auto">
<div className="bg-bg-light p-1 flex justify-end border-b min-h-[42px]">
<ViewSessionButton event={event} />
{mightHaveRecording(event.properties) && (
<ViewRecordingButton
Copy link
Member

Choose a reason for hiding this comment

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

maybe nicer to do this mightHaveRecording check inside the component and set disabledReason on the button

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 didn't want to pass the properties into the component because not ever instance has access to them. Have changed it around so disabledReason is passed in as a prop in the two cases we know the event properties

@daibhin daibhin merged commit c0500aa into master Dec 2, 2024
96 checks passed
@daibhin daibhin deleted the dn-feat/conditional-recording-button branch December 2, 2024 16:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants