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: Notebook Node actions #17520

Merged
merged 18 commits into from
Sep 27, 2023
Merged

feat: Notebook Node actions #17520

merged 18 commits into from
Sep 27, 2023

Conversation

benjackwhite
Copy link
Contributor

@benjackwhite benjackwhite commented Sep 19, 2023

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

  • Adds "actions" as a settable property on a notebookNodeLogic
  • Displays them below the node content when hovered / selected

Demo

2023-09-21 13 00 01

TODO

  • Add some logic to make it easier to determine whether it should be shown or not based on whether it already exists somewhere
  • Improve the UX for when it gets shown

👉 Stay up-to-date with PostHog coding conventions for a smoother review.

How did you test this code?

@posthog-bot
Copy link
Contributor

📸 UI snapshots have been updated

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

  • chromium: 0 added, 1 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.

…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
Copy link
Contributor

@daibhin daibhin left a 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 using setX in the component itself. Should we pick one (most likely using setX 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 support resizeable: true only for DataTable nodes but if an insight points to a SavedInsight that resolves to a DataTable 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 the insightLogic 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

@benjackwhite
Copy link
Contributor Author

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

@benjackwhite benjackwhite marked this pull request as ready for review September 26, 2023 15:11
@benjackwhite benjackwhite merged commit 460d814 into master Sep 27, 2023
@benjackwhite benjackwhite deleted the feat/node-buttons branch September 27, 2023 08:05
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