-
Notifications
You must be signed in to change notification settings - Fork 129
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: allow regex patterns and wildcards in survey url #805
Conversation
window.location = originalWindowLocation | ||
|
||
// eslint-disable-next-line compat/compat | ||
window.location = new URL('https://example.com?name=something') |
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.
nice!
With the regex and wildcard options, can we move this into a separate test that specifically deals with URL matching so that this one it
line isn't handling too many things now? 🤠
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.
Yes definitely!
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.
@liyiy should the url matching function be moved to a util? Would it be useful in other areas for comparing a url condition with the current href?
src/posthog-surveys.ts
Outdated
@@ -27,6 +28,23 @@ export class PostHogSurveys { | |||
} | |||
} | |||
|
|||
getMatchingUrl(url?: string): boolean { |
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 this will actually require a version update for users in order for it to work for them? @neilkakkar
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.
Yes
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'd recommend making this helper pure, i.e pass in URL and regex to match. Makes it easier to test, and remove reference to window.location.href
from this function
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.
Sounds good! Does it make sense for that helper to be in utils.ts
rather than a class method? At that point it would be a simple regex test of an argument url and pattern.
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.
Yep good call
src/posthog-surveys.ts
Outdated
if (!url) return true | ||
|
||
// If the url string starts and ends with / it is meant to be a regular expression | ||
if (url.startsWith('/') && url.endsWith('/')) { |
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.
not a big fan of this implicit matching, because if someone wanted to test for /test/
, we'll end up matching /test
as well. Not too big a deal, but indeed as you say there's an education component involved.
I think we can make this more explicit perhaps, have a toggle with the url field that mentions whether it's a regex or not, so users don't have to worry about adding custom /
to the front and back, which will get removed (very confusing as the end user). And just input a clear regex when they select the isRegex checkbox.
So in posthog-js, that would mean you have a second parameter telling you whether it's a regex or not.
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.
@neilkakkar Thank you for the feedback! Would that turn the conditions type into conditions: { url?: string; selector?: string; seenSurveyWaitPeriodInDays?: number, isRegex?: boolean } | null
? I wouldn't want to introduce any breaking changes on the url type, but having the isRegex boolean in the conditions object could make it seem like it also applies to the selector. On the other hand, since the checkbox would be controlled within posthog, that might be ok since the user would be explicitly applying it to the url. What do you think?
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 don't love having to introduce another parameter for this especially because this is more like an add on than a requirement to using URLs with surveys, but if we do want to properly support url with regex, I agree it's better to go with a more complete solution.
Instead of a checkbox though, we can make it more like our filters where the user has options to choose whether URL "matches regex" or "contains" the property value, similar to this:
Except it would only be "matches regex" and "contains" for now 😅
And the name of the parameter underneath the hood could be like urlMatchType
where the match type can be "contains" or "regex" or "exact"
That way we can retain more flexibility than just having isRegex
!
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.
It is an extra amount of work though, so feel free to let us know if it is, and the team will be happy to work on it together 😃
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.
Great call, makes more sense 👍
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 like the extra flexibility and matching an existing pattern!
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.
It is an extra amount of work though, so feel free to let us know if it is, and the team will be happy to work on it together 😃
I think I can handle the changes in this code easily enough, but may need help on the posthog side. I have been on vacation, which is why I had such a delay replying to your comments. Is there a goal or timeline for having this change in place or hitting a release date? If so, I might not be able to get the posthog side done fast enough.
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.
It's fine to just complete posthog-js and I'm happy to take up the posthog side of things.
Alongside conditions.url
I'll pass in a conditions.urlMatchType
which currently will be one of regex, exact, contains
which you can match by accordingly.
src/posthog-surveys.ts
Outdated
} | ||
} | ||
// If the url string has a wildcard, convert to a regular expression | ||
if (url.includes('*')) { |
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'd propose removing this magic, and let users use proper regexes if they need regexes.
Surveys is under a feature flag where the key is simply |
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.
This looks good, thanks @Bonitis . The companion PR is here: PostHog/posthog#17738
I just want to run an end-to-end test and see everything works with both PRs before I merge |
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.
Awesome work!!!!
@neilkakkar @liyiy thank you so much for your feedback and guidance in implementing this feature. I'm so excited to see it move forward! |
Hey @Bonitis , thanks for the contribution! I'd love to send you a merch code to posthog for this :) -> send me an email -> neil @ posthog .com Also, to get this merged, I had to create a copy with the right credentials. I've made sure to preserve your commits so it's still attributed to you. |
Changes
Caveats
/
at the beginning and end of the string is a great method for determining whether it is a regex. It requires education for the user to follow that pattern to have their pattern picked up correctly. I would love some feedback on whether that is acceptable.Checklist