Dynamic import not working

[jarecsni]

There has been a conversation around this problem on different thread, please see: https://github.com/facebook/react-native/issues/6391#issuecomment-329048372

The problem is essentially that as of now it is not possible to import or require modules dynamically or programatically (using a variable).

With import() in Stage 3 in TC39 this feature is fast becoming a standard language element and the lack of this facility in React Native is becoming all the more limiting.

Also, as per the above conversation there are very legitimate scenarios (dependency injection for example), where such lazy and conditional loading is a must.

Based on all this I would like to make a feature request for this (please let me know if this is not the right forum for doing so).

[cpojer]

@jeanlauliac can discuss more about the plans for this.

[jeanlauliac]

We plan on adding the import('foo') syntax to be able to load modules asynchronously, paving the way of being able to download part of the code on-demand, for example. This is something I'd love to happen towards the end of the year.

However, we have no plans to support non-static imports in general, whether it's a require(foo) or import(foo) where foo is a variable which value isn't known at bundling time. One reason I could point out, in particular, is that dynamic imports cannot be typecheked with Flow anyway (and I'd be surprised they are with Typescript either, but I haven't checked). Another reason is that we'd have to be over-eager when bundling, and include all the JS files, that would cause bigger bundles.

We could theoretically typecheck & support dynamic requires under the condition that the list of possible modules to be imported is known at bundling time, though it's not clear what syntax would express that. What I've seen in some projects to workaround this, for example for routing systems, is to have each require explicit. Ex.

{
  routeName: 'foo',
  view: () => require('SomeComponent'),
},
{
  routeName: 'bar',
  view: () => require('SomeOtherComponent'),
}

That is effectively equivalent to having 'dynamic' requires with a list of fixed possibilities, but more verbose. It would be possible, for one who wishes, to implement a Babel transform that'd make that less verbose.

[jarecsni]

@jeanlauliac Thanks for explaining the background! I think what you describe toward the end is exactly what people (including me) expect to happen: 1) provide a way to inform the packager which modules are potentially imported 2) support dynamic (programmatic) import of those declared in point 1. As you point out, type checking would work, bundle size would not be an issue.

Since dynamic (variable) imports will be part of the language, can RN afford not to provide some form of support?

[jeanlauliac]

Yes, even though I said we have no plans internally to implement it, I'd love RN to provide some form of support for this ^_^ We have no plans ourselves because we don't have a use case requiring that right now, and are busy with other issues, but I'm happy to look at proposals/PRs.

For example we could imagine some opt-in configuration setting that makes packager include all source files from a particular directory into a bundle, regressing build duration and bundle size but allowing for a form of dynamic require. It believes in need to be opt-in as it causes these regressions. Then we would have to figure out how numeric module IDs are handled in such a model.

[jarecsni]

Ok fair enough. I will have a think about it (I am not familiar with RN packager etc. so it may be a bit of a learning curve for me but then again, it is something I would love to use, so ... :))

[steveccable]

Is this being actively looked at/worked on by anyone at this point? This is still a feature I would very much like to see in RN, and was actually surprised not to have in the first place.

[jeanlauliac]

Is this being actively looked at/worked on by anyone at this point? This is still a feature I would very much like to see in RN, and was actually surprised not to have in the first place.

• Being able to dynamic require at runtime: no, this isn't being worked on right so far as I know.
• Being able to ignore dynamic requires (such as in moment.js) and have them throw at runtime, or replace them by static requires: this is already possible by having a custom babel transform that replaces dynamic requires by some code that throws, or just does nothing.

I'd like to publish some simple module to allow people to do the second case easily.

[sneerin]

This bug limit to numbers of really popular libraries like e.g. https://github.com/moment/moment/issues/3624 i saw similar other items with same issue

[camdagr8]

This is a huge bummer for me. I'm trying to take a Domain Driven Design approach with my RN app where each screen components have a predictable file structure:

--index.js
--actions.js
--actionTypes.js
--reducers.js

Then have a main reducers.js file that runs a loop that requires each file and automatically makes it available in the export default {...aggregatedReducersObject}

This approach simplifies our development process and reduces the number of times we've had compile errors because someone forgot to include their actions/reducers/etc into the aggregated files.

As a work around, I'm running a gulp watch on the components directory, then writing to my aggregated file on creation/delete. I hate doing it this way as there are often times when the gulp watch craps out or there's race conditions that spring up when editing that causes a need for a restart of both my gulp watch and RN.

[jeanlauliac]

