Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dynamic import not working #52

Open
jarecsni opened this issue Sep 13, 2017 · 44 comments
Open

Dynamic import not working #52

jarecsni opened this issue Sep 13, 2017 · 44 comments

Comments

@jarecsni
Copy link

There has been a conversation around this problem on different thread, please see:
facebook/react-native#6391 (comment)

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
Copy link
Contributor

cpojer commented Sep 13, 2017

@jeanlauliac can discuss more about the plans for this.

@jeanlauliac
Copy link

jeanlauliac commented Sep 14, 2017

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
Copy link
Author

jarecsni commented Sep 16, 2017

@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
Copy link

jeanlauliac commented Sep 18, 2017

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
Copy link
Author

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
Copy link

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
Copy link

jeanlauliac commented Dec 14, 2017

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
Copy link

sneerin commented Dec 27, 2017

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

@jeanlauliac jeanlauliac self-assigned this Dec 28, 2017
@camdagr8
Copy link

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
Copy link

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
Copy link

@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
Copy link

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
Copy link

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
Copy link

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

@serhiipalash
Copy link

serhiipalash commented Jan 10, 2018

@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.

@jeanlauliac jeanlauliac removed their assignment Jan 10, 2018
@simonbuchan
Copy link

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 microsoft/TypeScript#14844

@deecewan
Copy link

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
Copy link

simonbuchan commented Feb 27, 2018

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)

@MarcoMacedoP
Copy link

Is there any update status for this issue?

@pvanny1124
Copy link

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

@slorber
Copy link

slorber commented Apr 29, 2020

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? react-native-community/discussions-and-proposals#120 (comment)

@tastycode
Copy link

Looks like this would be a solution for local loading of certain kinds of content, e.g. @benbucksch 's use-case for translation files. https://github.com/itinance/react-native-fs

@coawazie
Copy link

Bump. This feature is really important....

@chybisov
Copy link

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.

This is really important use case.

@biancadragomir
Copy link

Are there any updates or any solutions? We really need to require conditionally because of integrating Huawei packages. They will be available on devices with Huawei services, but unavailable on all the others. This is really a blocker 😢

@deecewan
Copy link

deecewan commented Jun 3, 2021

you can already do conditional requires @biancadragomir IIRC.

if (HUAWEI_DEVICE) {
  require('huawei-packages');
}

this issue is specifically about not being able to use runtime-evaluated strings as import locations, for instance if you wanted to do:

const manufacturer = getManufacturerName();
require(`${manufacturer}-packages`);

edit: in fact #52 (comment) mentions it specifically - react-native-community/discussions-and-proposals#120 (comment) mentions it's released.

@biancadragomir
Copy link

@deecewan we are doing that already. But we are using a tool called handpick to exclude the huawei dependencies from normal builds. the problem is that for normal builds (non-huawei), that package isn't available and there's a crash when the build happens since the packager resolves all the "require(...)" from the project, regardless of the if branch they are on.

@jiangleo
Copy link

jiangleo commented Jul 9, 2021

You can try metro-code-split https://github.com/wuba/metro-code-split .
it provides Dll and Dynamic Imports features.

@iamonuwa
Copy link

Do not import/require the package at the top of the file.
Require it inside the function that it will be used in.

@pke
Copy link

pke commented May 14, 2022

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

It works for us in production.

It does not work in dev mode since the resolved files are cached by metro. Any changes to them or adding removing will not be recognised. I wonder if there is a metro setting to exclude certain file patterns from being cached?

@jd1378
Copy link

jd1378 commented Jun 13, 2022

I switched to re-pack which uses webpack 5 to bundle your app
I'm happy with it so far

@VityaSchel
Copy link

I switched to re-pack which uses webpack 5 to bundle your app I'm happy with it so far

tell expo developers to switch to it too pls

@karlhorky
Copy link

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`)

Since [email protected], there is an experimental require.context() implementation by @EvanBacon

const translationsContext = require.context(
  // Relative path to the directory containing the translations
  './translations',
  // Include subdirectories?
  false,
  // Regular expression files filter (eg. only include JSON files)
  /\.json$/,
);

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

This implementation is based on the require.context() feature in webpack

@feri-irawan
Copy link

What if the one using dynamic requirements is an installed package?

@vickz84259
Copy link

vickz84259 commented Aug 2, 2024

@feri-irawan I'm doing something similar at the company I work for. Our SDK when installed by a user needs to conditionally import another installed package. So you need to provide the relative path to the module you'd like to import based on the structure of node_modules.

Example:

const firebaseMessagingContext = require.context(
  '../../../../@react-native-firebase/messaging/lib',
  false,
  /index\.js$/
);

Note: The number of ../ needed depends on the structure of your library.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests