While using ollama-js, I've found myself referring to the Ollama API docs to see exactly when certain fields are provided in the response, but I believe ollama-js should be aiming to abstract away the API. Currently, the types for optional fields aren't actually optional. While documentation on the response interfaces would help with this, I think it would be even better if they were treated as different types of responses altogether.
There's three ways I think the final response could be handled
done could be an object instead of a boolean, where the object contains all the fields which are only accessible when done is truthy. This would still allow for if (done), since objects are considered truthy and undefined is not. This would require restructuring the response received from the API, though.
Using a type along the lines of partField & ({ done: false} | { done: true, ... ). This would not require any changes outside of the interface
While using ollama-js, I've found myself referring to the Ollama API docs to see exactly when certain fields are provided in the response, but I believe ollama-js should be aiming to abstract away the API. Currently, the types for optional fields aren't actually optional. While documentation on the response interfaces would help with this, I think it would be even better if they were treated as different types of responses altogether.
There's three ways I think the final response could be handled
donecould be an object instead of a boolean, where the object contains all the fields which are only accessible whendoneis truthy. This would still allow forif (done), since objects are considered truthy andundefinedis not. This would require restructuring the response received from the API, though.partField & ({ done: false} | { done: true, ... ). This would not require any changes outside of the interface