Possibility of adding options for manipulating key names #44

Open
ssboisen opened this Issue Sep 15, 2015 · 11 comments

Projects

None yet

9 participants

@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
Owner
devinus commented Jan 12, 2016

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
aweiker commented Feb 26, 2016

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

@heri16
heri16 commented Aug 3, 2016

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
minhajuddin commented Jan 11, 2017 edited

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
ericmj commented Jan 14, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment