You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Following the discussion in this PR #744, we identified a potential improvement: adding a new option raise_error: false to avoid dependency inversion when the client requires it.
Currently, Tesla provides several adapters, but there is no unified configuration across them. This lack of consistency can lead to fragmented and inefficient setups. The goal of this proposal is to discuss the possibility of providing a centralized configuration and determine if it would be a valuable addition.
Proposal
I propose creating a centralized module that defines an enumerable set of allowed options for every adapter. This approach would promote consistency and simplify configuration management. Here’s an example implementation:
defmoduleOptionsdo@moduledoc""" Represents configuration options for Tesla adapters. """@typet::%__MODULE__{timeout: non_neg_integer(),raise_error: boolean()}defstruct[:timeout,:raise_error]end
With this approach, every adapter would reference and use this shared configuration structure, reducing redundancy and improving maintainability.
Unresolved Questions
Could a centralized configuration lead to a "ball of mud" situation, where this module accumulates options not relevant to every adapter? For instance, the Mint adapter may never raise errors, while Finch does. Should we be concerned about this potential bloat, and if so, how do we manage it?
Context
Following the discussion in this PR #744, we identified a potential improvement: adding a new option
raise_error: false
to avoid dependency inversion when the client requires it.Currently, Tesla provides several adapters, but there is no unified configuration across them. This lack of consistency can lead to fragmented and inefficient setups. The goal of this proposal is to discuss the possibility of providing a centralized configuration and determine if it would be a valuable addition.
Proposal
I propose creating a centralized module that defines an enumerable set of allowed options for every adapter. This approach would promote consistency and simplify configuration management. Here’s an example implementation:
With this approach, every adapter would reference and use this shared configuration structure, reducing redundancy and improving maintainability.
Unresolved Questions
cc/ @yordis
The text was updated successfully, but these errors were encountered: