Provide camelized option according to v1.1 spec

[snewcomer]

https://jsonapi.org/format/1.1/

Profile links to follow in another PR.

[jherdman]

Ought this to be the default going forward, or do you think that explicit configuration is more ideal?

[snewcomer]

Kind of goes back to this discussion but I agree it probably should be the default going forward. Other libraries like ja_serializer also assume the default according to the jsonapi spec. I'll wait for @doomspork's thoughts as well.

#149 (comment)

[doomspork]

If this is the JSONAPI default, we should follow suit 👌

[doomspork]

Can we please find another way to express this block of code? The use of pipelines and lists is making this very difficult to grok. It's also strange that we have a case but don't actually pattern match on things.

Also, do we need Enum.filter(&(&1 != "")? What example would leave you with an extra empty string? If this is something that occurs I think trim: true in Regex.split/2 would be a better option.

[doomspork]

defmodule Example do
  @camelize_regex ~r/([a-zA-Z0-9])(?<delimeter>[-_])([a-zA-Z0-9])/
  def camelize(value) when is_binary(value) do
    with [h | t] when length(t) > 0 <- Regex.split(@camelize_regex, value, on: [:delimeter], trim: true),
         capitalized <- Enum.map(t, &String.capitalize/1),
         downcased <- String.downcase(h)
    do
      Enum.join([downcased | capitalized])
    else
      _ -> value
    end
  end
end

[doomspork]

I updated my example above to use the length(t) > 0 guard because I found an issue with the original code (and mine) using this regex:

Utils.String.camelize("exampleName")
"examplename"

I do not believe we want to downcase strings that are already camelcased.

[doomspork]

We can also update our regex here to avoid the need for the on: [:delimeter] (delimiter is spelled wrong in the regex also):

~r/(?<=[a-zA-Z0-9])[-_](?=[a-zA-Z0-9])/

iex> Regex.split(~r/(?<=[a-zA-Z0-9])[-_](?=[a-zA-Z0-9])/, "example_name")
["example", "name"]

[doomspork]

@snewcomer / @jherdman I feel this file as gotten to be a bit complicated with lots of functions for each style of formatting. What do you think about simplifying this module a bit?

defmodule Example do
  def underscore(value) do
    value
    |> tokenize()
    |> join("_")
  end

  def dasherize(value) do
    value
    |> tokenize()
    |> join("-")
  end

  def camelize(value) do
    with [h | t] when length(t) > 0 <- tokenize(value),
         capitalized <- Enum.map(t, &String.capitalize/1),
         downcased <- String.downcase(h)
    do
      Enum.join([downcased | capitalized])
    else
      _ -> value
    end
  end

  defp join(value, joiner), do: Enum.join(value, joiner)

  defp tokenize(value) do
    replaced_value = String.replace(value, ~r/([a-z])(?=[A-Z])/, "\\1_\\2")
    tokens = Regex.split(~r/(?<=[a-zA-Z0-9])[-_](?=[a-zA-Z0-9])/, replaced_value, trim: true)
    Enum.map(tokens, &String.downcase/1)
  end
end

iex> Example.underscore("example_name")
"example_name"
iex> Example.underscore("example-name")
"example_name"
iex> Example.underscore("exampleName")
"example_name"

iex> Example.dasherize("example-name")
"example-name"
iex> Example.dasherize("example_name")
"example-name"
iex> Example.dasherize("exampleName")
"example-name"

iex> Example.camelize("example_name")
"exampleName"
iex> Example.camelize("example-name")
"exampleName"
iex> Example.camelize("exampleName")
"exampleName"

Happy to open a PR to clean up this util 👍

[doomspork]

If this is the JSONAPI default, we should follow suit 👌

[doomspork]

Elsewhere we make use of guards yet with this function we go the if/else route. Is there a reason we didn't use guards here as well?

Suggested change

	def camelize({key, value}) do
	def camelize({key, value}) when is_map(value) do
	{camelize(key), camelize(value)}
	end
	def camelize({key, value})
	{camelize(key), value}
	end
	end

[snewcomer]

@doomspork @jherdman Lmk what you think about this PR to merge into this base branch. Essentially introduces expand_fields/2 where the second arg is the appropriate string method. There still exists Sean's idea to tokenize the string - which I like a lot and can happen here or another PR.

https://github.com/snewcomer/jsonapi/blob/5519920245c80af336027a9dfaafc526ec7cb8f7/lib/jsonapi/utils/string.ex

https://github.com/snewcomer/jsonapi/pull/1/files

[jherdman]

I don't believe this is strictly true, so it may be a bit misleading.

I'll start open a project board that has issues for new JSON:API v1.1 features.

[doomspork]

@snewcomer after we merge do you want me to open a PR to refactor the String utils?

[snewcomer]

@doomspork Yeah that would work!

Just looking for some feedback on this PR before tying this one up. Basically consolidates duplicated logic to get at the value to transform.

[doomspork]

Oh I missed that PR, let me look

[snewcomer]

@jherdman Did you want 0.9 released before this PR goes in?

[jherdman]

Yeah, let's do that. I can't seem to find any issues that need to be addressed before a 0.9 release.

[snewcomer]

Alrighty up to date with master and passing tests! All good to merge?