Skip to content
This repository has been archived by the owner on Oct 12, 2023. It is now read-only.

Customise conversion based on some criteria #27

Open
domchristie opened this issue Feb 13, 2016 · 3 comments
Open

Customise conversion based on some criteria #27

domchristie opened this issue Feb 13, 2016 · 3 comments

Comments

@domchristie
Copy link
Owner

As has been noted in other issues/pull requests (#26) the default conversion behaviour does not work in all cases, e.g.

Rather than add options for each of these cases, may I propose that just a single option be added that will handle all of the above. Something like:

humps.camelizeKeys(obj, {
  filters: [
    {
      filter: function (key) { return /^[A-Z_]+$/ },
      convert: function (key) { return key }
    },
    {
      filter: function (key) { return /^_/ },
      convert: function (key) { return key }
    },
    {
      filter: function (key) { return ['exclude_me', 'and_me'].indexOf(key) > _1 },
      convert: function (key) { return key }
    }
  ]
})

Although all the conversion functions in these cases simply return the original key unmodified, it may be useful to allow custom conversion e.g. #18.

Thoughts?

/cc @mattkrick, @GiovanniFrigo, @patrickgalbraith, @rufman

@patrickgalbraith
Copy link
Contributor

I like the thinking but I would recommend just doing it with a single callback like this:

humps.camelizeKeys(obj, (key, convert) => {
  return /^[A-Z_]+$/.test(key) ? key : convert(key)
})

That way you can just do the above like:

humps.camelizeKeys(obj, (key, convert) => {
  const tests = [/^[A-Z_]+$/, /^_/, /(exclude_me|and_me)/]
  return tests.some((re) => re.test(key)) ? key : convert(key)
})

In my opinion I still think #22 should be merged. But if not I can do this to fix it (at least the starts with underscore part).

humps.camelizeKeys(obj, (key, convert) => {
  return key.charAt(0) === '_' ? '_' + convert(key) : convert(key)
})

@GiovanniFrigo
Copy link

I agree with @patrickgalbraith, having a single callback makes the code more synthetic and flexible.

I'd still merge in #20 and #22 because it doesn't make much sense to have all-uppercase or underscore-starting keys camelized as it is right now.

@patrickgalbraith
Copy link
Contributor

@domchristie What do you think of #28?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants