Redux 4 breaking changes

[gaearon]

Creating this issue to keep a pile of breaking changes we want to release at once. This doesn’t mean we plan to do much breaking changes! Mostly they are cosmetic but since we’re using semver, we want to batch them. This is why this issue exists.

• Updated TypeScript bindings (for TS 2.0+)
• Remove ActionTypes from createStore exports. It was never intended to be a part of public API. It is not visible of you import redux but since we now support importing redux/lib/* officially, we should stop exporting ActionTypes from redux/lib/createStore.
• Make sure INIT name is random (Action never seen when dispatched on Store. #1736 (comment))
• Bundle the cjs and es modules (Bundle cjs and es formats #2358)
• Switch to babel-preset-env and drop support for IE < 11.
• Drop lodash dependency Optimize dispatch plain object check #2599
• Fix dispatching inside middleware setup. Or document this behavior. Dispatching in a middleware before applyMiddleware completes #1240.
• Forbid subscribe() and getState() while reducer is running: Forbid getState() and subscribe() while the reducer is being called #1568

[timdorr]

we now support importing redux/lib/*

We do? I always viewed any import from outside of main (basically any import with a slash) as accessing private APIs. Your main should be the list of public APIs provided by the library. The only exception is for reducing your bundle size (until ES6 module builders become more readily available), but you would be doing this as an optimization step after importing something from the public API.

Drop support for IE8.

Then we can import #1123 finally? 😄

[gaearon]

The only exception is for reducing your bundle size (until ES6 module builders become more readily available), but you would be doing this as an optimization step after importing something from the public API.

Yes, since 3.0.6. /lib/ is a practical way to do it today and I see no reason to disallow it until ES6-aware bundlers are commonplace. Our top-level API is stable so I don’t expect supporting it to be a pain.

Then we can import #1123 finally?

I’m looking into getting this in with es3ifyPlugin for now. But future-wise, yeah.

[timdorr]

Our top-level API is stable so I don’t expect supporting it to be a pain.

Yeah, I don't think it's a pain thing either, just more of a philosophical issue. How do we want to go about importing them for combineReducers? Move them to utils and import from there?

[timdorr]

Welp, I just went ahead and did that as a PR 😄 If you wanted to do it another way, no worries.

[gaearon]

Move them to utils and import from there?

👍

[guijesuis]

I d like to share a little bit of my experience with redux. i spent 5 month working on a fairly large redux application.
Redux did an awesome job. Nevertheless after few weeks of dev we hit the issue "how to deal with asynchronous actions". At first we used redux thunk and it did the job, but ours actions grew rapidly in complexity.
At that point i decided to create a middleware base and generator functions (similar to redux saga but it was still actions). it allowed us to write complex action like the following login action

export function* login(login, password) {
  var {state} = yield {
    type: types.ON_DO_NOTHING
  };

  if (state.cursor == "wait")
    return {type: types.ON_DO_NOTHING};

  yield {type: types.ON_WAITCURSOR_START};

  var {state,result} = yield RestManager.Call({
    method: REST.METHODS.POST,
    url: REST.RESOURCES.SESSIONS,
    header: RestManager.getAuthenticationHeader(login, password)
  });

  if (result.status == "success") {

    yield  {
      type: types.ON_REQUEST_SESSION_ID_COMPLETED,
      sessionID: result.data.content.sessionId,
    };

    var {state,result} = yield RestManager.Call({
      method: REST.METHODS.GET,
      url: REST.RESOURCES.FEATURES + "/AIPLM_INTEGRATION/users/" + login,
      header: RestManager.getBasicHeader(REST.APPLICATION_TYPE.JSON)
    });

    if (result.status == "success") {

      yield {type: types.ON_GET_CURRENT_DOCUMENT};
    }
    else {

      yield {type: types.ON_DISCONNECT_YES};

      yield messagesAction.displayMessage("error", i18n.t("NO_FEATURE_MESSAGE"));
    }
  }
  else {

    yield messagesAction.displayMessage("error", result.data.content);
  }

  return {type: types.ON_WAITCURSOR_STOP};
}

And that how we resolved our issue with asynchronous action..

I now believe that redux is mixing 2 distinct concept as one, action and store effect.
• Actions should be what the user or computer trigger (ex: click on button, clock-tic , post form ...)
• Store effects should be triggered by action to mutate the store

[gaearon]

@guijesuis

Awesome that you discovered this pattern while working on a real world app. I agree with you that this seems like a great idea. In fact this is exactly what https://github.com/yelouafi/redux-saga offers.

[gaearon]

Oh wait, you mentioned that. Yeah it’s not exactly the same now that I look at it. This is both the blessing and the curse of Redux: you can choose any abstractions that you feel comfortable with.

[guijesuis]

Redux-saga grant daemon. within daemon you can track action and dispatch effect (but those effect are still action in redux). Don't you believe that separating those 2 (getting a store effect dispatcher and an action effect dispatcher with their own midleware pipe) one way to improve redux in the future.

[taion]

BTW, I think imports of the form ${package}/lib/${module} are not ideal, though they're the easiest way to go. Especially if you have a separate ES module build for which tree shaking works anyway, you should probably expose those as ${package}/${module} imports, potentially by npm publishing a subdirectory rather than the project's Git root.