Then have a main reducers.js file that runs a loop that requires each file and automatically makes it available in the export default {...aggregatedReducersObject}

I'm curious: how do you get the list of files to require, do you use readdir?

[camdagr8]

@jeanlauliac Yes, I use readdir via a custom CLI for the project that generates components/assets/libraries and adds the file names to the aggregated object.

It ends up looking like this:

export default {
    Login: {
        redux:  {
            state:       require('./components/screens/Login/state').default,
            actionTypes: require('./components/screens/Login/types').default,
            actions:     require('./components/screens/Login/actions').default,
            reducers:    require('./components/screens/Login/reducers').default,
            services:    require('./components/screens/Login/services').default,
        },
        screen: require('./components/screens/Login').default,
    },
    Home: {
        screen: require('./components/screens/Home').default,
    }
}

Then I use react-native-navigation to register the screens:

import registry from './registry';

// Redux setup
let actionTypes = {};
let actions  = {};
let reducers  = {};
let services = {};
let state = {};


Object.values(registry).forEach((item, i) => {

    if (!item.hasOwnProperty('redux')) { return; }

    let k = Object.keys(registry)[i];

    if (item.redux.hasOwnProperty('actionTypes')) {
        actionTypes = Object.assign({}, actionTypes, item.redux.actionTypes);
    }

    if (item.redux.hasOwnProperty('actions')) {
        actions[k] = item.redux.actions;
    }

    if (item.redux.hasOwnProperty('reducers')) {
        reducers[k] = item.redux.reducers;
    }

    if (item.redux.hasOwnProperty('state')) {
        state[k] = item.redux.state;
    }

    if (item.redux.hasOwnProperty('services')) {
        services[k] = item.redux.services;
    }
});

// Create the store
const createStoreWithMiddleware = applyMiddleware(thunk)(createStore);
const store = createStoreWithMiddleware(combineReducers(reducers), state);

// Register screens and create tabs
let tabs = [];

Object.values(registry).forEach((item, i) => {

    if (!item.hasOwnProperty('screen')) {
        return;
    }

    let k = Object.keys(registry)[i];
    Navigation.registerComponent(`app.${k}`, () => item.screen, store, Provider);

    if (item.hasOwnProperty('tab')) {
        tabs.push(item.tab);
    }
});

[jeanlauliac]

I was asking because readdir would be even more of a stretch to support by default, there's no concept of filesystem anymore at runtime. I think the way you approach this, by generating an aggregated module, is correct. But ideally the bundler would be able to generate it on-demand rather than it being a separate build step.

[serhiipalash]

For example we could imagine some opt-in configuration setting that makes packager include all source files from a particular directory into a bundle

You can do this with babel-plugin-wildcard https://www.npmjs.com/package/babel-plugin-wildcard

It works for us in production.

[camdagr8]

@serhiipalash I'll have to give this a look. Thanks!

[serhiipalash]

@camdagr8 I don't know how this plugin works, but we have folder with these files

translations/
   en.json
   de.json

I think it replaces our

import * as translations from '../../translations'

on this

import de from '../../translations/de'
import en from '../../translations/en'
const translations = { de, en }

And it does this before React Native packager started. If you add more files in translations folder after React Native packager start (during development), it will not know about them until you restart it. In production as we don't have such case - read dynamic new files during runtime, we can use it.

[simonbuchan]

Webpack does this by parsing the module expression and bundling everything it could require

Typescript has been coming at typing modules for a while, but the current closest issue would be https://github.com/Microsoft/TypeScript/issues/14844

[deecewan]

Another reason is that we'd have to be over-eager when bundling, and include all the JS files, that would cause bigger bundles

I think that not implementing this because it could blow out bundle sizes is like saying you're not going to support node_modules, because too many modules will blow out bundle size. Webpack allows this, but doesn't encourage it. If a developer plans on using this, of course the burden is on the developer to mitigate bundle size issues.

One place I'd like this is in importing translation files. They all sit in the same place, and if I could use a variable, I could do something like

import(`translations/${locale}.json`)

In this case, eagerly loading the whole folder is not just a side-effect, but the intention, given the alternative of

const translations = {
  en: import(`translations/en.json`),
  de: import(`translations/de.json`),
  'en-US': import(`translations/en-US.json`),
};

And so on for more languages as my service scales out.

Not only that, but I also need to load locale data, both for the Intl polyfill and for react-intl. I end up having three lists that do nothing but contain imports for every file in three different folders. If anything, that'll increase bundle sizes more, because of all the code sitting there to fill the void of dynamic imports.

