feat(stateConfig): make state config more flexible

[JamesSingleton]

This allows the provideStateConfig to accept more than an object
or a string.

Closes #20

[oneamexbot]

☑️ Preflight Checklist:

All questions must be addressed before this PR can be merged.

• What is the communication plan for this change?
• Does any documentation need to be updated or added to account for this change? If so was it done already?
• What is the motivation for this change?
• Should these changes also be applied to a maintenance branch or any other long lived branch?
• How was this change tested?
• Does this change require cross browser checks? Why or why not?
• Does this change require a performance test prior to merging? Why or why not?
• Could this be considered a breaking change? Why or why not?
• Does the change impact caching?
• Does the change impact HTTP headers?
• Does the change have any new infrastructure requirements?
• Does the change affect other versions of the app?
• Does the change require additional environment variables?
• What is the impact to developers using the app?
• What is the change to the size of assets?
• Should integration tests be added to protect against future regressions on this change?

Generated by 🚫 dangerJS against d8853e7

[JamesSingleton]

• What is the communication plan for this change?
  • API Docs
• Does any documentation need to be updated or added to account for this change? If so was it done already?
  • Potentially https://github.com/americanexpress/one-app/blob/master/docs/api/modules/App-Configuration.md#providestateconfig.
  • No it has not been updated, not sure if it is needed.
• What is the motivation for this change?
  • The config from the root module should be more flexible #20
• Should these changes also be applied to a maintenance branch or any other long lived branch?
  • No
• How was this change tested?
  • Unit tests
  • Manually serving a root module to one-app
• Does this change require cross browser checks? Why or why not?
  • N/A
• Does this change require a performance test prior to merging? Why or why not?
  • N/A
• Could this be considered a breaking change? Why or why not?
  • No, relaxing the check on provideStateConfig
• Does the change impact caching?
  • No
• Does the change impact HTTP headers?
  • No
• Does the change have any new infrastructure requirements?
  • No
• Does the change affect other versions of the app?
  • No
• Does the change require additional environment variables?
  • No
• What is the impact to developers using the app?
  • Allows developers to provide a more flexible provideStateConfig
• What is the change to the size of assets?
  • N/A
• Should integration tests be added to protect against future regressions on this change?
  • Not sure, would like some input from @anescobar1991 @10xLaCroixDrinker @Francois-Esquire @nellyk, @mtomcal and @JAdshead on this

[mtomcal]

Looks great to me. We should add a test case to Integration test to see if non string is parsed correctly as well.

[10xLaCroixDrinker]

• Does any documentation need to be updated or added to account for this change? If so was it done already?

  • Potentially https://github.com/americanexpress/one-app/blob/master/docs/api/modules/App-Configuration.md#providestateconfig.

Yes it should be updated in this PR

[10xLaCroixDrinker]

keep validating the type

[JamesSingleton]

So we want to only explicitly accept string, number, or boolean? The reason I did this was it puts the complexity to 13. I talked with @JAdshead and we came up with this solution.

[JamesSingleton]

Looks great to me. We should add a test case to Integration test to see if non string is parsed correctly as well.

@mtomcal,

This would require a 0.0.2 of PickyFrank to be created since the current way we log things, it throws at the first error instead of batching everything together.