fusionjs / fusion-plugin-rpc Goto Github PK
View Code? Open in Web Editor NEWMigrated to https://github.com/fusionjs/fusionjs
License: MIT License
Migrated to https://github.com/fusionjs/fusionjs
License: MIT License
Documentation regarding Fusion API is out of date given recent changes to leverage new Dependency Injection architecture.
Update documentation
It can be useful to mock handlers when writing unit tests, both in the browser and server.
Bug
fusion-plugin-rpc
should integrate better with routePrefix
. The standard way of handling routePrefix
is to provide a fetch
implementation that automatically appends the prefix.
fusion-plugin-rpc
prepends the routePrefix to its calls to fetch
, which results in a double route prefix url.
fusion-plugin-rpc
should call fetch without prepending the route prefix.
The handler API should take ctx
as a second argument. For example:
app.plugin(RPC, {handlers: {getUser: (args, ctx) => ''}});
We don't need to have special code ensuring rpc handlers are
not registered in the browser since we don't allow for extraneous
config registration.
Parts of the readme remain out of date.
Update README.md
The current API of rpc handlers has users return a Promise that resolves to a response for the rpc request. If the promise rejects, the plugin will use the properties on the error (other than the stack trace) as the response. This causes issues however when a handler allows an error to bubble from a library. The bubbled error will be used for the response, and can contain information the user may not want in the response, such as leaked information from the request.
To resolve this, we should enforce that endpoints have explicit error handling that describes exactly the data they want to respond with. We can do this by ignoring the data in rejection errors unless they come from a special error subclass ResponseError
which will be provided by the rpc plugin.
Example RPC Handler
import {ResponseError} from 'fusion-plugin-rpc';
function testHandler(args, ctx) {
try {
doThing();
} catch (e) {
throw new ResponseError('Failed to do thing', { custom: 'metadata' });
}
}
// Responds with
{
status: 'failure'
data: {
message: 'Failed to do thing',
meta: {
custom: 'metadata',
},
}
}
If a normal error is thrown, the plugin will log a warning and respond with an unknown error message.
HTTP status codes don't translate nicely to the web rpc pattern. We currently send a 400 status code on RPC failure, however this doesn't really make any sense. From the RPC framework perspective, the request succeeded. We could potentially send some error status code for serialization / deserialization errors, but apart from that I think we should simply default to a 200 status code, and allow the user to override it via the ctx
argument passed to the rpc handler.
Thoughts?
Source code currently lacks Flow types. As a widely used plugin, it could benefit from static checking.
Implement Flow types
Instantiation of a plugin may not always be best served by being synchronous.
Allow createPlugin and it's associated methods to be asynchronous.
Unhelpful error message.
fusion-plugin-rpc/src/server.js
Lines 150 to 152 in 72c38fb
Feature request
At the moment, the aforementioned error message is unclear. Adding a little more info won't hurt.
The first thought that came to my mind when I saw the message was that I would need to extract ResponseError
from the original thrown error message.
message: "UnknownError - Use ResponseError for more detailed error messages"
message: "UnknownError - Use ResponseError from fusion-plugin-rpc (or fusion-plugin-rpc-redux-react if you are using React) package for more detailed error messages"
fusion-plugin-rpc version: 2.3.0
Node.js version (node --version
): 8.11.3
npm version (npm --version
): 5.6.0
Operating System: macOS 10.14.3
Plugins developed by the FusionJS team should provide a consistent interface for obtaining a request-scoped service instance, as described here: fusionjs/fusion-core#72 (comment)
Rationale:
A consistent interface reduces the cognitive load on framework users since it becomes one less thing that requires looking up documentation
Deliverable:
Change the provided interface from (ctx) => T
to {from: (ctx) => T}
The current process for failing an RPC is to return a Promise that rejects. This works fairly well, however it falls a bit short when you want to serialize data with the RPC failure.
It is generally good practice to only instances of an Error
object to Promise.reject()
, and similarly to only throw Error
objects (see https://eslint.org/docs/rules/prefer-promise-reject-errors and https://eslint.org/docs/rules/no-throw-literal). However, lets say you want to signal an RPC failure, and you want to serialize some JSON down to the client. We currently only send the error.message
data to the client, meaning you are very restricted in how you handle errors.
Node has somewhat recently standardized on using Error.code
to signal the type of error (see https://nodejs.org/api/errors.html#errors_error_code). A good first step would be supporting this property on the rejected error.
If error.code is not enough (which I suspect it won't be), we could support serializing arbitrary JSON on the error.meta
key.
Thoughts?
Delete after 2018-02-20
See TODO in server.js
Rationale: Currently, RPC always assume JSON data. Supporting FormData would enable the ability to do file uploads
We need to update the core plugin api to pass null
or undefined
to the Service constructor when a user calls .of()
. Once that is done, we can update our check to check for truthiness rather than ctx.headers.
We currently copy methods from {handlers} onto the RPC service. In the browser, we send down a serialized version of those handlers. While this has a nice API, it has a few problems.
A .request
API is simpler and solves these problems.
There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.
Error type: Preset name not found within published preset config (monorepo:angularmaterial). Note: this is a nested preset so please contact the preset author if you are unable to fix it yourself.
Codebase currently has a copy/pasta type definition for fetch
. Other plugins also have this same copy/pasta.
We can either:
FusionJS
package.fetch
and import the libdef.A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.