New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possibility of adding options for manipulating key names #44

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

Comments

Projects
None yet
@ssboisen

ssboisen commented Sep 15, 2015

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

This comment has been minimized.

Show comment
Hide comment
@patrickdet

patrickdet Oct 15, 2015

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

patrickdet commented Oct 15, 2015

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

@devinus

This comment has been minimized.

Show comment
Hide comment
@devinus

devinus Jan 12, 2016

Owner

Considering this for inclusion in 1.6.

Owner

devinus commented Jan 12, 2016

Considering this for inclusion in 1.6.

@philipgiuliani

This comment has been minimized.

Show comment
Hide comment
@philipgiuliani

philipgiuliani Feb 18, 2016

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

philipgiuliani commented Feb 18, 2016

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

@aweiker

This comment has been minimized.

Show comment
Hide comment
@aweiker

aweiker Feb 26, 2016

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

aweiker commented Feb 26, 2016

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

@heri16

This comment has been minimized.

Show comment
Hide comment
@heri16

heri16 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.

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

This comment has been minimized.

Show comment
Hide comment
@mgwidmann

mgwidmann Nov 29, 2016

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

mgwidmann commented Nov 29, 2016

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

@minhajuddin

This comment has been minimized.

Show comment
Hide comment
@minhajuddin

minhajuddin Jan 11, 2017

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

minhajuddin commented Jan 11, 2017

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

This comment has been minimized.

Show comment
Hide comment
@mgwidmann

mgwidmann Jan 11, 2017

@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

mgwidmann commented Jan 11, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@minhajuddin

minhajuddin Jan 12, 2017

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

minhajuddin commented Jan 12, 2017

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

@ericmj

This comment has been minimized.

Show comment
Hide comment
@ericmj

ericmj 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.

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

This comment has been minimized.

Show comment
Hide comment
@minhajuddin

minhajuddin Jan 14, 2017

@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.

minhajuddin commented Jan 14, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@icorderi

icorderi Nov 13, 2017

What's the status on this?

icorderi commented Nov 13, 2017

What's the status on this?

@bottlenecked

This comment has been minimized.

Show comment
Hide comment
@bottlenecked

bottlenecked Dec 1, 2017

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

bottlenecked commented Dec 1, 2017

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

@KalvinHom

This comment has been minimized.

Show comment
Hide comment
@KalvinHom

KalvinHom May 29, 2018

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

KalvinHom commented May 29, 2018

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

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