Add Nova Scheduling Provider #79
Conversation
| */ | ||
| id: string; | ||
| /** | ||
| * The identifier of the type of code which scheduled the job. Not that this is |
There was a problem hiding this comment.
| * The identifier of the type of code which scheduled the job. Not that this is | |
| * The identifier of the type of code which scheduled the job. Note that this is |
| priority: JobPriority; | ||
| /** | ||
| * The identifier of the type of job. Note that this is not globally | ||
| * unique amongst all instance of a job type. |
There was a problem hiding this comment.
| * unique amongst all instance of a job type. | |
| * unique amongst all instances of a job type. |
| NovaSchedulingProviderProps | ||
| > = ({ children, scheduling }) => { | ||
| return ( | ||
| <NovaSchedulingContext.Provider value={scheduling}> |
There was a problem hiding this comment.
Is it possible to add a default value for scheduling to support hosts which simple needs? We don't have any examples in this PR of how we expect a host to hook this, or a default implementation... :)
| @@ -0,0 +1,25 @@ | |||
| export interface NovaScheduling { | |||
There was a problem hiding this comment.
Take a look at the comments on the other interface files - let's add some inline documentation around what this is and how to use it. At the moment, this is not clear on how a host would fulfill its duty to a component that is using this API.
Without a default implementation, it will also be difficult for component builders to use the API in their development environments - we will need to think through what the simplest path is for someone who wants to support this in Storybook for example...
/**
- Describes the eventing contract that is used to communicate between UI components and their logical parent within a host application.
- Usage: components should create small independent packages that define the events they generate using this contract.
- Logical parents can take a dependency on the event package, and use it to translate the events into appropriate actions within the larger application.
*/
|
|
||
| type IJob<TResult> = (() => Promise<TResult>) | (() => TResult); | ||
|
|
||
| export interface IJobMetaData { |
There was a problem hiding this comment.
It looks like we are currently hiding details of the scheduler API:
What are the reasons for not exposing these, and would we consider exposing them in future?
There was a problem hiding this comment.
The interface should be kept generic to provide scheduling implementation flexibility for consumers.
Operations that aren't currently supported by the API are changing priority and exposing a completion promise. My thought was to keep the API simply at the minimal set of features needed, and then we can add more as required.
|
Should we add scheduling provider in test utils so that it has fully mocked nova environment? |
|
Would be also awesome to add some example component relying scheduling provider to |
Adds a new provider, context, and interfaces for a scheduling service to be exposed as a nova context. This will allow react components to schedule units of work to an app's scheduling services.
The interfaces follow TMP's implementation, with generic string ids to track
scheduledByIdandjobId. The interface allows cancelling the job via the job handle returned from Priorities follow those defined by the Prioritized Task Scheduling API within chrome: https://wicg.github.io/scheduling-apis/#sec-task-priorities.