facebook / idx

Library for accessing arbitrarily nested, possibly nullable properties on a JavaScript object.

idx

This module is deprecated and no longer maintained. Use optional chaining instead.

idx is a utility function for traversing properties on objects and arrays, where intermediate properties may be null or undefined.

One notable difference between idx and optional chaining is what happens when an intermediate property is null or undefined. With idx, the null or undefined value is returned, whereas optional chaining would resolve to undefined.

Install

$ npm install idx babel-plugin-idx

or

$ yarn add idx babel-plugin-idx

Configure Babel to include the babel-plugin-idx Babel plugin.

{
  plugins: [['babel-plugin-idx']];
}

This is necessary for idx to behave correctly with minimal performance impact.

Usage

Consider the following type for props:

type User = {
  user: ?{
    name: string,
    friends: ?Array<User>,
  },
};

Getting to the friends of my first friend would resemble:

props.user &&
  props.user.friends &&
  props.user.friends[0] &&
  props.user.friends[0].friends;

Instead, idx allows us to safely write:

idx(props, _ => _.user.friends[0].friends);

The second argument must be a function that returns one or more nested member expressions. Any other expression has undefined behavior.

Static Typing

Flow and TypeScript understand the idx idiom:

// @flow

import idx from 'idx';

function getName(props: User): ?string {
  return idx(props, _ => _.user.name);
}

If you use idx@3+, you may need to add the following to your .flowconfig:

[options]
conditional_type=true
mapped_type=true

Babel Plugin

The idx runtime function exists for the purpose of illustrating the expected behavior and is not meant to be executed. The idx function requires the use of a Babel plugin that replaces it with an implementation that does not depend on details related to browser error messages.

This Babel plugin searches for requires or imports to the idx module and replaces all its usages, so this code:

import idx from 'idx';

function getFriends() {
  return idx(props, _ => _.user.friends[0].friends);
}

gets transformed to something like:

function getFriends() {
  return props.user == null
    ? props.user
    : props.user.friends == null
    ? props.user.friends
    : props.user.friends[0] == null
    ? props.user.friends[0]
    : props.user.friends[0].friends;
}

Note that the original import gets also removed.

It's possible to customize the name of the import/require, so code that is not directly requiring the idx npm package can also get transformed:

{
  plugins: [
    [
      'babel-plugin-idx',
      {
        importName: './idx',
      },
    ],
  ];
}

License

idx is MIT licensed.

idx's Issues

Question: what the difference between idx and lodash.get ?

RTFM: https://lodash.com/docs/4.17.4#get

Why you need patent for this functionality ?

Cannot find name 'bigint'

Type: Bug
Version: 2.5.4
Subject: Type Error
Environment: TypeScript 3.1.6

We are receiving the following error on build with the latest version (2.5.4).

ERROR in node_modules/idx/lib/idx.d.ts(52,21): error TS2304: Cannot find name 'bigint'.
node_modules/idx/lib/idx.d.ts(53,13): error TS2304: Cannot find name 'bigint'.

Why using the whole babel plugins and flow definitions

The question goes into 2 directions:

1. Why (if implemented on babel) are not we using the ECMAScript proposal syntaxlike?.this.directly.

2. Isn't it simpler to create a plain function wrapper? What are the advantages in comparison to the following:

function idx (expression: string) {
  try {
    return eval(expression)
  } catch (err) {
    return null // or process the error to check `undefined` against `null`
  }
}

// call afterwards binding scope

I understand the 2nd isn't ideal either (we are loosing flow power here, but I guess it could be still recovered improving the example function with some metaprogramming), but I would like to understand why of the syntax. Maybe just to have leaner code with flow annotations working, but then: what about the babel plugin?

Participation in developing the existential operator proposal Babel plugin

Feel free to close the issue (since this is about the existential proposal), but I wanted to check in/ask if FB would be willing to help with the development of the actual babel plugin given it's Stage 1 now (babel/babylon#328).

Aside: happy to see the use of preset-env and lerna 😄

