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

Avoid raising errors - Normalize reserved options #756

Open
carrascoacd opened this issue Feb 28, 2025 · 0 comments
Open

Avoid raising errors - Normalize reserved options #756

carrascoacd opened this issue Feb 28, 2025 · 0 comments

Comments

@carrascoacd
Copy link
Contributor

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:

defmodule Options do
  @moduledoc """
  Represents configuration options for Tesla adapters.
  """

  @type t :: %__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?

cc/ @yordis

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

1 participant