You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 17, 2023. It is now read-only.
At the moment, developers need to provide the JSON object of the configuration when initialise the SDK, here is an example.
In this example, the content of mobile-services.json is put into a JS file and then required by the user's application. This is due to the fact that JSON format is not universally supported by all the loaders/importers in nodejs/typescript. It is supported by the newer versions of node and typescript, but the older ones don't.
To make it easier for developers to use our SDK, we should handle the loading and parsing of the mobile-services.json file. It will:
Make it easier for developers to consume our SDK
Make it easier for us to document the setup steps.
A possible approach is to allow developers to provide the path to the mobile-services.json file as part of the SDK initialisation. The SDK will still be backward compatible if the parameter to initialise the SDK is an object. But if the parameter is a String type, the SDK will then load and parse the configuration file and build the configuration object.
The text was updated successfully, but these errors were encountered:
wei-lee
changed the title
Add support for parsing the configuration file as part of the SDK init
Add support for loading and parsing the configuration file as part of the SDK init
Apr 8, 2019
Currently, SDK deals with processing config (parsing), however, users can pick the way to load JSON file that works with their bundler or load them separately outside bundler as well.
Current usage looks as follows:
new App(require("yourpath/mobile-services.json"))
This is executed at compilation time.
If suggestion is to do:
new App("yourpath/mobile-services.json")
Referring to file from the outside application (from node_modules) etc. may be tricky when package structure is not flattened. Propper way to deal with this will be to add the file as Cordova resource and let' it be available inside platforms, however, this is actually more complex, do not support web etc.
Open for suggestion. We tried to resolve mobile-config.json loading using numerous ways in the past by separate spikes and picked that option as the most flexible.
As I said, the API should still backward compatible. This means that developers can still chose how to load the config file if their app's setup is special. Then for our sdk, we can make it clear that if a string is passed in, it should:
An absolute path to the config file so that the path won't be a problem.
We will choose to only support loading the configuration file during build time. That is that some kind of bundler is used. These days pretty much all the bundlers are nodejs based, so it means we just need to support node to load the configuration.
This makes a lots of sense after clearing it now and it will actually work quite good with Cordova based use cases. We can provide loading of this config file outside browserify workflow so users will be able to swap this without recompiling application code - thus promotion to production etc. will be possible without full rebuild.
Feature Request
At the moment, developers need to provide the JSON object of the configuration when initialise the SDK, here is an example.
In this example, the content of
mobile-services.json
is put into a JS file and then required by the user's application. This is due to the fact that JSON format is not universally supported by all the loaders/importers in nodejs/typescript. It is supported by the newer versions of node and typescript, but the older ones don't.To make it easier for developers to use our SDK, we should handle the loading and parsing of the
mobile-services.json
file. It will:A possible approach is to allow developers to provide the path to the
mobile-services.json
file as part of the SDK initialisation. The SDK will still be backward compatible if the parameter to initialise the SDK is an object. But if the parameter is a String type, the SDK will then load and parse the configuration file and build the configuration object.The text was updated successfully, but these errors were encountered: