Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request(farrow-client-api): custom fetcher #142

Closed
tqma113 opened this issue Dec 3, 2021 · 7 comments
Closed

Feature Request(farrow-client-api): custom fetcher #142

tqma113 opened this issue Dec 3, 2021 · 7 comments

Comments

@tqma113
Copy link
Collaborator

tqma113 commented Dec 3, 2021

#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 the invoke function of api pipeline? Or is there any else way to solve this problem?

Expect

// Generated Code
export const api = {
  addTodo: (input: AddTodoInput, options?: ApiInvokeOptions) =>
    apiPipeline.invoke({ type: 'Single', path: ['addTodo'], input }, options) as Promise<AddTodoOutput>,

  removeTodo: (input: RemoveTodoInput, options?: ApiInvokeOptions) =>
    apiPipeline.invoke({ type: 'Single', path: ['removeTodo'], input }, options) as Promise<RemoveTodoOutput>,
}

// expect could call with custom fetcher
api.addTodo({/** input data */}, { fetcher: customFetcher })
@Lucifier129
Copy link
Collaborator

api.setFetcher(fetcjer) will be ok?

@tqma113
Copy link
Collaborator Author

tqma113 commented Dec 7, 2021

Looks yes. But not functional. 👀

api.setFetcher(fetcjer)

or

api.addTodo({/** input data */}, { fetcher: customFetcher })

?

@Lucifier129
Copy link
Collaborator

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.

@Lucifier129
Copy link
Collaborator

And api.addTodo({/** input data */}, { fetcher: customFetcher }) is not equal to api.setFetcher(fetcher) since it only works once.

@tqma113
Copy link
Collaborator Author

tqma113 commented Dec 9, 2021

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?

@Lucifier129
Copy link
Collaborator

Yes, it makes sense.

options.fetcher > setFetcer(fetcher) > default fetcher

@tqma113
Copy link
Collaborator Author

tqma113 commented Dec 9, 2021

@tqma113 tqma113 closed this as completed Dec 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants