add support for nils

[sasa1977]

Problem

Currently provider doesn't support nil values, which sometimes leads to weird hacks in the client code.

For example, suppose that we're shipping metrics to an external service. The URL of this service is provided via a config parameter. Now, on some deployments (e.g. private sandboxes used by individual developers), we don't want to send the metrics.

Currently there are two ways of handling this.

The first one is to use a single parameter, and a hardcoded "nil substitute". E.g. if the param value is http://do-not-send-metrics we don't ship the metrics. This is weird and hacky. Chosing a nil substitute may not be possible for all types (e.g. dates or numbers).

Another option is to introduce another param, a boolean, called e.g. ship_metrics. The downside here is that we now need an extra param, and we still need to provide some dummy value for the URL.

If nil was supported this could easily be handled with a single param. If the param is nil, don't ship metrics.

Solution proposal

We add the nil? option, so one can do:

use Provider,
  params: [{:metrics_url, type: :string, nil?: true}, ...],
  ...

In this case, if the value is not provided, it will default to nil. If the provided value is an empty string, the param is cast to nil. This behavior can be changed by providing an empty_values option, which would work like in Ecto changeset. The question is whether this option should be param-specific, or is it enough that it's global (i.e. single setting for the entire schema).

By default, params are not nilable.

[ankhers]

I'm not sure about this one. The idea of :nil? makes sense overall, but I feel like certain types of values are going to be sprinkled with :nil?s in various different environments. Most notably in dev for things such as the metrics url that you describe. If I start throwing nil?: true in there to satisfy development, I am going to still have it there for my prod environment where I actually want to ensure that the value is set.

Similarly, I think the empty_values option makes sense in the context of Phoenix / ecto because there is no real difference between leaving a textbox empty vs nil. It is up to the application at that point to decide if an empty string can be a valid value. Whereas for this lib, just not setting whatever key is probably different than explicitly setting an empty string value in the key?

[sasa1977]

The idea of :nil? makes sense overall, but I feel like certain types of values are going to be sprinkled with :nil?s in various different environments. Most notably in dev for things such as the metrics url that you describe.

In the given example the need for nil actually occurs in prod, i.e. on a deployed version. But you make a good point for dev env (and the same stands for test).

This is part of the reason why I didn't implement it originally, and we were able to handle all our needs without it. It did require providing some dummy values for dev/test, but that was fine. There was I think one or two cases where we had to resort to the hack above, i.e. set some quasi-nil and compare against that magic constant in the lib code.

Similarly, I think the empty_values option makes sense in the context of Phoenix / ecto because there is no real difference between leaving a textbox empty vs nil. It is up to the application at that point to decide if an empty string can be a valid value. Whereas for this lib, just not setting whatever key is probably different than explicitly setting an empty string value in the key?

Good point! Currently we use the default Ecto constants, so empty string is treated as nil. I guess we should change this, i.e. only so one can provide the empty string (or string with only whitespaces) as the value?

[ankhers]

i.e. only so one can provide the empty string (or string with only whitespaces) as the value?

While I cannot think of a usecase where a whitespace only value is particularly useful, I think that is the behaviour that we should be targeting. If the user explicitly provides a value, we should be making the assumption that the value provided is the value that we want to be using.