Closed elliotdickison closed 3 years ago
@maxkomarychev Any feedback on this? I'd be happy to put together a PR if we can agree on a direction.
hey! that's a great suggestion!
why not drop the js_override flag and the UltimateConfig module reference from JavaScript entirely and just generate a pure JavaScript module containing the needed variables. This would simplify usage (zero config!) and make things work on the web and on native with the same import path. Or am I missing some benefit to pulling the JS config values from native?
the very reason I created this project is to keep all platforms aligned. there are plenty of solutions which work good in pure js world but I want to be able to define variables in all platforms. having said that it seems natural to propagate values from ios/android to js.
it's getting a bit tricky now to try to retrofit pure-js solution on top of current library. I wonder is it possible to have isomorphic implementation such that we don't have to generate separate d.ts file for overrides.
for instance is maybe possible to detect whether code is running in web or react-native? maybe by checking existence of some global variable? window?
the very reason I created this project is to keep all platforms aligned. there are plenty of solutions which work good in pure js world but I want to be able to define variables in all platforms. having said that it seems natural to propagate values from ios/android to js.
The vision makes sense, I like it.
I wonder is it possible to have isomorphic implementation such that we don't have to generate separate d.ts file for overrides. Would the switch between the pure-js web module and the react-native module have to be automatic though?
I believe that building an automatic switch behinds the scenes would require dynamic imports (to avoid referencing react native modules in a web app)... not ideal. I think we could generate a separate build file specifically for the web though without duplicating types. Users could import the file via import config from "react-native-ultimate-config/web";
, making it clear that they're getting a web-specific version. For universal react-native/react-native-web projects it is standard to use webpack to replace "react-native" imports with "react-native-web" imports, so we could write a bit o' documentation recommending the same thing to switch between "react-native-ultimate-config" and "react-native-ultimate-config/web".
These changes could be implemented separately from any modification to the js_override
flag, but they would allow you to eventually drop the js_override
flag in favor of import config from "react-native-ultimate-config/web";
which I think would be more in line with your vision of an "ultimate" config option that is the same everywhere in a react native app.
Do you think we can do it relying on this feature of react-native and metro bundler https://reactnative.dev/docs/platform-specific-code ?
We could create a file index.js
and index.native.js
. In web projects you it would resolve to index.js
free of all react-native imports. In RN projects it would resolve toindex.native.js
.
In such case we don't have to worry about dynamic and/or optional imports and simply have 2 files picked up by a bundler based on which bundler/env is used.
What do you think?
Oh nice, love it. I think I've got enough to put together a PR, should have time in the next couple of weeks.
published as part of 3.4.0
thank you! <3
It would be a killer feature if this package worked on the web as well (for universal react-native/react-native-web projects). It can almost be used as is with the
js_override
flag set to true, except that the getter functions in the resultingoverride.js
file don't have branches for the web platform.The bare minimum that would be needed to support this:
web
branches to the auto-generatedRN.Platform.select
calls inoverride.js
.web
key along side theios
andandroid
keys in platform-specific yaml config.override.js
.js_override
must be turned on and "react-native-ultimate-config/override" imported directly to work on the web (to avoid importing the native module).A semi-related suggestion: why not drop the
js_override
flag and theUltimateConfig
module reference from JavaScript entirely and just generate a pure JavaScript module containing the needed variables. This would simplify usage (zero config!) and make things work on the web and on native with the same import path. Or am I missing some benefit to pulling the JS config values from native?If you're open to one or more of these ideas I'm happy to create a pull request.