Possibility of adding options for manipulating key names

[ssboisen]

Hi Devin,

I was wondering how you feel about adding the option to supply a function which would enable the users of Poison to manipulate the names of keys when both encoding and decoding. It would be a simple string ->string function that can be supplied as a option with the default value being the identify function. The use case for this feature is that we use snake_case in our elixir backend but camelCase in our javascript frontend. We would like to have the serializer take of doing this conversion.

Currently we have a solution where we in case of encoding redefine the Poison.Encoder protocol implementation for Map and for decoding do a recursive run though the map resulting from calling Poison.decode. It would be nice if it was something that could be build into the serializer using a simple hook as described above.

Best Regards

Simon, Denmark

[patrickdet]

👍 I have exactly the same use-case. Elixir to JS and back. A hook like this would make life much easier.

[devinus]

Considering this for inclusion in 1.6.

[philipgiuliani]

Extractly what i searched! :) Would be amazing to see this implemented. The base of @joshprice looks already good!

[aweiker]

Any update on this? I would love to have some basic support for this.

[heri16]

I think what people are asking here is for an external function to be called to transform the keys. The anonymous function would be up to library user to define and pass_in, thus we avoid having it built-into Poison.

[mgwidmann]

would also be nice to have value transformations if possible... (for example decrypting an encrypted value)

[minhajuddin]

I have a use case where the input json has keys in mixed cases, sometimes Latitude and sometimes latitude. At the moment I am manually lower casing keys using http://minhajuddin.com/2017/01/11/case-insensitive-key-retrieval-from-maps-in-elixir/ Would love to have this even if it provided a lower_case_keys transform

[mgwidmann]

@minhajuddin be careful with that, as iterating all keys/values each time you need to access defeats the purpose of using a map over a keyword list. A large data set will be significantly slower to access this way. I would say that a better approach would be to modify that code to attempt to fetch latitude and then try Latitude. Even if you try various versions of the key that will scale better than Enum.find/2

[minhajuddin]

@mgwidmann Good point. Creating a new map and then using lower case keys to access makes more sense performance wise.

[ericmj]

The general advice is to fix data at the boundaries, when the data enters the rest of your system it should be in the correct state instead of trying to handle incorrect data everywhere in your system. That means that you should transform the map to lowercase after json decoding it instead of changing how you access the map.

[minhajuddin]

@ericmj Makes total sense. That is why I am following this issue with interest. Adding this feature will help me transform the keys at the time of decoding. I have seen cowboy do this with http headers.

[icorderi]

What's the status on this?

[bottlenecked]

Hi everyone, I tried a somewhat different approach here #151, maybe we can get interest in this feature rekindled

[KalvinHom]

Interested in this as well, as our existing frontend expects camelCase JSON.

[Jamesweng]

hello, any way to decode and transform keys to snake styles now?