Huge News!Announcing our $40M Series B led by Abstract Ventures.Learn More →
task-serializer
Advanced tools
task-serializer - npm Package Compare versions
Comparing version 1.0.2 to 1.0.3
| { | ||
| "name": "task-serializer", | ||
| "version": "1.0.2", | ||
| "version": "1.0.3", | ||
| "description": "Serialize tasks/promises for integrated control. Option for limiting number of concurrent tasks.", | ||
@@ -5,0 +5,0 @@ "main": "index.js", |
@@ -11,4 +11,2 @@ copyright 2020 craigphicks ISC license | ||
| All rejected tasks/promises are managed so that they don't throw unhandled rejections. | ||
| The are 4 different classes exported from the module: | ||
@@ -20,30 +18,4 @@ - `AsyncIter` | ||
| Each of those classes has these input functions: | ||
| - `addTask(func,...args)`/`addTask(promise)` to add tasks/promises. | ||
| - `addEnd()` to indicate that no more tasks/promises will be added, thus allowing exit after the pipeline has drained. | ||
| See [Essential Information](#essential-information) for a discussion of their behavior and differences. | ||
| The output interface of each of those classes differ, and are suitable for different usage cases. The following table compares some properties of those classes to help decide which is suitable for a given usage case: | ||
| | property |`AsyncIter`|`NextSymbol`|`WaitAll`|`Callbacks`| | ||
| |-- |-- |-- |-- |-- | | ||
| | read buffered | yes | yes | yes | no | | ||
| | continuous vs. batch |cont | cont | batch | cont | | ||
| | control loop | yes | yes | no | no | | ||
| | select style | no | yes | N/A | N/A | | ||
| where 'property' are as follows: | ||
| - 'read buffered': | ||
| - Whether the class has an internal buffer storing the outcomes of finished tasks/promises until they are read by the consumer. | ||
| - 'continuous vs. batch': | ||
| - Batch indicates either: | ||
| - no consumer read until all tasks/promises have resolved, or until any tak/poromise has rejected (`WaitAll.waitAll`) | ||
| - no consumer read until all tasks/promises have either resolved or rejected (`WaitAll.waitAllSettled`) | ||
| - Continous indicates the internal read buffer is intended to be read by consumers before all taks/promises have resolved/rejected. | ||
| - 'control loop' | ||
| - The output may be easily read in an asynchrous control loop | ||
| - 'select style' | ||
| - The control loop condition informs an output is 'ready' without actually reading it. This style is useful for a top level control loop integrating 'ready' conditions from many unrelated sources. (See [`NextSymbol` usage example](#nextsymbol-usage-example).) | ||
| Read-buffered classes prioritize rejected-values over resolved-values, and pass the rejected-values first whenever both are availabe. The exception to this rule is `WaitAll.waitAllSettled()`, which transforms rejected-values into resolved-values. | ||
| # Usage examples | ||
@@ -53,4 +25,6 @@ | ||
| To make the examples more readable, some shared demo functions for a file `demo.lib` are used, and those [shared functions are listed at the end](#demo-libjs) of the examples. One of those functions is the async function `producer(ts)`. It inputs the tasks by calling `addTask(...)` staggered over time, followed by `addEnd()`. Some of those tasks throw `Errors`, other resolve normally. | ||
| To make the examples more readable some shared function are used. [They are listed at the end](#demo-libjs) of the examples. | ||
| One of those shared functions is the async function `producer()`. It inputs the tasks by calling `install.addTask(...)` staggered over time, followed by `install.addEnd()`. Some of those tasks throw `Errors`, other resolve normally. | ||
| All the below example code is availalable in the `example-usages` subdirectory of the installed node module, e.g., `node_modules/task-serializer/usage-examples`. | ||
@@ -240,4 +214,39 @@ | ||
| ``` | ||
| # Esential Information | ||
| # APIs | ||
| ## Classes share common input functions | ||
| Each of the classes includes these input functions: | ||
| - `addTask(func,...args)`/`addTask(promise)` to add tasks/promises. | ||
| - `addEnd()` to indicate that no more tasks/promises will be added, thus allowing exit after the pipeline has drained. | ||
| ## Class have differing output functions and behavior | ||
| The output interface of each of those classes differ, and are suitable for different usage cases. The following table compares some properties of those classes to help decide which is suitable for a given usage case: | ||
| | property |`AsyncIter`|`NextSymbol`|`WaitAll`|`Callbacks`| | ||
| |-- |-- |-- |-- |-- | | ||
| | read buffered | yes | yes | yes | no | | ||
| | continuous vs. batch |cont | cont | batch | cont | | ||
| | control loop | yes | yes | no | no | | ||
| | select style | no | yes | N/A | N/A | | ||
| where 'property' are as follows: | ||
| - 'read buffered': | ||
| - Whether the class has an internal buffer storing the outcomes of finished tasks/promises until they are read by the consumer. | ||
| - 'continuous vs. batch': | ||
| - Batch indicates either: | ||
| - no consumer read until all tasks/promises have resolved, or until any tak/poromise has rejected (`WaitAll.waitAll`) | ||
| - no consumer read until all tasks/promises have either resolved or rejected (`WaitAll.waitAllSettled`) | ||
| - Continous indicates the internal read buffer is intended to be read by consumers before all taks/promises have resolved/rejected. | ||
| - 'control loop' | ||
| - The output may be easily read in an asynchrous control loop | ||
| - 'select style' | ||
| - The control loop condition informs an output is 'ready' without actually reading it. This style is useful for a top level control loop integrating 'ready' conditions from many unrelated sources. (See [`NextSymbol` usage example](#nextsymbol-usage-example).) | ||
| ## Resolve/Reject handling | ||
| All rejected tasks/promises are managed so that they don't throw unhandled rejections. | ||
| Read-buffered classes prioritize rejected-values over resolved-values, and pass the rejected-values first whenever both are availabe. The exception to this rule is `WaitAll.waitAllSettled()`, which transforms rejected-values into resolved-values. | ||
| ## Terminology | ||
@@ -260,2 +269,3 @@ | ||
| - Task/promise outcome has been read by the consumer. This state might not be reached of reading is abandoned, e.g. due to a rejected-value. | ||
| - The class instance passed through the following milestones, in order: | ||
@@ -271,2 +281,4 @@ - *started-processing* | ||
| # APIs | ||
| ## API shared by all classes | ||
@@ -273,0 +285,0 @@ - `instance=new <Classname>({concurrentTaskLimit=0}={})` |
New alerts
License Policy Violation
LicenseThis package is not allowed per your license policy. Review the package's license to ensure compliance.
Found 1 instance in 1 package
Fixed alerts
License Policy Violation
LicenseThis package is not allowed per your license policy. Review the package's license to ensure compliance.
Found 1 instance in 1 package
Improved metrics
- Total package byte prevSize
- increased by0.39%
58766
- Number of lines in readme file
- increased by3.37%
368
No dependency changes