chore: ApiBuilder
should support Default
without a token
#60
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When creating an API instance the current methods enforce checking for a local
token
file, even when you intend to provide your own viawith_token()
, thus finding a token is redundant, as is the info log of one missing being emitted.from_cache()
callscache.token()
to set thetoken
field in the builder.with_token()
prior, bothdefault()
andnew()
methods use the same initialization. Only workaround is to duplicatefrom_cache()
and omit the token check.build_headers()
method during the finalbuild()
call.This PR changes:
Default
impl for both sync/async structs to provide the same struct value except for thetoken
field, leaving it asNone
by default.from_cache()
will use the "Struct Update" syntax to spread the remaining default field values (this communicates more clearly what the method is actually modifying).Api
andApiBuilder
structs were grouped contextually for better visibility vs interleaved. Handled via a separate commit.I've tried to minimize affecting anything else, but technically if someone was relying on
ApiBuilder::default()
before instead of::new()
, the only difference should be thattoken
is not potentially set for them. Anyone who is using::new()
should be unaffected by this change.Related: #54 (comment)