-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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: Notebook Node actions #17520
feat: Notebook Node actions #17520
Conversation
📸 UI snapshots have been updated1 snapshot changes in total. 0 added, 1 modified, 0 deleted:
Triggered by this commit. |
…eat/node-buttons # Conflicts: # frontend/__snapshots__/scenes-app-recordings--recordings-play-list-no-pinned-recordings.png
# Conflicts: # frontend/src/scenes/notebooks/Nodes/NodeWrapper.tsx # frontend/src/scenes/notebooks/Nodes/NotebookNodeFlag.tsx # frontend/src/scenes/notebooks/Nodes/NotebookNodePerson.tsx # frontend/src/scenes/notebooks/Nodes/NotebookNodeSurvey.tsx
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 largely agree with the direction here. Didn't do a full review because I know it's still a draft but my main top of minds are:
-
We almost always rely on a logic e.g. when rendering the title, component and now actions. It probably makes sense for setting these kinds of things to live in the component so we can access that logic and not have to do nasty things like
findMounted
elsewhere. -
It feels like we're kind of split right now between setting things in
createPostHogWidgetNode
and usingsetX
in the component itself. Should we pick one (most likely usingsetX
in the component) and try to move everything there or allow both which could be confusing. In my opinion, anything that relies on the node attributes should probably live in the component because they'll most likely need more context e.g. for the Query node we should currently supportresizeable: true
only forDataTable
nodes but if an insight points to aSavedInsight
that resolves to aDataTable
it will not be resizeable: https://github.com/PostHog/posthog/blob/master/frontend/src/scenes/notebooks/Nodes/NotebookNodeQuery.tsx#L191. If we had access to theinsightLogic
in the component we could set this parameter there instead. -
Settings might be the only exception to the above because they are actually not rendered inside the component. They do however just get set on the nodeLogic.... so maybe we could do something like
const { setWidgets } = useActions(nodeLogic)
useEffect(() => {
setWidgets([{ key: 'settings', Component: Settings }])
}, [])
and keep everything consistent
- Do we risk the component getting too messy if everything is being set / changed inside it? Maybe a declarative approach could be interesting to explore, I really liked that when building the Raycast extension so could be a fruitful source of inspiration. An example could be:
<NotebookNode>
<NotebookNode.Box>
{/* Normal content goes in here */}
</NotebookNode.Box>
<NotebookNode.Actions>
<NotebookNode.Action
icon={<IconFlag />}
text="Show implementation"
onClick={() => {
if (nextNode?.type.name !== NotebookNodeType.FeatureFlagCodeExample) {
insertAfter(buildCodeExampleContent(id))
}
}}
/>
{survey.linked_flag && (
<NotebookNode.Action
text="View linked flag"
onClick={() => {
if (nextNode?.type.name !== NotebookNodeType.FeatureFlag) {
insertAfter(buildFlagContent((survey.linked_flag as FeatureFlagBasicType).id))
}
}}
/>
)}
</NotebookNode.Actions>
</NotebookNode>
Ultimately nothing here is blocking and more just me trying to drop as much context / ideas as I can. Certainly good enough to go with for now in my opinion given how easy it'd be to change down the line
Yeah I think we're due an API review to look at the concepts we have and what we've learned to pull it around a common approach. The nested components idea is a good one. How we actually build it - no idea. But worth exploring. I'll probably move forward with this as is and then follow up to tidy and perhaps reduce some of the options |
Problem
@neilkakkar kicked off great stuff with having contextual actions to add sibling nodes relevant to the selected one.
This is the follow up to make it a "native" part of nodes, with some hopefully nicer UX/DX.
Changes
Demo
TODO
👉 Stay up-to-date with PostHog coding conventions for a smoother review.
How did you test this code?