`UnboxDeepRequired doesn't support enum type.

enum MyEnum {
  'a' = 'a',
  'b' = 'b',
}
type MyType = {
  enum: MyEnum;
};
const e: MyEnum | null | undefined = idx({} as MyType, _ => _.enum);

Got:

Type 'IDXOptional<string>' is not assignable to type 'MyEnum | null | undefined'.
  Type 'string' is not assignable to type 'MyEnum | null | undefined'.ts(2322)

Because idxs return type is string | null | undefined instead of MyEnum | null | undefined

Related PR: #76

@mohsen1 @brieb @yungsters

Magical library

I'm just curious, the source of the name idx

How to use idx

Some info is missing in the README.md.

Do I need to install idx as devDependency or dependency?

After I write the idx optional chaining syntax, do I need to import the idx function? If, yes, why?

Does idx() function transform the syntax when using babel or in runtime?

Do I need any config in .babelrc?

idx doesnt detect null value in Russian localization in IE

In russian localization IE throws next error "Не удалось получить свойство "value" ссылки, значение которой не определено или является NULL". But nullPattern regex doesn't detect it as null error, because of upper case (NULL)

Replace `NonUndefinedOrnNull` with TypeScript standard type `NonNullable`

Replace NonUndefinedOrnNull with TypeScript standard type NonNullable.

https://github.com/facebookincubator/idx/blob/master/packages/idx/src/idx.d.ts#L5

https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-8.html#predefined-conditional-types

@mohsen1

idx withDefault variant

I think it would be nice to add an additional export of the idx function which will allow us to pass in a default value.

Since idx has its own type, it would be quite difficult to create a wrapper around idx without breaking the current type signature.

I propose an API that looks like this:

idxOr('DEFAULT VALUE', data, data => data.path.name);

Similar to ramda's pathOr function http://ramdajs.com/docs/#pathOr

relicense idx without patents grant

after React, it would be nice also to have idx relicensed without the patent grant clause.
do we will see it happening?

thanks.

Outdated CHANGELOG

Hi 👋, I was just updating dependencies in my projects and wanted to take a look into your changelog. Unfortunately the changelog is out of sync with the latest released version. It stops at version 2.4.0. Could you please add the missing changes to the changelog and keep it in sync? Thanks a lot!

Merge in the macro?

There is a great macro project https://github.com/dralletje/idx.macro that makes it possible to use this with Create React App without ejecting. Would it not make sense to just merge this into one project (especially since the author specifically wrote that he's open to do so?)

This would make it easier to keep them in sync since the typescript definitions have already started diverging... :-/

CI is not running test for PRs

Let's make CI run tests for PRs too

[TS] v2.5.0 DeepRequired generic breaks input.focus()

After upgrading to v2.5.0 I get the following error:

Context:

Deprecate?

Now that optional chaining is almost everywhere, I think this should print out a deprecation warning.

Flow typedef doesn't work?

https://github.com/facebookincubator/idx/blob/master/packages/idx/src/idx.js.flow#L12

Is there a version of flow which comes with this type baked in? For open-source users, it'd be nice if the distributed typedef was useful.

idx() callbacks may only access properties on the callback parameter!

I've reported this issue on flowtype: facebook/flow#4729

I also create an issue here.

---

The following code raises a flowtype error when using idx with immutable.js:

// `state` is obtained from redux store
// `state.user` is an immutable object; you need to use `getIn()` to access properties
const token = idx(state, _ => _.user.getIn(['userInfo', 'token']));

The flowtype shows the error:

 81:   const countryCode = idx(state, _ => _.country.getIn(['selectCountry', 'countryCode']));
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ function call. idx() callbacks may only access properties on the callback parameter!

I need to change code to this to suppress flowtype warnings:

const tokenS = idx(state, _ => _.user.getIn);
const token = (tokenS) ? tokenS(['userInfo', 'token']) : undefined;

It makes no sense to write such code.

Running Jest tests I got "The body of the arrow function supplied to `idx` must be a single expression"

The body of the arrow function supplied to `idx` must be a single expression (without curly braces).
        36 |            })
        37 |                    .then(res => {
      > 38 |                            const similarItems = idx(res, _ => _.data.similarDeals) || [];
           |                                                               ^
        39 |                            if (similarItems.length) {
        40 | 
        41 |                                    const converted = similarItems.map(item => {

typescript definitions

it would be nice to have also typescript definitions along with flow ones in order to support out of the box strict typescript environments.

Compare this with Lodash.get

Hi,
Could you let me know? What is different between this plugin with Lodash.get?
https://lodash.com/docs/#get

Thanks

IE and FireFox - different error patterns

IE and Edge

I've been using idx for a couple of days and found that it returns only null on property access error for IE and Edge.

This is caused because the isNullPropertyAccessError and isUndefinedPropertyAccessError methods used by idx are getting the same pattern from the getInvalidPropertyAccessErrorPattern function as shown bellow:

// FireFox
getInvalidPropertyAccessErrorPattern(null);
// Pattern: /.+ is null/
getInvalidPropertyAccessErrorPattern(undefined);
// Pattern: /.+ is undefined/

// Chrome
getInvalidPropertyAccessErrorPattern(null);
// Pattern: /Cannot read property '.+' of null/
getInvalidPropertyAccessErrorPattern(undefined);
// Pattern: /Cannot read property '.+' of undefined/

// EDGE and IE11
getInvalidPropertyAccessErrorPattern(null);
// Pattern: /Unable to get property '.+' of undefined or null reference/
getInvalidPropertyAccessErrorPattern(undefined);
// Pattern: /Unable to get property '.+' of undefined or null reference/

Firefox

I am also getting sometimes a TypeError message only in FireFox version 52.
I guess this is related to the fact that in most of the browser you get the same error message but different ones for FF in the following cases:

Chrome
// Access to a property of an object set as undefined
var a = undefined;
a.someProperty
**TypeError: Cannot read property 'someProperty' of undefined**
// Access to a property of undefined (global object)
undefined.someProperty
**TypeError: Cannot read property 'someProperty' of undefined**

FireFox
// Access to a property of an object set as undefined
var a = undefined;
a.someProperty
**TypeError: a is undefined**
// Access to a property of undefined (global object)
undefined.someProperty
**TypeError: undefined has no properties**

IE and EDGE
// Access to a property of an object set as undefined
var a = undefined;
a.someProperty
**Unable to get property 'someProperty' of undefined or null reference**
// Access to a property of undefined (global object)
undefined.someProperty
**Unable to get property 'someProperty' of undefined or null reference**

Firefox nightly - idx fails to match TypeErrors

TypeErrors in Firefox nightly do not pass the undefinedPattern and nullPattern tests.

It's easily reproducible:

• Go to this JSFiddle
• Open the Debugger and check Pause on exception
• Observe that the error is rethrown while it should be handled on line 65.

Screenshot:

This is due to TypeErrors messages in Firefox nightly being different from regular Firefox, see the same example in regular Firefox:

Typescript types do not work on undefined as first parameter (new test case)

@Horaddrim This doesn't solve the problem for me.

    const myVar: { a: { b: string } } | null = null as {
      a: { b: string };
    } | null;
    const something = idx(myVar, _ => _.a.b) || "TEST";

still fails the build.

Originally posted by @macalinao in https://github.com/facebookincubator/idx/issue_comments#issuecomment-449763073

Can't make babel-plugin-idx works with async function

Description

Everything is working fine until I use idx inside async function

const obj = { a: 0, b: { c: 1 } }

const Working = () => {
  idx(obj, _ => _.b.c)
}

const notWorking = async () => {
  idx(obj, _ => _.b.c)
}

I'm getting this :

babel config :

"babel": {
    "presets": [
      [
        "es2015",
        {
          "modules": false
        }
      ],
      "react",
      "stage-0"
    ],
    "plugins": [
      "idx",
      [
        "transform-runtime",
        {
          "helpers": false,
          "polyfill": false
        }
      ]
    ]
  }

DeepRequiredObject causing issues in Typescript 3.5.1

After upgrading to typescript 3.5.1 I am having issues and having to do a lot of manual casting of types.

const Users: {
    user?: {
        dateAdded: Date
    }
} = { user: { dateAdded: new Date() } };
const userDate = idx(Users, _ => _.user.dateAdded)
if (userDate) {
    new Date(userDate) // Errors - Type DeepRequiredObject<Date> is not assignable to type 'number'
}

The following will also fail:

interface UInterface {
    user?: {
        dateAdded: Date;
    };
}

const Users: UInterface = { user: { dateAdded: new Date() } };
const userDate = idx<UInterface, Date>(Users, _ => _.user.dateAdded); // This now fails with
/*
TS2741: Property '[Symbol.toPrimitive]' is missing in type 'DeepRequiredObject<Date>' but is required in type 'Date'
*/
if (userDate) {
    console.log(new Date(userDate));
}

discussion for setIn implementation?

Is there discussion or an existing solution for a setInversion? It seems like it could maintain the same api and just add an extra param to set value if path exists.

similar to: https://lodash.com/docs/4.17.11#set

Seems like this would be useful to others?

Typescript types do not work on undefined as first parameter

The following does not work:

          const myVar: { a: { b: string } } | null = null as {
            a: { b: string };
          } | null;
          const something = idx(myVar, _ => _.a.b);

Default value

What do you think about having a default value in case there is an error while accessing a property.

Essentially, the function signature might be like:

function idx<Ti, Tv, Td>(input: Ti, accessor: (input: Ti) => Tv, defaultValue: ?Td): ?Tv

And then we could use it as:

const DEFAULT_FRIENDS = [{ name: "Pavlos" }]
idx(props, _ => _.user.friends[0].friends, DEFAULT_FRIENDS)

Which can be transformed to

props.user == null 
   ? props.user 
   : props.user.friends == null 
         ? props.user.friends 
         : props.user.friends[0] == null 
                ? DEFAULT_FRIENDS
                : props.user.friends[0].friends

Add support for union types

When I provide the following function definition:

type TestT = { x?: { z: boolean } }

function somefn(t: TestT) {
  return idx(t, _ => _.x.z)
}

flow compiles with no errors. however, when I change the definition of TestT to the following:

type TestT = { y: string } | { x?: { z: boolean } }

Flow returns the following error (at the usage of idx above): "property x Property not found in object type"

`idx` should be implemented such that function calls don't lose their `this` binding

This doesn't work:

componentWillUnmount(): void {
  idx(this.foo, _ => _.bar());
  delete this.foo;
}

It gets transformed to this:

(_ref = this.foo) != null 
  ? (_ref = _ref.bar) != null 
    ? _ref() 
  : _ref 
: _ref;
delete this.foo;

And can throw this kind of error because internal to foo, this is undefined:

TypeError: Cannot read property '_baz' of undefined

This works fine:

componentWillUnmount(): void {
  if (this.foo) {
    this.foo.bar();
  }
  delete this.foo;
}

I suppose idx should do this instead?

(_ref = this.foo) != null 
  ? _ref.bar != null
    ? _ref.bar() 
  : _ref.bar 
: _ref;

Minimal test case: (link)

undefined variables are not accesing in firefox and edge....type Error: this.something is undefined

how can change my code to get rid off this error="typeError: this.someThing is undefined"
'someThing ' is undefined value

Upgrade to latest version of Flow

Upgrade to latest version of Flow

The current version: 0.89.0.
The version used here: ^0.73.0

"uncovered code" warning from flow

Although I'm not getting any error when using idx, I'm getting "uncovered code" wherever idx is used. Using flow 0.61.0, idx 2.2.0, babel-plugin-idx: 2.2.0.

Example:

index.js

// @flow
import idx from 'idx';

type User = {
    user: ?{
        name: string,
        friends: ?Array<User>,
    }
};

const props: User = { user: null };

// Uncovered code warning from flow for arrow function below
idx(props, _ => _.user.friends[0].user.friends)

flow coverage index.js 
Covered: 56.25% (9 of 16 expressions)

flow coverage index.js --pretty
{
  "expressions":{
    "covered_count":9,
    "uncovered_count":7,
    "uncovered_locs":[
      {
        "source":"/Users/ngupta/progjs/idx_sample/index.js",
        "type":"SourceFile",
        "start":{"line":14,"column":12,"offset":232},
        "end":{"line":14,"column":12,"offset":233}
      },
      {
        "source":"/Users/ngupta/progjs/idx_sample/index.js",
        "type":"SourceFile",
        "start":{"line":14,"column":17,"offset":237},
        "end":{"line":14,"column":17,"offset":238}
      },
      {
        "source":"/Users/ngupta/progjs/idx_sample/index.js",
        "type":"SourceFile",
        "start":{"line":14,"column":17,"offset":237},
        "end":{"line":14,"column":22,"offset":243}
      },
      {
        "source":"/Users/ngupta/progjs/idx_sample/index.js",
        "type":"SourceFile",
        "start":{"line":14,"column":17,"offset":237},
        "end":{"line":14,"column":30,"offset":251}
      },
      {
        "source":"/Users/ngupta/progjs/idx_sample/index.js",
        "type":"SourceFile",
        "start":{"line":14,"column":17,"offset":237},
        "end":{"line":14,"column":33,"offset":254}
      },
      {
        "source":"/Users/ngupta/progjs/idx_sample/index.js",
        "type":"SourceFile",
        "start":{"line":14,"column":17,"offset":237},
        "end":{"line":14,"column":38,"offset":259}
      },
      {
        "source":"/Users/ngupta/progjs/idx_sample/index.js",
        "type":"SourceFile",
        "start":{"line":14,"column":17,"offset":237},
        "end":{"line":14,"column":46,"offset":267}
      }
    ]
  }
}

New release?

There's some great updates to the TS typing here and it'd be awesome to have a 2.6.0 release :)

Thanks so much!

[request] Add changelog

[email protected] was released yesterday, and I can't seem to find anything suggesting what the breaking changes are. Can you please post a changelog, at least for major version releases?

Consider to support nullable type in `idx` first argument

E.g.

type Obj = {
  a?: {
    b?: {
      c?: string
    }
  }
}
let obj: Obj = {} as any;
const a = idx(obj, _ => _.a);
const b = idx(a, _ => _!.b); // a can be null or undefined
const c = idx(b, _ => _!.c); // b can be null or undefined

Can we ignore the ! in the last two lines ?

FYI: @mohsen1

mention optional chaining proposal

Since this is very relevant to this project, mentioning https://github.com/tc39/proposal-optional-chaining in the readme for example would be a good idea I think

Accessing Data on Void

I get type errors when trying to access nested data on a value that could be void.

For example:

const fetchData: Promise<void | {data: {nested: 1}}>;
const response = await fetchData();
const nested = idx(response, _ => _.data.nested);

I get the following error from TypeScript: Property 'data' does not exist on type 'void'

Since the type void will always be undefined or null, shouldn't the code above pass the type checker?

Btw, thanks for this tool!

idx swallows some null-related errors that optional chaining do not

Here is a serious incompatibility with optional-chaining.

Testcase:

var a = { b: null };
a?.b.c; // should throw a TypeError, as `a.b` is null

With idx, as currently implemented in https://github.com/facebookincubator/idx/blob/master/packages/idx/src/idx.js#L58

var a = { b: null };
idx(a, _ => _.b.c); // do not throw error

In order to follow more closely the spec, idx should not catch every null-related error, but test the nullity of one specific value, e.g.:

const idx = (input, accessor)  => input == null ? input : accessor(input);

Of course, this would be a serious BC breaking change for idx.

@babel/typescript support

Hi there,

I am working on a project that is compiling TypeScript through Babel using @babel/typescript preset and when I try to use idx I appear to run into an issue with the babel stage and I believe it is similar to #72 in that idx is being fed TypeScript AST and gets confused.

I could be wrong! I've only done some cursory debugging by adding some console.log's before the error message to see why it was hitting the else case every time.

Minimal babel config:

{
    presets: [
        [
            "@babel/preset-env",
            {
                targets: {
                    node: "current",
                },
            },
        ],
        "@babel/typescript",
    ],
    plugins: [
        "babel-plugin-idx"
    ],
};

dummy type:

interface MainArgs {
  QUICK_MODE?: boolean
}
const defaultArgs {
 QUICK_MODE: false
}
  
function dummy(mainArgs: MainArgs) {
let args = {
  ...defaultArgs
  ...mainArgs
};
const QUICK_MODE = idx(mainArgs, a => a.QUICK_MODE!)!;

I've tried various permutations with the TypeScript non-null assertion and nothing helps.

Here's the error (with mismatched line numbers)

ERROR in ./src/dummy.ts
Module build failed (from ./node_modules/babel-loader/lib/index.js):
SyntaxError: /tmp/w/dummy/src/dummy.ts: idx callbacks may only access properties on the callback parameter.
  137 |         // ...code
  138 |         
> 139 |         const QUICK_MODE = idx(mainArgs, a => a.QUICK_MODE!)!;
      |                                               ^
  140 |         await this.cleanup(QUICK_MODE);
  141 | 
    at File.buildCodeFrameError (/tmp/w/dummy/node_modules/@babel/core/lib/transformation/file/file.js:261:12)
    at makeChain (/tmp/w/dummy/node_modules/babel-plugin-idx/lib/babel-plugin-idx.js:92:24)
    at visitIdxCallExpression (/tmp/w/dummy/node_modules/babel-plugin-idx/lib/babel-plugin-idx.js:100:23)
    at /tmp/w/dummy/node_modules/babel-plugin-idx/lib/babel-plugin-idx.js:149:11
    at Array.forEach (<anonymous>)
    at Object.ImportDeclarationVariableDeclarator (/tmp/w/dummy/node_modules/babel-plugin-idx/lib/babel-plugin-idx.js:145:51)
    at NodePath._call (/tmp/w/dummy/node_modules/@babel/traverse/lib/path/context.js:53:20)
    at NodePath.call (/tmp/w/dummy/node_modules/@babel/traverse/lib/path/context.js:40:17)
    at NodePath.visit (/tmp/w/dummy/node_modules/@babel/traverse/lib/path/context.js:88:12)
    at TraversalContext.visitQueue (/tmp/w/dummy/node_modules/@babel/traverse/lib/context.js:118:16)
    at TraversalContext.visitMultiple (/tmp/w/dummy/node_modules/@babel/traverse/lib/context.js:85:17)
    at TraversalContext.visit (/tmp/w/dummy/node_modules/@babel/traverse/lib/context.js:144:19)
    at Function.traverse.node (/tmp/w/dummy/node_modules/@babel/traverse/lib/index.js:94:17)
    at traverse (/tmp/w/dummy/node_modules/@babel/traverse/lib/index.js:76:12)
    at NodePath.traverse (/tmp/w/dummy/node_modules/@babel/traverse/lib/path/index.js:161:24)
    at PluginPass.Program (/tmp/w/dummy/node_modules/babel-plugin-idx/lib/babel-plugin-idx.js:173:16)
    at newFn (/tmp/w/dummy/node_modules/@babel/traverse/lib/visitors.js:193:21)
    at NodePath._call (/tmp/w/dummy/node_modules/@babel/traverse/lib/path/context.js:53:20)
    at NodePath.call (/tmp/w/dummy/node_modules/@babel/traverse/lib/path/context.js:40:17)
    at NodePath.visit (/tmp/w/dummy/node_modules/@babel/traverse/lib/path/context.js:88:12)
    at TraversalContext.visitQueue (/tmp/w/dummy/node_modules/@babel/traverse/lib/context.js:118:16)
    at TraversalContext.visitSingle (/tmp/w/dummy/node_modules/@babel/traverse/lib/context.js:90:19)
    at TraversalContext.visit (/tmp/w/dummy/node_modules/@babel/traverse/lib/context.js:146:19)
    at Function.traverse.node (/tmp/w/dummy/node_modules/@babel/traverse/lib/index.js:94:17)
    at traverse (/tmp/w/dummy/node_modules/@babel/traverse/lib/index.js:76:12)
    at transformFile (/tmp/w/dummy/node_modules/@babel/core/lib/transformation/index.js:88:29)
    at runSync (/tmp/w/dummy/node_modules/@babel/core/lib/transformation/index.js:45:3)
    at runAsync (/tmp/w/dummy/node_modules/@babel/core/lib/transformation/index.js:35:14)
    at process.nextTick (/tmp/w/dummy/node_modules/@babel/core/lib/transform.js:34:34)
    at process._tickCallback (internal/process/next_tick.js:61:11)
 @ ./src/index.ts 34:0-66 35:35-57

Add support for Map.get in .ts files

Currently writing:

 idx(obj, _ => _.someMapProp.get(someKey).subValue)

in typescript file gives an error:
TS2533: Object is possibly 'null' or 'undefined'

babel-plugin does not verify idx was imported from the package idx

Babel plugin doesn't verify idx comes from an import from idx package.
This change could be dangerous if somebody has a function called idx in their code.

I was trying to add idx in create-react-app by default as it would be usefull for many people and a way to expand its use.

See facebook/create-react-app#1874

I know this should be check here.
I will try to make a PR for this.

cc @gaearon

Flow cannot resolve module idx

Cannot resolve module idx.

     1│ // @flow
     2│ import idx from 'idx';
     3│ import * as React from "react";
     4│ import {execute} from 'graphql/execution';
     5│ import {parse} from 'graphql/language';

My packages versions are:

"babel": "^6.23.0",
"babel-plugin-idx": "^2.2.0",
"flow-bin": "^0.72.0",

Do you guys have any idea what the problem might be?

Doesn't work with TS compiler

I've got a project that use: TS, React, Webpack, Babel, idx, and kept having issues with IE11. After digging a bit deeper I realised the TS compiler, which runs first in the build chain, prevents babel-plugin-idx from transpiling idx because it obfuscates the import and usage.

This may have been obvious, but I didn't realise until recently. I think it should be mentioned explicitly in the readme that you have to use @babel/plugin-transform-typescript and NOT the TS compiler.

I haven't found a workaround yet, I'd like to have type checking when creating my production build. If anyone has dealt with this I would love to know.

I'm happy to make a PR for the readme update if you'd like.

Error message patterns prevent Firefox from improving messages

Over in Bug 1498257, we've had to back out some DX improvements to error messages from Firefox's JS engine because it broke Flipkart (the number 6 site in India, top 150 globally).

It turns out the reason is idx, see https://bugzilla.mozilla.org/show_bug.cgi?id=1498257#c7 for more details.

https://github.com/facebookincubator/idx/blob/master/packages/idx/src/idx.js#L73-L84

I'm not sure how widely this lib is used, but fixing here would allow us to attempt error message improvements again.

https://hg.mozilla.org/integration/mozilla-inbound/rev/f0c6e521429c is the changeset that was backed out. Some example improved error messages are:

TypeError: win.browser.runtime is undefined, can't access property "getManifest" of it
TypeError: [...][Symbol.iterator](...).next(...).value is null, can't access property Symbol.iterator of it

idx doesn't detect TypeErrors in german IE

Related to #46 , A german error can look like this:

Die Eigenschaft "addresses" eines undefinierten oder Nullverweises kann nicht abgerufen werden.

This does not pass the regex test and therefore gets thrown in the console.

Change return value from `T2 | null | undefined` to `T2 | null` and `T2 | undefined`?

I'm using idx with Typescript and running into some minor problems with the return type.
Example:

interface User {
  user?: { name?: string };
}
function getName(user: User) {
 return idx(user, _ => _.user.name);
}

I would expect the return type of getName to be string | undefined. However the type is string | undefined | null.
I would think that it can be inferred at compile time that null is not a possible return type in case case, given the interface User.

Is there any reason for this behaviour or is it a limitation with Typescript?