Infinite depth configuration

[GravlLift]

This PR allows for more targeted configuration of state, removing the restriction that only top-level data can be stored. For instance, this is now a valid configuration:

export function localStorageSyncReducer(
  reducer: ActionReducer<any>
): ActionReducer<any> {
  return localStorageSync({
    keys: [
      {
        account: [
          { settings: [{ settingsGroup1: ['oneSettingInParticular'] }] },
        ],
      },
    ]
  })(reducer);
}

The above configuration would result in a localstorage value under the key account that looked like so, ignoring all other values in account, settings, or settingsGroup1:

{
  "settings": {
    "settingsGroup1": {
      "oneSettingInParticular": "value of setting"
    }
  }
}

Upgraded TS to 3.9.7
Added .editorconfig

[BBlackwo]

Hi Jason @GravlLift,

Thanks so much for the PR! This is great. I love how you've cleaned up the code and added types.

Can you please:

• Fix up the comments above (type consistency and adding a test)
• Update the docs with an example config multiple levels deep.
• Rebase off the lastest master and resolve the conflicts
• Update your commit messages to follow the new required commit message format .
  You can do this with an interactive rebase. I'd also suggest squashing some of the commits together.
  Your new commit format should be something like feat: allow infinite depth configuration

Once you've made those changes I'll have another look.

[GravlLift]

All set @BBlackwo.

• Fix up the comments above (type consistency and adding a test)
• Update the docs with an example config multiple levels deep.
• Rebase off the lastest master and resolve the conflicts
• Update your commit messages to follow the new required commit message format .

[BBlackwo]

Thanks for addressing all of those things! I've just got a few more minor comments if you can have a look please.

The only one that needs to be addressed is the deserialize function missing from the type. All the rest are optional.

You may want to squash the fixes together too.

Once that's addressed I'll merge it in and it will be automatically released as the next minor version.

[GravlLift]

Updated according to comments.

On an unrelated note, I'm not sure exactly how the commit/release note tool works, but it might be useful to apply that commit formatting restriction only to the master branch, and then simply squash PRs into a single commit with the correct formatting. That way you can have messy PR branches that you can update and commit as much as you like without restriction, but that mess gets condensed and removed into a single commit with a useful message when it goes to master. I'm rewriting the same commit over and over in this branch with force push anyways, so in essence you're losing that branch history regardless.

Just a suggestion.

[BBlackwo]

Thanks for fixing those up 👌

it might be useful to apply that commit formatting restriction only to the master branch, and then simply squash PRs into a single commit with the correct formatting.

That's a good idea. It looks like semantic release might not work well with squashed commits, sadly. But I'll keep it in mind!

[BBlackwo]

Thanks so much for this enhancement, Jason @GravlLift!

[BBlackwo]

🎉 This PR is included in version 10.1.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[BBlackwo]

Sorry it took so long for me to merge this in, btw. Appreciate your patience and continuing to address my comments months later.