Closed tqma113 closed 2 years ago
api.setFetcher(fetcjer)
will be ok?
Looks yes. But not functional. :eyes:
api.setFetcher(fetcjer)
or
api.addTodo({/** input data */}, { fetcher: customFetcher })
?
We can follow the principle of functional core, imperative shell
, and ask a question 'Is it fetcher at the core or at the boundary?'
pipeline.use(middleware)
is already dependent on an internal mutable shared state, it let use write many middlewares in a separate way instead of chainable style.
Use functional style in JavaScript/TypeScript is given its cost. We can gain more benefits at the core of our logic to cover the cost.
So, in my opinion, fetcher
is something at the boundary, it will be ok to use imperative style rather than functional style.
Of course, an elegant functional approach solve the same problem perfectly will be the best way.
And api.addTodo({/** input data */}, { fetcher: customFetcher })
is not equal to api.setFetcher(fetcher)
since it only works once.
When people want to add a specific header to a single request(calling), seems that only api.setFetcher(fetcher)
can't do this. Maybe we could support both of them?
Yes, it makes sense.
options.fetcher
> setFetcer(fetcher)
> default fetcher
96 #98
At #98, We can do
const myApiPipeline = createApiPipeline({ fetcher })
. But we ignore another case: code generation at client. In the generated code. the pipeline has been created already, So we still can not custom fetcher at this case.For now, we can pass the
batch
options when calling generated function. Could we add new option to theinvoke
function of api pipeline? Or is there any else way to solve this problem?Expect