-
Notifications
You must be signed in to change notification settings - Fork 3
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
Add types for jobs #16
Conversation
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'm not particularly opinionated, but my one comment would be that I would intuitively expect to pass a function as a parameter to another to run a task/job. That's the case with setTimeout
, setInterval
, node-schedule
, etc.
Where instead of:
jobs.runNow().flushBatch({ batch: [] })
We'd have:
jobs.runNow(() => flushBatch({ batch: [] }))
// or
jobs.runNow(someJobFunc)
This discussion is completely external to the implementation, so just speaking about what would feel "natural" to me. I do understand we have a tradeoff between feel and the implementation behind the scenes.
And like I said, not very opinionated.
It might feel natural, but like you said yourself, the implementation gets in the way. We have no idea when this function will be run... nor on which server. The only thing we know is that we need to store Within those constraints I'm open to any kind of suggestion or simplification of the API! |
What file is the implementation of this in (in PostHog/plugin-server#325)? |
Ah, so it's PostHog/plugin-server#351 |
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.
Looks like this needs reworking because of jobs API changes PostHog/plugin-server#351 (comment)
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.
Sorry, wrong review, I wanted this to be 🔴 🟥 🙅 RED
Let's try again! |
Here's a plugin using this code: https://github.com/PostHog/session-tracker-plugin/pull/2/files |
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.
Made two suggestions, implemented them in #17
src/types.ts
Outdated
: Record<string, (opts: any) => JobControls> | ||
} | ||
|
||
export type MetaJobsInput<M extends PluginMeta> = { |
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 think this could be called PluginJobs
, which would be more similar to other such types and more obvious?
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.
Good for me
src/types.ts
Outdated
[K in keyof J]: (opts: J[K]) => JobControls | ||
} | ||
|
||
export type CreatePluginMeta<Input extends MetaInput> = PluginMeta & { |
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 is named like a function (starting with a verb) on top of plain PluginMeta
, but if this is the way we'd like devs to use for typing, we should only expose this really. Could we rename this to PluginMeta
and rename the "dumb" base interface to BasePluginMeta
?
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!
Jobs types proposal
This is a WIP that adds types to an experimental syntax for jobs as described here: PostHog/plugin-server#325
The following will work after this is merged:
The
meta.jobs
is fully typed. Thejobs
export unfortunately has to go throughMetaJobsInput<Meta>
when declaring (or it could beMeta['__jobsInput']
perhaps?), as the output ofmeta.jobs
has a different structure than the input.meta.jobs
runs all the jobs via a wrapper likejobs.runIn(30, 'minutes').flushBatch()
....Obviously this should be merged only once we agree on the structure...