The v_ferry_client from vlabs-development

v_ferry_client's Introduction

TODO: Put a short description of the package here that helps potential users know whether this package might be useful for them.

Features

TODO: List what your package can do. Maybe include images, gifs, or videos.

Getting started

TODO: List prerequisites and provide or point to information on how to start using the package.

Usage

TODO: Include short and useful examples for package users. Add longer examples to /example folder.

const like = 'sample';

Additional information

TODO: Tell users more about the package: where to find more information, how to contribute to the package, how to file issues, what response they can expect from the package authors, and more.

v_ferry_client's People

Contributors

Watchers

v_ferry_client's Issues

Logging

Right now there is no logging, only built in print calls.

Possible solutions:

add a new logger package as dependency and handle logging internally
add a new logger package as dependency, and require a logger instance in constructor to be used for logging
add a simple void Function(String message /* and maybe a logLevel */) required constructor param, and the call-site implements the logging

onError handling

Right now there is only an ErrorLink added to the link tree, but it is pretty empty.

Possible solutions:

add an optional ErrorLink to the FerryClient constructor and use that
add an optional onGraphQLError and onException which are parameters of the ErrorLink (this way the gql_error_link does not have to be a dependecy of the package user project)
- here we could decide how much control do we want, since if if these handlers return null then nothing extra happens, but if they return some other Response then the original request's response is "overridden" with the new response. I would vote for not altering the result (so the on... methods should return void, and internally it should return null), but there might be a sensible reason to do so 🤷‍♂️

Recommend Projects