Additionally, it'd be nice to be able to import via http. For instance, instead of bundling all translations with my application and increasing download for people who only need one language, have

const translations = await import(`https://some-s3-url.com/translations/${locale}.json`);

and similarly with the locale data that also needs to be loaded.

[simonbuchan]

Importing unbundled code is a very interesting use-case that would in the general case need to implement https://whatwg.github.io/loader/

I've gotten surprisingly far by simply combining fetch() and eval(), some simplified code:

const externals = {
  react: require('react'),
  'react-native': require('react-native'),
};
async function fetchImport(url) {
  const res = await fetch(url);
  const source = await res.text();

  let exports = {};
  const module = { exports };
  const require = id => {
    if (!(id in externals)) throw new Error(`Module not found: ${id}`);
    return externals[id];
  };
  eval(source);
  return module.exports;
}

The main problem with this is that error stacks in (at least android) JSC don't include frames from eval'd code at all, even with \n//# sourceURL=${url} appended (which works when using the remote debugger)

[slorber]

@camdagr8 what you want can also be done by using babel macros / codegen https://medium.com/@karanjthakkar/using-babel-macros-with-react-native-8615aaf5b7df

@jeanlauliac I have an app which is actually 2-in-1 apps. It's like a merge of the Uber Driver and Uber Customer app into a single app shell, with a common login interface. After login we should redirect the user to the correct app according to a boolean. I want dynamic imports because if the user is a driver there is no need to load the client app code (+ the apps were designed initially as standalone and have initialization side effects, singletons...)

Are you saying that this could be a solution to my problem?

const Main = ({user}) => {
  const UberApp = user.isDriver ? require("UberDriverApp") : require("UberCustomerApp");
  return <UberApp/>;
}

And this will ensure that only one of the 2 "internal apps" are effectively loaded, giving me some benefits (less JS parsing, faster initialization, no unwanted/unneeded startup side effects...) ???

[jeanlauliac]

I want dynamic imports because if the user is a driver there is no need to load the client app code (+ the apps were designed initially as standalone and have initialization side effects, singletons...)

Since your requires are inline, it's effectively not going to run either module factory function until the code require one or the other, at which point it'll run only one. The other module (and dependencies) won't get run and so won't affect global state. Thus you don't need dynamic import() for that, this is already something that works 😄

What dynamic import() might be able to provide in that example, is downloading the JavaScript code from one app or the other, only when needed, so as to make the app lighter in weight. This is not something that Metro supports out-of-the-box, and it also comes with its own sets of tradeoff (won't work offline, etc.)

[slorber]

Thanks @jeanlauliac , require() will be fine for me then, as I don't need to download remote js code, and require is enough for all local code (many usecases can be solved by using codegen macro above imho)

[EskelCz]

This is also important for loading storybook stories from src folder, without maintaining an index file. https://storybook.js.org/basics/writing-stories/#loading-stories-dynamically

[jdnichollsc]

Hi guys! Exist any solution to download remote bundles at runtime?

[benbucksch]

This request is not to download resources from the Internet and make them available synchronously. It's merely about loading the bundled assets with a URL that's constructed at runtime, so that I can load "./data/" + lang + "/" + file + ".txt" and implement a class that loads a certain type of files.

I've got thousands of data files, and all those in several languages, a total of maybe 10000 files, and which file is loaded depends on the user input, so I really need to construct the filename at runtime.

I would already be happy with a normal fetch("asset://" + filename) with async load. I completely fail to understand why that cannot be done.

[uladkasach]

@jeanlauliac you mentioned that async import will be supported by end of year:

We plan on adding the import('foo') syntax to be able to load modules asynchronously, paving the way of being able to download part of the code on-demand, for example. This is something I'd love to happen towards the end of the year.

do you know if that has been completed? Or what the plans are for that, if not?

[jeanlauliac]

I've left the project since then so I'm not 100% sure of the current state, but I think there's some partial support. @rafeca, @rubennorte, do you know if there is any possibly import() support in OSS Metro?

[markwongsoontorn]

Being able to dynamically load dependencies would make a huge difference, webpack already has this supported, I'd like to see this happen sometime in the near future.

[MarcoMacedoP]

Is there any update status for this issue?

[pvanny1124]

Bump. It would be extremely nice to have the ability to do this.

[slorber]

It's not totally related, but wanted to mention here that optional requires are now possible. Not sure how but this might enable a workaround for some people interested by this feature? https://github.com/react-native-community/discussions-and-proposals/issues/120#issuecomment-617466779