machine-as-action is a Node.js utility designed to bridge the gap between 'machines' – a pattern for encapsulating reusable business logic – and standard HTTP/WebSocket request-response cycles. It allows developers to define a machine and then wrap it with `asAction` to automatically handle incoming request parameters as machine inputs and map machine exits to various HTTP response types, including JSON data, rendered views, or redirects. The current stable version is 10.3.1, though recent release notes show significant changes around version 7.x. While there isn't a strict, rapid release cadence apparent from the provided data, updates have been made. Its primary differentiator lies in its deep integration with the 'machine' pattern, providing a structured and convention-over-configuration approach to expose API endpoints, particularly useful in frameworks like Sails.js where machines are a core architectural component. It offers granular control over response status codes and view rendering based on the outcome of a machine's execution, aiming to reduce boilerplate in controller logic.
npm install machine-as-actionVerified import paths — ran on the pinned version, not inferred.
This quickstart demonstrates how to wrap an inline machine with `asAction` and simulate its execution using mock `req` and `res` objects. It covers basic JSON responses and advanced view rendering, illustrating how machine outputs are mapped to HTTP responses.
Ensure all machine definitions adhere strictly to the 'machine' specification, providing `inputs`, `exits`, and a `fn` property.
Review the documentation for `responseType`, `statusCode`, and `viewTemplatePath` options within machine exits. Test existing custom response handling thoroughly after upgrading.
Be aware of the `X-Stub` header for debugging. In production (`process.env.NODE_ENV==='production'`), a warning will be logged instead. If you want to suppress this header even in development, you may need to intercept or modify responses.
Always explicitly define the `responseType` and `statusCode` for non-success exits to ensure predictable HTTP responses, especially for error conditions that should return specific status codes (e.g., 400 Bad Request, 404 Not Found).
Ensure `asAction` is called only once for each machine. Store the result of `asAction` and reuse it, rather than calling `asAction` multiple times with the same input.
Verify that the machine definition object has a `fn` property, and correctly structured `inputs` and `exits` objects as per the machine spec.
If working in a pure ESM project, you might need to use dynamic `import('machine-as-action')` or configure your build system (e.g., Webpack, Rollup) to handle CommonJS modules within an ESM context. This package is primarily CJS.Double-check that the variable holding your machine definition is correctly imported or defined and is a valid object containing a `fn` function.
No dependency data recorded yet.