not working when browser not support Symbol

[ariesjia]

if browser not support Symbol ，the action.key is string not equal to object ， so push error and not send api

for (let key in action) {
    if (key !== [CALL_API]) {
      validationErrors.push(`Invalid root key: ${key}`);
    }
  }

I fount if browser support Symbol , do not enter this for loop . because action.key is real Symbol

Maybe this validate is not necessary .

[olslash]

+1 -- having this issue in phantom, even though it's going through babel first. Any ideas?

[olslash]

as a hotfix in my codebase, i fixed this by:

• changing CALL_API to a string ("redux-api-middleware/CALL_API") in CALL_API.js
• taking out the array around CALL_API here: https://github.com/agraboso/redux-api-middleware/blob/master/src/validation.js#L89. I think that must have been a typo.

there is some weird issue with the way babel is handling symbols that's preventing it from working, but I can't figure it out.

[riophae]

You could inject a polyfill for Symbol into your project.
See: https://github.com/zloirock/core-js#commonjs

[olslash]

I changed my test setup to not include Phantom so I can't verify this, but I believe I did have Symbol polyfilled. It's possible the issue was with the polyfill, or that it wasn't working properly, although other ES6 stuff like Promise did. Once i get browser tests running again I'll report back.

[riophae]

@olslash Did you bundle the project when testing in Phantom.js? As far as I know, if you didn't use something like Browserify, Phantom.js could work improperly with core.js polyfills.

[jamesbillinger]

+1 I'm having this issue in IE11. I added es6-symbol and verified that I can create and use Symbols, but I still can't get [CALL_API] to work in IE.

[stinju]

FWIW, I ran into the same issue when using with react-native on pre-iOS-9 devices.

[danny-andrews]

I don't think we should be using symbols in the action anyway, as the redux docs suggest against it: "We recommend that you use strings and not Symbols for action types, because strings are serializable, and by using Symbols you make recording and replaying harder than it needs to be." Although this is talking specifically about action types, the same principle applies for all parts of an action.

So I think we should change the lines here from:

const CALL_API = Symbol('Call API');

export default CALL_API;

to

export default 'CALL API';

[geminiyellow]

@agraboso

i found the Discussion about use Symbol as action type.

reduxjs/redux#114 (comment)
reduxjs/redux#127

and @gaearon change Symbol to prefix @@ as initial action special type in redux.
so how about change Symbol('Call API') to redux-api-middleware/API or @@redux-api-middleware/API or something else.

[ariesjia]

+1 for '@@'

[barrystaes]

Agreed.

Its also what react-router-redux does: @@router/UPDATE_LOCATION
(formerly known as redux-simple-router)

[barrystaes]

@geminiyellow
I guess now the hard part is naming things, and do a PR.. and update docs and tests.

I think CALL_API is fine, but what about using @@redux-api-middleware/RSAA as the value, and RSAA as the value's name? This would make it somewhat self-explaining and future proof.

The example would then become

import { RSAA } from `redux-api-middleware`;

{
  [RSAA]: {
    endpoint: 'http://www.example.com/api/users',
    method: 'GET',
    types: ['REQUEST', 'SUCCESS', 'FAILURE']
  }
}

Just a thought.. i have to say that CALL_API is also quite self-explanatory..

[geminiyellow]

@barrystaes
yes, i think so, CALL_API is good enough, but RSAA is better.
[CALL_API] in redux-api-middleware is a type name,
so nouns RSAA looks more self-explaining, and shorter, and no _.
i dont like _

sorry, @georgebonnr , wrong @