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
The static configuration modules (environment.js and local-settings.js) were built in a hurried fashion a long time ago to support local development and network configuration.
In the time since, it's become pretty clear we have lots of room for improvement.
Moving to a run-time configurable config, we would initialize the app with a set of defaults, like we do now, but configuration panels or URL parameters could be used to control the app at run time.
The process.env part could be done by passing a small function to the provider to read the defaults, one to read the current value (e.g. local storage) and another one to write (we could use local storage by default here too).
Another thing I was thinking about would be to have two ways to declare an config value in the env vars: as a default if not set, and as a way to set the value when the app starts. For example, we could have ARAGON_ASSET_BRIDGE=local yarn start as a default, and SET_ARAGON_ASSET_BRIDGE=local yarn start to force it. The use-configuration provider could let us say “use this value as a default” or “use this value and write it if needed”. We could also provide a function, as a separate export to convert from ARAGON_ASSET to aragonAsset, so that it would be super easy to set the former as an env var, and the latter in the code.
The text was updated successfully, but these errors were encountered:
The static configuration modules (
environment.js
andlocal-settings.js
) were built in a hurried fashion a long time ago to support local development and network configuration.In the time since, it's become pretty clear we have lots of room for improvement.
I have some ideas for a run-time configurable
ConfigurationContext
, that could also be nicely encapsulated into ause-conf
package.Moving to a run-time configurable config, we would initialize the app with a set of defaults, like we do now, but configuration panels or URL parameters could be used to control the app at run time.
Some other thoughts from @bpierre:
The text was updated successfully, but these errors were encountered: