Connect funnel persons to the frontend - #4953
Conversation
|
Just a heads up: there's going to be a slight API change here!: #4946 The Oh, and also, we switched to POST because we were getting some "url too long" errors, and since Persons expects the same parameters + 1 extra ( |
390923a to
969e027
Compare
969e027 to
f5c2387
Compare
|
oops give me one sec to fix the bar click before anyone reviews this 😅 edit: we're good now 😄 |
|
ospath module errors :( |
mariusandra
left a comment
There was a problem hiding this comment.
I gave a look through the code, but couldn't really test it. Got this:
Is that because I'm running postgres? Checking on my M1 now, so can't really switch...
I found some things to remark on, but nothing serious... except for the feature flag typo.
Once you check these things, someone other than me should probably give this a final review.
| trendsLogic().actions.loadPeople( | ||
| { id: step.action_id, name: step.name, properties: [], type: step.type }, | ||
| `Persons who completed Step #${stepNumber} - "${step.name}"`, | ||
| '', | ||
| '', | ||
| '', | ||
| true, | ||
| '', | ||
| stepNumber | ||
| ) |
There was a problem hiding this comment.
A nit for now and outside the scope of the PR, but this loadPeople could get a refactor into basically loadPeople(action, options). Having that many '', in a row feels like something could be improved :).
There was a problem hiding this comment.
yeah, I've kind of been able to connect the funnel/trends logics together so I think I'll try to refactor this into the personsModalLogic as originally planned, in a separate PR 😃
| return ( | ||
| <Modal | ||
| title={title} | ||
| title={<b>{title}</b>} |
There was a problem hiding this comment.
I think we should prefer <strong> over <b>, <em> over <i>, etc.
| saveOriginal?: boolean, | ||
| searchTerm?: string | ||
| searchTerm?: string, | ||
| funnel_step?: number |
There was a problem hiding this comment.
It's a bit of a mess in this action, but normally we should stick to camelCase in JS, except when really and directly dealing with responses from API endpoint that follow different conventions.
Here the funnel_step var starts from the action, so it makes sense to use the JS convention I think.
There was a problem hiding this comment.
Yeah, I definitely get confused sometimes when to use camel vs snake case in the frontend because it seems like we use snake case in a lot of places on the frontend so we can pass in params like { funnel_step } instead of { funnel_step: funnelStep }
| ], | ||
| funnelPersonsEnabled: [ | ||
| () => [featureFlagLogic.selectors.featureFlags], | ||
| (featureFlags) => featureFlags[FEATURE_FLAGS.FUNNEL_PERSON_MODAL], |
There was a problem hiding this comment.
Type here, it should be FUNNEL_PERSONS_MODAL (person+"S").
I think we should remove the explicit Record<string, string> type for the FEATURE_FLAGS object, but again outside the scope here :)
|
Tested locally for the API connections, that seems to be working fine 👍 |
|
Anything else I need to update/fix to get this PR in? 😄 |
samwinslow
left a comment
There was a problem hiding this comment.
Code LGTM although I can't run Clickhouse portions locally. Let's just make sure any UI that depends on CH is not shown for Postgres-only installs. Should the selector for funnelPersonsEnabled also check if Clickhouse is supported?
Are there still styling issues after merging master (from a point after #4965 was merged)? I can help resolve those in another PR if so.
I skipped it originally because I thought we could just release that funnel persons feature flag to people who had clickhouse enabled |

Changes
Please describe.
If this affects the frontend, include screenshots.
This PR is just to connect the funnel persons api call from #4883 to the frontend
I still have to fix the filters, which I'll do in a separate PR
note: This only works for clickhouse right now and repeated steps aren't working quite 100% yet because the new funnel query has to be implemented first
Screen.Recording.2021-07-02.at.9.40.44.AM.mov
Checklist