Feature/dynamic config load

[CodeSkills]

Related issues

None

Short description and why it's useful

This enables to load dynamic config on every page load.

Anyone can simply define loadConfig function within src/server/index.js that returns a Promise.

module.exports.loadConfig = (req) => {
  const axios = require('axios')
   return new Promise((resolve, reject) => axios.get('myapi.com/config', {
     params: {
       domain: req.headers.host
     }
   }).then(res => {
    resolve(res.data)
   }).catch(error => reject(error)))
 }

Screenshots of visual changes before/after (if there are any)

None

Screenshot of passed e2e tests (if you are using our standard setup as a backend)

Using own API - tested locally (debug and visual)

Upgrade Notes and Changelog

• No upgrade steps required (100% backward compatibility)
• I've updated the Upgrade notes and Changelog on how to port existing VS sites with this new feature

Contribution and currently important rules acceptance

• I read and followed contribution rules
• I read the TypeScript Action Plan and adjusted my PR according to it
• I read about Vue Storefront Modules and I am aware that every new feature should be a module

[filrak]

With this approach is keeping config in apps state still necessary? @pkarw wdyt?

[pkarw]

It’s a cool feature! Thanks a lot! Can You also add some docs on that?

@NataliaTepluhina could you please add these docs to the official resources?

[pkarw]

@filrak yes, it’s bascially the only way to provide the config to CSR - we need config to properly execute client side code. Ofc we can do separate request just for config from Clients side but it makes no sense; it’s more optimal to keep it in state in this case.

When user doesn’t require to have dynamic config reload then config is not provided to the clients side but just compiled into webpack bundle

[CodeSkills]

@pkarw Renamed the function and added basic Docs to the end of Config Docs.

[pkarw]

Awesome, Thanks! Will merge it once get in front of my computer :)

[CodeSkills]

Last thing, when the Promise is rejected (for some reason which could happen). There should be 2 options

1. Continue with default (build time/runtime config)
2. Throw Error 500 page

These are rare occurrences but will eventually happen.

@pkarw Should I add a config for dynamicConfigReload that can decide between these two?

[pkarw]

Yes Please, thats a good point. We should have the option in config for that 👍

[CodeSkills]

Added the option and tested all options with latest changes to check that all works as expected.

@pkarw Let me know if you come up with better naming for the option :-)

It now allows to configure an option if it should continue with built time config or to be redirected to /error page.

[pkarw]

Perfect. Thanks!