So, Lead & lagging measures are related to WIG itself. Also, we suggest that increasing lead measures will increase lag measure (it's a hypothesis, we don't know for sure). Let's see examples.
Extra articles:
const assert = require('assert'); | |
const ProxyWrapper = require('./proxyWrapper'); | |
describe('ProxyWrapper', function() { | |
describe('#wrap', function() { | |
beforeEach(function() { | |
this.data = { a: 1, b: { c: { d: 2 } }, e: { f: [3, 4] } }; | |
this.wrappedData = ProxyWrapper.wrap(this.data); | |
}); |
So, Lead & lagging measures are related to WIG itself. Also, we suggest that increasing lead measures will increase lag measure (it's a hypothesis, we don't know for sure). Let's see examples.
Extra articles:
// Define custom error enum, | |
pub enum Error { | |
NotFound() | |
// ... and any more errors here | |
} | |
// Make it castable to Rejection | |
impl warp::reject::Reject for Error {} | |
pub async fn handler() -> std::result::Result<impl Reply, Rejection> { |
// As stated by author, you shouldn't use rejection as "return value" for | |
// error, since rejection mostly means "This filter is not capable of handling | |
// this request". So other filters should be tried. | |
// https://github.com/seanmonstar/warp/issues/388#issuecomment-576453485 | |
// | |
// So whatever you return (Ok or Error), it should be a response value. Implementing | |
// that was not obvious, however Warp `3.2` added an approach to solve that. | |
// Operation `map` was added to cast whatever's on the chain into response, and we | |
// can use it to convert our custom error into Reply, not Rejection, to make warp | |
// work properly |