Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Question: extending context initial request headers

Abierto
  • ¿Algo no está bien?
#114 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
30/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
typescript
Área
api, tooling

Línea de trabajo

Start by tracing the generated use* functions, useApiContext(), fetcherOptions, and the myFetchFn call described in the issue. Clarify the intended property-specific header merge behavior and how per-request variables should interact with shared context options. Done means the chosen behavior is documented and verified for both shared and request-specific headers.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

waiting response

Hi everyone,

I have a question, I believe it's currently not possible but if it is, it would be nice to know.

With the fetcherOptions in the apiContext (auto-generated and manually modified) I am able to set some specific headers all of the requests. Let's say, for example, the authentication header which will be common to all requests (ie. Bearer Auth).

There are certain APIs, however, that require their own headers. In those cases, with the parameters of the use* generated function I'm able to send those as well without problem.

However, the problem that happens is that because of the way the fetch fn is called, all these initial fetcherOptions headers seem to get overwritten:

myFetchFn({ ...fetcherOptions, ...variables }, signal),

Is there any way to allow it overwrite in a property-specific way? For example something like this:

{headers: {...fetcherOptions.headers, ...variables.headers}} (I know we should check for possible null objects, I'm omitting it for simplicity's sake).

Other way I've been thinking of that could be possible to implement something like this would be passing the variables to the useApiContext() call at the start of each use* function and letting each person to extend the resulting variables in their own fashion or requirements per as the project.

What do you think? Thank you for your help

Lenguaje dominante
TypeScript
Estrellas
634
Forks
83
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de fabien0102/openapi-codegen

Todos los issues de fabien0102/openapi-codegen

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.