Return a tuple about maprewire HOT 3 CLOSED

Good point. Do you think it should come down with the :ok atom like {:ok, map, remap}?

from maprewire.

I’m not sure that {:ok, map, remap} is necessary for this library, unless you intend to return {:error, map, rules} or something like that on conversion failure. I think simply returning {map, remap} instead of [map, remap] is a better choice (tuples are fixed length while lists are not).

I have some other ideas after looking at what you’re doing (I’ve got a couple of hand-rolled approaches to this that I’m using that if I can figure out a way to genericize them, I might propose to you as alternatives to how the rules might be implemented). One thing I’ve noticed in particular is that because you’re using string rules (e.g., "id=>shopify_id"), you can only go from string to string, not string to atom or vice-versa. If you added the ability to specify your rules as any tuple-generating enumerable, you can do this. Something like:

def normalize_rules(rules) when is_binary(rules) do
  rules
  |> String.split(~r/\s/) # split on any whitespace
  |> Enum.map(&normalize_rule/1)
end

def normalize_rules(rules) when is_list(rules) do
  Enum.map(rules, &normalize_rule/1)
end

def normalize_rules(rules) when is_map(rules) do
  Enum.to_list(map)
end

defp normalize_rule({_old, _new} = rule), do: rule

defp normalize_rule(value) when is_binary(value), do: to_tuple(String.split(value, "=>"))

defp normalize_rule(value) when is_list(value) and length(value) != 2,
  do: raise("Invalid rule format #{inspect(value)}")

defp normalize_rule(value) when is_list(value), do: to_tuple(value)

defp normalize_rule(value), do: raise("Invalid rule format #{inspect(value)}")

Now you can process this with something like:

defp restructure(map, rules) do
  rules
  |> normalize_rules()
  |> Enum.map(&restructure_entry(&1, map))
  |> Enum.into(%{})
end

defp restructure_entry({old, new}, map) do
  {new, Map.get(map, old)}
end

This sort of thing potentially allows you to have more interesting constructs like this as a rule:

%{"id" => "shopify_id", "price" => {"price", &to_cents/1}}

For this to work, the putative restructure_entry that I showed would need to look like:

defp restructure_entry({new, {old, fun}}, map) when is_function(fun) do
    {new, fun.(Map.get(map, old))}
end

defp restructure_entry({new, {old, default}}, map) do
  {new, Map.get(map, old, default)}
end

defp restructure_entry({new, old}, map) do
  {new, Map.get(map, old)}
end

from maprewire.

I've pushed a commit (about 3 hours ago) that shows how the error tuple could be used in place of raising BadArgument.

I think this path would allow deeper support for packages like Ok_Jose.

Hmm, some really good ideas to think about here.

I was considering adding modifiers to the strings so you could create some kind of additional action.

Using the modifiers you could do something like id=>^shopify_id where ^ is the modifier for casting a string key to atoms or have a global modifier where you have lots of values %id=>shopify_id title=>name where % will cast every key to an atom.

However, I'm not sure if this would allow for the ability to things like %{"id" => "shopify_id", "price" => {"price", &to_cents/1}} unless it comes with some kind of pass through modifier.

I like the idea of expanding the functionality, but I think the project needs a plan and some set of goals.

I've sent an email to your GitHub address @halostatue :)

from maprewire.